Граф коммитов

18 Коммитов

Автор SHA1 Сообщение Дата
Vincent Dondain f8d00ee167
[xm][msbuild] Fix full profile FrameworkList file (#5674)
* Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/801867
  System.Memory.dll not being copied anywhere when Roslyn package is referenced
  The issue was that the XM FrameworkList was shared for the 2 profiles and there are differences.
  The Full profile for instance doesn't have `System.Memory` and that causes some issues with Nuget package references.
* Updated tests to report issues against the XM Full and Mobile Framework lists
* Now using 2 separate XM FrameworkList files (updated makefile) since the list of assemblies is different and that's expected by the mono team.
2019-02-27 12:38:38 -05:00
Rolf Bjarne Kvinge 3704379ba5
[msbuild] Find source files in the Xamarin.MacDev repo as well to improve dependency tracking. (#5278)
This makes 'make' rebuild the msbuild assemblies when only something in the
Xamarin.MacDev repository changes.
2018-12-18 07:48:40 +01:00
Chris Hamons d7c2a45ca9
Add 'NoBindingEmbedding' style binding project support (#5167)
- Existing binding projects embed the native libraries within the assembly as managed resource
- This does not scale well and has performance implications
- This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently.
- Existing binding projects are not affected, they will continue as is
- I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects.
    -When we complete some form of msbuild testing reform, we'll revisit these tests.
- Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere)
- Remove unnecessary sleep and fix broken touch command
- Output failing test log to console instead of test output
    - VSfM does not handle thousands of lines of test failure message well
- Add ability to generate binding projects with LinkWith
2018-12-12 09:55:57 -05:00
Rolf Bjarne Kvinge c69c74b3d3
Clone files if possible whenever it makes sense. (#5049)
Cloning is faster when supported, and it also saves disk space.
2018-10-29 16:09:30 +01:00
Rolf Bjarne Kvinge 26b500ab27
[msbuild] Don't put gcc/linker flags in the response file, since Mono.Options doesn't support escaping quotes. Fixes vsts#649776. (#4495)
Mono.Options doesn't (yet) support escaped quotes when parsing response files,
which becomes a problem because escaped quotes are necessary when passing
paths with spaces as gcc/linker flags.

So don't write gcc/linker flags in the response file, and instead pass them as
normal command line arguments, and to be on the safe side, do the same thing
for all extra arguments passed to mmp/mtouch.

Also add tests.

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/649776.
2018-07-24 19:49:33 +02:00
Rolf Bjarne Kvinge 398f430a55
[msbuild] Fix Makefile warning by removing duplicate target. (#3277)
Fixes this warning:

> Makefile:317: target `/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/msbuild/iOS' given more than once in the same rule.

because the same directory was listed twice.
2018-01-22 22:30:27 +01:00
Rolf Bjarne Kvinge 4b667e4700
[build] Fix makefiles to be compatible with remake v4.2.1. (#3184)
For some strange reason the following sometimes work with make v3.8.1:

    X/:
    	mkdir X

    X/Y: X
    	mkdir X/Y

Note how the second target specifies `X` as a dependency, but the actual
target to be executed is `X/` (additional trailing slash).

It does not work with remake (v4.2.1), nor in a simple test case like the one
above with make (v3.8.1), but it works in our own makefiles (which are
admittedly slightly more complicated).

Since it's trivial to fix, and I don't understand how it works in make in the
first place, I'm just changing it to what makes sense (and works everywhere):
remove trailing slashes from all directories that are used as targets.
2018-01-09 17:09:04 +01:00
Jeffrey Stedfast 316948e5d0 [msbuild] Repack all iOS Task assemblies into Xamarin.iOS.Tasks.dll (#3168) 2018-01-08 14:29:52 -05:00
Jeffrey Stedfast 5645e3349a Revert "[msbuild] Repack all iOS Task assemblies into Xamarin.iOS.Tasks.dll (#3007)"
This reverts commit 2d4256ef15.
2017-11-29 09:22:22 -05:00
Jeffrey Stedfast 2d4256ef15
[msbuild] Repack all iOS Task assemblies into Xamarin.iOS.Tasks.dll (#3007)
* [msbuild] Pack all iOS MSBuild Task assemblies into a single assembly

* Fixed the build

* Renamed ProcessArgumentBuilder to CommandLineArgumentBuilder

This is needed to prevent symbol conflicts with Xamarin.MacDev's
ProcessArgumentBuilder (which is functionally different from
Xamarin.MacDev.Tasks.Core's class of the same name).

* Fixed ILRepack logic for filtering dll's to repack

* Fixed building of Xamarin.iOS.Tasks.Tests now that X.iOS.Tasks.dll contains all symbols

* Updated Makefile now that only 1 iOS Task assembly needs to be distributed

* ILRepack Xamarin.Mac.Tasks as well

* Fixed up *.targets to specify The One Assembly To Rule Them All

* [xharness] Build MSBuild tests with MSBuild.

* Touch the ilrepack stamp file *after* invoking ILRepack, not before.

* Same for Xamarin.Mac.Tasks
2017-11-27 14:44:09 -05:00
Jeffrey Stedfast 12bb6eca91 [msbuild] Switched to using System.Json instead of Newtonsoft.Json (#2834) 2017-10-10 16:04:14 -04:00
Rolf Bjarne Kvinge b568b2541e [builds] Improve mono/llvm dependencies. (#1948)
* [builds] Improve mono/llvm dependencies.

* Create a list of all the files in the mono and llvm repositories, and save
  these lists as a Make variable (in a generated Makefile - .deps.*.mk). We
  don't list _all_ the files in each repository, because there are quite a few
  (55k for mono), and Make measurably takes a while to check all of them, so
  try to limit it to a sane subset, without risking missing changes to files
  that actually matters.

* Always create stamp files when we're done with mono builds.

* Modify the mono/llvm builds to depend on all the files in their
  repositories.

* Explicitly list the corresponding .stamp-build-* files as dependencies for
  various files that are produced by the mono builds, so that make knows how
  to build these files.

* Rewrite the *-facade-check targets to depend on the corresponding
  *_BCL_TARGETS, so that we can avoid running a submake to the same Makefile
  to execute the facade checks.

  It now takes a little while (less than a second on my machine, which is
  fine) for make to list all dependencies and get their timestamps, but if
  executing multiple submakes this adds up to a multi-second timewaste.

  So avoid the timewaste by not doing submakes, but instead use dependencies
  to enforce the required target execution ordering.

* Don't depend on nicely named intermediate targets, since won't prevent
  rebuilds:

      build-cross64: setup-cross64

  Since the `setup-cross64` file doesn't exist, `build-cross64` will always
  execute. Instead depend on the stamp file:

      build-cross64: .stamp-configure-cross64

  And now `build-cross64` will only rebuild if needed.

* Don't try to list all intermediate files as .SECONDARY dependencies, instead
  list none at all, which works as if all files were listed as dependencies.

* Some targets had to move later in the file, since variables used in dependencies:

       foo: $(VARIABLE)

  must be defined before that point in the file, as opposed to variables used in recipes:

       foo:
           $(MAKE) $(VARIABLE)

  can be defined anywhere in the Makefile.

* Simplify the targets that sign assemblies significantly.

There are a few end results:

* It's now possible to do `make install`, without doing `make all` first. This
  might seem weird, but that also ensures the more common `make all install`
  works properly.

* Remakes (without any mono/llvm changes) in build/ are much faster, because
  we now won't recurse into every mono build:

      $ time make all -C builds/ -j8
      [...]
      real  0m1.873s

  This even means that we might be able to make it a habit to remake in the
  root directory, which doesn't take forever now:

      $ time make all -j8
      [...]
      real  0m4.521s

  Unfortunately adding `make install` to the mix still does some useless
  stuff, and it ends up taking ~30 seconds to complete a full build:

      $ time make all install -j8
      [...]
      real  0m32.542s

* [msbuild] Don't verify the xml syntax of targets files unless the files change.

* [build] Don't depend on installed files.

Don't depend on installed files, because that causes a rebuild when installing
to a different directory (i.e. package creation).

* Bump maccore to get build improvements.

Rebuilds are now very fast:

    $ make all install -j8
    $ time make all install -j8
    real	0m5.735s

Less than 6s to figure out that nothing needs to be done.

And strangely flushing the disk cache doesn't make it much slower:

    $ sudo purge
    $ time make all install -j8
    real	0m7.309s

Which probably means that Make mostly reads file metadata, and not actual file
contents (which is good).
2017-03-31 20:23:38 +02:00
Rolf Bjarne Kvinge c4b5fa5f44 [msbuild] Remove support for XI/Classic. (#976)
* [msbuild] Remove unused FrameworkList.xmls

* [msbuild] Make files in /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/msbuild/iOS the real deal, not a symlink.

* [msbuild] Make /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS a symlink, instead of each file inside.

* [msbuild] Don't put anything in /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/2.1 anymore.

* [msbuild] Remove support for XI/Classic binding projects.

* Improve 'install-system' to clean up old files.

* [msbuild] Simplify XI/Classic targets files a bit.

* [msbuild] Remove dead XI/Classic code.

* Bump maccore to get fix for xamarin-analysis.

commit xamarin/maccore@34c04c2bf1
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date:   Mon Oct 10 16:46:18 2016 +0200

    [analysis] Update to put files in /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS.

    XI/Classic is being removed now, which means files should go into
    /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/msbuild/iOS/ instead of into
    /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/2.1.
2016-10-13 10:47:46 +02:00
Emanuel 4f5fc6d263 Enables CoreCompile target for WatchOS App projects (#826)
* Enables CoreCompile target for WatchOS App projects

The iOS Designer depends on Roslyn Workspace APIs to inspect and get notified of project changes, which needs CoreCompile target to work.

Fixes Bug #41766 (https://bugzilla.xamarin.com/show_bug.cgi?id=41766)

* [msbuild] Adds empty cs file to avoid errors and warnings when building watchOS apps

Xbuild fails to build projects with no @(Compile). This change workaround it for watchOS apps.
2016-09-16 14:16:32 -04:00
Rolf Bjarne Kvinge b7570c09d4 [msbuild] Remove debug spew. (#747) 2016-09-02 08:25:52 -04:00
Rolf Bjarne Kvinge ba7cddc34e [msbuild] Add nuget diagnostics. (#255)
* [msbuild] Add nuget diagnostics.

* [msbuild] Make restore less verbose.

To see if that's what's causing an infinite newline print loop on jenkins bots.

* [msbuild] nuget can't list sources on jenkins for some reason, so just do it manually.

* [msbuild] Make sure diagnostics doesn't fail the build.
2016-06-23 06:22:21 -07:00
joj 19b87f2723 Added new Mac.Tasks.Core project; moved tasks with no Core base there 2016-05-26 10:07:59 -03:00
Rolf Bjarne Kvinge 68df944ad6 Build MSBuild targets & assemblies. 2016-04-24 14:48:44 -04:00