[builds] Make the tools build use mono's packaged logic instead of our own. - #5962
Conversation
…r own. Make the 'tools64' build use mono's packaged build logic instead of our own. This is the first step to consuming the BCL from the mono archive. Also completely refactor the 'tools64' build by removing everything we don't need and renaming it to 'bcl' (since that's more representative of what it does).
Move the facade check targets below the declaration of their prerequisite variables (*_BCL_TARGETS), since otherwise the prerequisite variable will be empty when the facade check targets are read by make, they end up with no prerequisites at all, and the targets fail.
|
Build failure |
Before we unzip, we remove the target directory. This is a bad idea if the target directory is also used for other things: in particular it breaks parallel make if some other target tries to write to the temporary directory. Instead unzip downloaded files into a subdirectory exclusively used by those unzipped files, which means we can remove at will before unzipping.
| @@ -328,8 +326,8 @@ $(MAC_DIRECTORIES) $(BUILD_DESTDIR): | |||
| mac-facade-check: $(MAC_BCL_TARGETS) | |||
There was a problem hiding this comment.
We'll need to get rid of the FACADE_SUBDIRS_MK which is included directly from mono sources in https://github.com/xamarin/xamarin-macios/blob/03669d4c030b2313d2037493307e3cb2d4f3bd88/builds/Makefile#L188
There's two options: 1) just include all *.dll in the ios/mac-bcl folders and trust mono to not put unwanted files there 2) hardcode list of assemblies/facades here. Any preferences?
There was a problem hiding this comment.
I think the Xamarin.Linker.SdkTest should cover this scenario, so I think we can just remove the whole facade check from this makefile.
@spouliot what do you think?
There was a problem hiding this comment.
Actually the facade check is just one part of the problem, we'd still need a list of the facade assemblies. Solution 1) won't work when building from source, so I think we need a dual solution: keep the existing code when building from source, and then use solution 1) when we're using the mono archive.
We still have a hard-coded list of facade assemblies elsewhere in our code (in tests), so we'll be notified if new facade assemblies are added to the archive (the corresponding test will start to fail).
|
Build failure |
rolfbjarne
added
the
skip-api-comparison
|
The api comparison failed because the src build is too different from the previous commit: i.e. the failure is expected/can be ignored. |
|
|
||
| $(BUILD_DESTDIR)/ios-bcl/%.dll: $(MONO_IOS_SDK_DESTDIR)/ios-bcl/%.dll | $(TMP_BCL_TARGET_DIRS) | ||
| $(Q) $(CP) $< $@ | ||
| $(Q_SN) MONO_CFG_DIR=$(TOP) $(SYSTEM_SN) -q -R $@ $(PRODUCT_KEY_PATH) |
There was a problem hiding this comment.
do we need to re-sign here? the assemblies from the mono archive should already have the correct signature (if they don't I'd consider that a bug).
There was a problem hiding this comment.
I don't think we do need to re-sign. I'll have a look and put up another PR if that's the case.
…ic instead of our own. (dotnet#5962)" (dotnet#5971)" This reverts commit cb1ead3.
4 participants
Make the 'tools64' build use mono's packaged build logic instead of our own.
This is the first step to consuming the BCL from the mono archive.
Also completely refactor the 'tools64' build by removing everything we don't
need and renaming it to 'bcl' (since that's more representative of what it
does).
This also means we're now consuming the BCL from the mono archive.