2016-06-06 13:18:52 +03:00
|
|
|
TOP=../..
|
2016-04-26 15:00:35 +03:00
|
|
|
include $(TOP)/Make.config
|
|
|
|
|
2021-08-12 13:30:57 +03:00
|
|
|
SUBDIRS += custom-type-assembly frameworks nugets libraries
|
2021-05-18 17:28:09 +03:00
|
|
|
|
2016-04-26 15:00:35 +03:00
|
|
|
# without this many compiler warnings about unused functions and variables
|
|
|
|
# in system headers show up.
|
|
|
|
export CCACHE_CPP2=1
|
|
|
|
|
2021-08-12 13:30:57 +03:00
|
|
|
ifeq ($(V),)
|
|
|
|
ZIP=zip --symlinks --quiet
|
|
|
|
else
|
|
|
|
ZIP=zip --symlinks
|
|
|
|
endif
|
|
|
|
|
2016-10-07 13:48:01 +03:00
|
|
|
GENERATED_FILES = \
|
|
|
|
libtest.structs.h \
|
|
|
|
libtest.decompile.m \
|
|
|
|
libtest.properties.h \
|
|
|
|
../bindings-test/ApiDefinition.generated.cs \
|
|
|
|
../bindings-test/StructsAndEnums.generated.cs \
|
2017-11-06 19:16:32 +03:00
|
|
|
RegistrarTest.generated.cs \
|
|
|
|
TrampolineTest.generated.cs \
|
2016-10-07 13:48:01 +03:00
|
|
|
|
|
|
|
GENERATED_FILES_PATTERN = \
|
|
|
|
libtest.structs%h \
|
|
|
|
libtest.decompile%m \
|
|
|
|
libtest.properties%h \
|
|
|
|
../bindings-test/ApiDefinition.generated%cs \
|
|
|
|
../bindings-test/StructsAndEnums.generated%cs \
|
2017-11-06 19:16:32 +03:00
|
|
|
RegistrarTest.generated%cs \
|
|
|
|
TrampolineTest.generated%cs \
|
2016-10-07 13:48:01 +03:00
|
|
|
|
|
|
|
testgenerator.exe: testgenerator.cs Makefile
|
|
|
|
$(Q) mcs -out:$@ $<
|
|
|
|
|
|
|
|
$(GENERATED_FILES_PATTERN): testgenerator.exe
|
|
|
|
$(Q) mono --debug $<
|
|
|
|
|
2016-04-26 15:00:35 +03:00
|
|
|
libtest-object.m libtest-ar.m:
|
|
|
|
$(Q) ln -fhs libtest.m $@
|
|
|
|
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
MACOS_INFO_PLIST_INFIX=/Versions/A/Resources
|
|
|
|
MACOS_BINARY_INFIX=/Versions/A
|
|
|
|
MACCATALYST_INFO_PLIST_INFIX=/Versions/A/Resources
|
|
|
|
MACCATALYST_BINARY_INFIX=/Versions/A
|
|
|
|
|
|
|
|
define SymlinksTemplate
|
|
|
|
|
|
|
|
$(1)_XTEST_TARGETS += \
|
|
|
|
.libs/$(1)/XTest.framework/XTest \
|
|
|
|
.libs/$(1)/XTest.framework/Resources \
|
|
|
|
.libs/$(1)/XTest.framework/Versions/Current \
|
|
|
|
.libs/$(1)/XTest.framework/Versions/A/Resources/Info.plist \
|
|
|
|
|
|
|
|
.libs/$(1)/XTest.framework$($(2)_BINARY_INFIX) .libs/$(1)/XTest.framework$($(2)_INFO_PLIST_INFIX):
|
|
|
|
$$(Q) mkdir -p $$@
|
|
|
|
|
|
|
|
.libs/$(1)/XTest.framework/XTest: | .libs/$(1)/XTest.framework
|
|
|
|
$$(Q) ln -fs Versions/A/XTest $$@
|
|
|
|
|
|
|
|
.libs/$(1)/XTest.framework/Resources: | .libs/$(1)/XTest.framework
|
|
|
|
$$(Q) ln -fs Versions/Current/Resources $$@
|
|
|
|
|
|
|
|
.libs/$(1)/XTest.framework/Versions/Current: | .libs/$(1)/XTest.framework/Versions
|
|
|
|
$$(Q) ln -fs A $$@
|
|
|
|
|
|
|
|
x::
|
|
|
|
@echo $(1)_XTEST_TARGETS=$$($(1)_XTEST_TARGETS)
|
|
|
|
|
|
|
|
endef
|
|
|
|
ifdef INCLUDE_MAC
|
|
|
|
$(eval $(call SymlinksTemplate,macos,MACOS))
|
|
|
|
endif
|
|
|
|
ifdef INCLUDE_MACCATALYST
|
|
|
|
$(eval $(call SymlinksTemplate,maccatalyst,MACCATALYST))
|
|
|
|
endif
|
|
|
|
|
2016-04-26 15:00:35 +03:00
|
|
|
define Template
|
|
|
|
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
$(1)_XTEST_TARGETS += \
|
|
|
|
.libs/$(1)/XTest.framework$($(2)_BINARY_INFIX)/XTest \
|
|
|
|
.libs/$(1)/XTest.framework$($(2)_INFO_PLIST_INFIX)/Info.plist \
|
|
|
|
|
2016-04-26 15:00:35 +03:00
|
|
|
$(2)_TARGETS = \
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
$$($(1)_XTEST_TARGETS) \
|
2016-04-26 15:00:35 +03:00
|
|
|
.libs/$(1)/XStaticObjectTest.framework/XStaticObjectTest \
|
|
|
|
.libs/$(1)/XStaticArTest.framework/XStaticArTest \
|
|
|
|
.libs/$(1)/libtest.dylib \
|
2017-01-26 15:38:39 +03:00
|
|
|
.libs/$(1)/libtest2.a \
|
2016-04-26 15:00:35 +03:00
|
|
|
.libs/$(1)/libtest.a \
|
|
|
|
.libs/$(1)/libtest-object.a \
|
|
|
|
.libs/$(1)/libtest-ar.a \
|
|
|
|
$$(foreach arch,$(3),.libs/$(1)/libtest.$$(arch).a) \
|
|
|
|
$$(foreach arch,$(3),.libs/$(1)/libtest-object.$$(arch).a) \
|
|
|
|
$$(foreach arch,$(3),.libs/$(1)/libtest-ar.$$(arch).a) \
|
|
|
|
.libs/$(1)/XTest.framework \
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
.libs/$(1)/XTest.framework.stamp \
|
2016-04-26 15:00:35 +03:00
|
|
|
|
2016-10-07 13:48:01 +03:00
|
|
|
all-local:: $$($(2)_TARGETS) $(GENERATED_FILES)
|
2016-04-26 15:00:35 +03:00
|
|
|
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
.libs/$(1)/XTest.framework.stamp: $$($(1)_XTEST_TARGETS)
|
|
|
|
$$(Q) touch $$@
|
|
|
|
|
2016-04-26 15:00:35 +03:00
|
|
|
clean-$(1):
|
|
|
|
rm -Rf .libs/$(1)
|
|
|
|
|
|
|
|
CLEAN_TARGETS += clean-$(1)
|
Optimize calls to BlockLiteral.SetupBlock to inject the block signature. (#3391)
* [linker] Optimize calls to BlockLiteral.SetupBlock to inject the block signature.
Optimize calls to BlockLiteral.SetupBlock[Unsafe] to calculate the block
signature at build time, and inject it into the call site.
This makes block invocations 10-15x faster (I've added tests that asserts at
least an 8x increase).
It's also required in order to be able to remove the dynamic registrar code in
the future (since calculating the block signature at runtime requires the
dynamic registrar).
* [mtouch/mmp] Add support for reporting errors/warnings that point to the code line causing the error/warning.
Add support for reporting errors/warnings that point to the code line causing
the error/warning by adding ErrorHelper overloads that take the exact
instruction to report (previously we defaulted to the first line/instruction
in a method).
* [tests] Add support for asserting filename/linenumber in warning messages.
* Make all methods that manually create BlockLiterals optimizable.
* [tests] Create a BaseOptimizeGeneratedCodeTest test that's included in both XI's and XM's link all test.
* [tests] Add link all test (for both XI and XM) to test the BlockLiteral.SetupBlock optimization.
* [tests] Add mtouch/mmp tests for the BlockLiteral.SetupBlock optimization.
* [tests][linker] Make the base test class abstract, so tests in the base class aren't executed twice.
* [tests][linker] Don't execute linkall-only tests in linksdk.
The optimization tests only apply when the test assembly is linked, and that
only happens in linkall, so exclude those tests in linksdk.
* [tests][mmptest] Update test according to mmp changes.
Fixes these test failures:
1) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("inline-runtime-arch")
The warning 'MM0132: Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
2) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("foo")
The warning 'MM0132: Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
* [tests][linker] Fix typo.
Fixes this test failure:
1) SetupBlock_CustomDelegate (Linker.Shared.BaseOptimizeGeneratedCodeTest.SetupBlock_CustomDelegate)
Counter
Expected: 1
But was: 2
* [registrar] Minor adjustment to error message to match previous (and better) behavior.
Fixes this test failure:
1) Failed : Xamarin.Registrar.GenericType_WithInvalidParameterTypes
The error 'MT4136: The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)'' was not found in the output:
Message #1 did not match:
actual: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<Foundation.NSObject>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
expected: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
* [docs] mmp shows MM errors/warnings.
* [docs] Improve according to reviews.
* [tests] Fix merge failure causing test duplication.
2018-02-06 09:08:15 +03:00
|
|
|
EXTRA_DEPENDENCIES = libtest.h $(GENERATED_FILES) rename.h
|
2016-04-26 15:00:35 +03:00
|
|
|
|
|
|
|
.libs/$(1)/libtest-object.%.o: export EXTRA_DEFINES=-DPREFIX=1
|
|
|
|
.libs/$(1)/libtest-ar.%.o: export EXTRA_DEFINES=-DPREFIX=2
|
|
|
|
|
|
|
|
.libs/$(1)/libtest%.a: .libs/$(1)/libtest%.o libtest-object.m libtest-ar.m
|
|
|
|
$(Q) rm -f $$@
|
2020-07-23 16:37:39 +03:00
|
|
|
$$(call Q_2,AR [$(1)]) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar cru $$@ $$<
|
2016-04-26 15:00:35 +03:00
|
|
|
|
2017-01-18 12:25:58 +03:00
|
|
|
.libs/$(1)/libtest.a: $$(foreach arch,$(3),.libs/$(1)/libtest.$$(arch).a)
|
2016-04-26 15:00:35 +03:00
|
|
|
$(Q) rm -f $$@
|
|
|
|
$$(call Q_2,LIPO [$(1)]) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo $$^ -create -output $$@
|
|
|
|
|
2017-01-26 15:38:39 +03:00
|
|
|
.libs/$(1)/libtest2.a: $$(foreach arch,$(3),.libs/$(1)/libtest2.$$(arch).a)
|
|
|
|
$(Q) rm -f $$@
|
|
|
|
$$(call Q_2,LIPO [$(1)]) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo $$^ -create -output $$@
|
|
|
|
|
2017-01-18 12:25:58 +03:00
|
|
|
.libs/$(1)/libtest-object.a: $$(foreach arch,$(3),.libs/$(1)/libtest-object.$$(arch).a)
|
2016-04-26 15:00:35 +03:00
|
|
|
$(Q) rm -f $$@
|
|
|
|
$$(call Q_2,LIPO [$(1)]) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo $$^ -create -output $$@
|
|
|
|
|
2017-01-18 12:25:58 +03:00
|
|
|
.libs/$(1)/libtest-ar.a: $$(foreach arch,$(3),.libs/$(1)/libtest-ar.$$(arch).a)
|
2016-04-26 15:00:35 +03:00
|
|
|
$(Q) rm -f $$@
|
|
|
|
$$(call Q_2,LIPO [$(1)]) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo $$^ -create -output $$@
|
|
|
|
|
|
|
|
COMMON_DYLIB_ARGS=-g -dynamiclib -gdwarf-2 -fms-extensions libframework.m -o $$@ -Wall -framework Foundation -lz
|
2020-05-12 17:38:05 +03:00
|
|
|
.libs/$(1)/libtest.x86.dylib: ARCH=i386
|
2021-03-03 09:48:07 +03:00
|
|
|
.libs/$(1)/libtest.%.dylib: libframework.m | .libs/$(1)
|
|
|
|
$$(call Q_2,CC, [$(1)]) $$(XCODE_CC) $$(COMMON_DYLIB_ARGS) -arch $$(if $$(ARCH),$$(ARCH),$$*) $(5) $$($(2)_$$(shell echo $$* | tr a-z A-Z)_OBJC_CFLAGS)
|
2021-05-13 19:45:48 +03:00
|
|
|
$$(Q) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool -id @rpath/libtest.dylib $$@
|
2021-03-03 09:48:07 +03:00
|
|
|
|
|
|
|
## The following arm64_32 rule is required for this to work with newer make versions, otherwise a rule in mk/rules.mk is chosen instead.
|
|
|
|
## The problem is that 'arm64_32' is longer than 'libtest', the former is a stem in the rule just above, while the latter is a rule in mk/rules.mk,
|
|
|
|
## and in newer make versions make will choose the rule that matches the shorter stem.
|
|
|
|
.libs/$(1)/libtest.arm64_32.dylib: libframework.m | .libs/$(1)
|
|
|
|
$$(call Q_2,CC, [$(1)]) $$(XCODE_CC) $$(COMMON_DYLIB_ARGS) -arch arm64_32 $(5) $$($(2)_$$(shell echo $$* | tr a-z A-Z)_OBJC_CFLAGS)
|
2021-05-13 19:45:48 +03:00
|
|
|
$$(Q) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool -id @rpath/libtest.dylib $$@
|
2016-04-26 15:00:35 +03:00
|
|
|
|
2019-10-03 17:38:44 +03:00
|
|
|
.libs/$(1)/libtest.dylib: $$(foreach arch,$(3),.libs/$(1)/libtest.$$(arch).dylib)
|
2016-04-26 15:00:35 +03:00
|
|
|
$$(call Q_2,LIPO [$(1)]) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo $$^ -create -output $$@
|
|
|
|
|
|
|
|
# XTest is a framework where the binary code is a (fat) dynamic library
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
.libs/$(1)/XTest.framework$($(2)_BINARY_INFIX)/XTest: .libs/$(1)/libtest.dylib | .libs/$(1)/XTest.framework$($(2)_BINARY_INFIX)
|
2018-10-29 18:09:30 +03:00
|
|
|
$$(Q) $(CP) $$^ $$@
|
2021-05-13 19:45:48 +03:00
|
|
|
$$(Q) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool -id @rpath/XTest.framework/XTest $$@
|
2016-04-26 15:00:35 +03:00
|
|
|
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
.libs/$(1)/XTest.framework$($(2)_INFO_PLIST_INFIX)/Info.plist: XTest-Info-$(1).plist | .libs/$(1)/XTest.framework$($(2)_INFO_PLIST_INFIX)
|
2018-10-29 18:09:30 +03:00
|
|
|
$$(Q) $(CP) $$^ $$@
|
2016-04-26 15:00:35 +03:00
|
|
|
|
|
|
|
# XStaticObjectTest is a framework where the binary code is a (fat) object file
|
|
|
|
.libs/$(1)/XStaticObjectTest.framework/XStaticObjectTest: $$(foreach arch,$(3),.libs/$(1)/libtest-object.$$(arch).o) | .libs/$(1)/XStaticObjectTest.framework
|
|
|
|
$(Q) rm -f $$@
|
|
|
|
$$(call Q_2,LIPO [$(1)]) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo $$^ -create -output $$@
|
|
|
|
|
|
|
|
# XStaticArTest is a framework where the binary code is a (fat) ar archive (of object files)
|
|
|
|
.libs/$(1)/XStaticArTest.framework/XStaticArTest: $$(foreach arch,$(3),.libs/$(1)/libtest-ar.$$(arch).a) | .libs/$(1)/XStaticArTest.framework
|
|
|
|
$(Q) rm -f $$@
|
|
|
|
$$(call Q_2,LIPO [$(1)]) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo $$^ -create -output $$@
|
|
|
|
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
$(1)_DIRECTORIES = \
|
|
|
|
.libs/$(1)/XTest.framework \
|
|
|
|
.libs/$(1)/XTest.framework/Versions \
|
|
|
|
.libs/$(1)/XStaticObjectTest.framework \
|
|
|
|
.libs/$(1)/XStaticArTest.framework \
|
|
|
|
|
|
|
|
$$($(1)_DIRECTORIES):
|
2016-04-26 15:00:35 +03:00
|
|
|
$$(Q) mkdir -p $$@
|
|
|
|
|
|
|
|
endef
|
|
|
|
|
2019-10-03 17:38:44 +03:00
|
|
|
# 1: platform infix
|
|
|
|
# 2: platform variable
|
|
|
|
# 3: architectures
|
|
|
|
# 4: platform name
|
|
|
|
# 5: min version
|
|
|
|
# 6: os
|
2021-11-24 00:02:02 +03:00
|
|
|
$(eval $(call Template,iphonesimulator,IOSSIMULATOR,x86 x86_64 arm64,iPhoneSimulator,-mios-simulator-version-min=8.0 -isysroot $(SIMULATOR_SDK)))
|
2020-12-17 20:53:16 +03:00
|
|
|
$(eval $(call Template,iphoneos,IPHONEOS,armv7 armv7s arm64,iPhoneOS,-miphoneos-version-min=8.0 -isysroot $(DEVICE_SDK)))
|
2016-04-26 15:00:35 +03:00
|
|
|
ifdef INCLUDE_TVOS
|
2021-11-24 00:02:02 +03:00
|
|
|
$(eval $(call Template,tvsimulator,TVSIMULATOR,x86_64 arm64,AppleTVSimulator,-mtvos-simulator-version-min=9.0 -isysroot $(SIMULATORTV_SDK)))
|
2020-12-17 20:53:16 +03:00
|
|
|
$(eval $(call Template,tvos,TVOS,arm64,AppleTVOS,-mtvos-version-min=9.0 -fembed-bitcode -isysroot $(DEVICETV_SDK)))
|
2016-04-26 15:00:35 +03:00
|
|
|
endif
|
|
|
|
ifdef INCLUDE_WATCH
|
2020-12-17 20:53:16 +03:00
|
|
|
$(eval $(call Template,watchsimulator,WATCHSIMULATOR,x86 x86_64,WatchSimulator,-mwatchos-simulator-version-min=2.0 -isysroot $(SIMULATORWATCH_SDK)))
|
|
|
|
$(eval $(call Template,watchos,WATCHOS,armv7k arm64_32,WatchOS,-mwatchos-version-min=2.0 -fembed-bitcode -isysroot $(DEVICEWATCH_SDK)))
|
2016-04-26 15:00:35 +03:00
|
|
|
endif
|
2018-02-02 13:14:44 +03:00
|
|
|
ifdef INCLUDE_MAC
|
2021-11-22 20:48:05 +03:00
|
|
|
$(eval $(call Template,macos,MACOS,x86_64 arm64,MacOSX,-mmacosx-version-min=$(MIN_OSX_VERSION_FOR_MAC) -isysroot $(XCODE_DEVELOPER_ROOT)/Platforms/MacOSX.platform/Developer/SDKs/MacOSX$(MACOS_SDK_VERSION).sdk))
|
2020-12-17 20:53:16 +03:00
|
|
|
endif
|
|
|
|
ifdef INCLUDE_MACCATALYST
|
2021-03-03 09:48:07 +03:00
|
|
|
$(eval $(call Template,maccatalyst,MACCATALYST,x86_64 arm64,MacCatalyst,$(MACCATALYST_COMMON_CFLAGS)))
|
2018-02-02 13:14:44 +03:00
|
|
|
endif
|
2016-04-26 15:00:35 +03:00
|
|
|
|
2021-04-29 14:41:52 +03:00
|
|
|
.libs/ios-fat .libs/tvos-fat .libs/watchos-fat .libs/maccatalyst-fat .libs/macos-fat:
|
2019-10-03 17:38:44 +03:00
|
|
|
$(Q) mkdir -p $@
|
2016-04-26 15:00:35 +03:00
|
|
|
|
2019-10-03 17:38:44 +03:00
|
|
|
define LibTemplate
|
|
|
|
.libs/$(4)/libtest.$(1).a: $(2) $(3) | .libs/$(4)
|
2016-04-26 15:00:35 +03:00
|
|
|
@rm -f $$@
|
|
|
|
$$(Q_LIPO) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo $$^ -create -output $$@
|
|
|
|
|
|
|
|
$(5)_TARGETS += .libs/$(4)/libtest.$(1).a
|
2019-10-03 17:38:44 +03:00
|
|
|
all-local:: $$($(5)_TARGETS)
|
2016-04-26 15:00:35 +03:00
|
|
|
endef
|
|
|
|
|
2019-10-03 17:38:44 +03:00
|
|
|
$(eval $(call LibTemplate,armv7+7s,.libs/iphoneos/libtest.armv7.o,.libs/iphoneos/libtest.armv7s.o,ios-fat,IOS))
|
|
|
|
$(eval $(call LibTemplate,armv7+x86,.libs/iphoneos/libtest.armv7.o,.libs/iphonesimulator/libtest.x86.o,ios-fat,IOS))
|
|
|
|
$(eval $(call LibTemplate,armv7s+x86,.libs/iphoneos/libtest.armv7s.o,.libs/iphonesimulator/libtest.x86.o,ios-fat,IOS))
|
|
|
|
|
2021-04-30 08:51:58 +03:00
|
|
|
ifdef INCLUDE_TVOS
|
2019-10-03 17:38:44 +03:00
|
|
|
$(eval $(call LibTemplate,arm64+x86_64,.libs/tvos/libtest.arm64.o,.libs/tvsimulator/libtest.x86_64.o,tvos-fat,TVOS))
|
2021-04-30 08:51:58 +03:00
|
|
|
endif
|
2019-10-03 17:38:44 +03:00
|
|
|
|
2021-04-30 08:51:58 +03:00
|
|
|
ifdef INCLUDE_WATCH
|
2019-10-03 17:38:44 +03:00
|
|
|
$(eval $(call LibTemplate,armv7k+x86,.libs/watchos/libtest.armv7k.o,.libs/watchsimulator/libtest.x86.o,watchos-fat,WATCHOS))
|
2021-04-30 08:51:58 +03:00
|
|
|
endif
|
2019-10-03 17:38:44 +03:00
|
|
|
|
2021-04-30 08:51:58 +03:00
|
|
|
ifdef INCLUDE_MACCATALYST
|
2021-03-03 09:48:07 +03:00
|
|
|
$(eval $(call LibTemplate,x86_64+arm64,.libs/maccatalyst/libtest.x86_64.o,.libs/maccatalyst/libtest.arm64.o,maccatalyst-fat,MACCATALYST))
|
2021-04-30 08:51:58 +03:00
|
|
|
endif
|
2020-12-17 20:53:16 +03:00
|
|
|
|
2021-04-29 14:41:52 +03:00
|
|
|
ifdef INCLUDE_MAC
|
|
|
|
$(eval $(call LibTemplate,x86_64+arm64,.libs/macos/libtest.x86_64.o,.libs/macos/libtest.arm64.o,macos-fat,MACOS))
|
|
|
|
endif
|
|
|
|
|
2019-10-03 17:38:44 +03:00
|
|
|
define FatFrameworkTemplate
|
|
|
|
.libs/$(1)/XStaticObjectTest.framework/XStaticObjectTest: .libs/$(2)/XStaticObjectTest.framework/XStaticObjectTest .libs/$(3)/XStaticObjectTest.framework/XStaticObjectTest | .libs/$(1)
|
|
|
|
$(Q) mkdir -p $$(dir $$@)
|
2021-11-24 00:02:02 +03:00
|
|
|
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
|
2019-10-03 17:38:44 +03:00
|
|
|
|
|
|
|
.libs/$(1)/XStaticArTest.framework/XStaticArTest: .libs/$(2)/XStaticArTest.framework/XStaticArTest .libs/$(3)/XStaticArTest.framework/XStaticArTest | .libs/$(1)
|
|
|
|
$(Q) mkdir -p $$(dir $$@)
|
2021-11-24 00:02:02 +03:00
|
|
|
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
|
2019-10-03 17:38:44 +03:00
|
|
|
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
.libs/$(1)/XTest.framework$($(4)_BINARY_INFIX)/XTest: .libs/$(2)/XTest.framework$($(4)_BINARY_INFIX)/XTest .libs/$(3)/XTest.framework$($(4)_BINARY_INFIX)/XTest | .libs/$(1)
|
2019-10-03 17:38:44 +03:00
|
|
|
$(Q) mkdir -p $$(dir $$@)
|
2021-11-24 00:02:02 +03:00
|
|
|
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
|
2016-04-26 15:00:35 +03:00
|
|
|
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
.libs/$(1)/XTest.framework$($(4)_INFO_PLIST_INFIX)/Info.plist: .libs/$(2)/XTest.framework$($(4)_INFO_PLIST_INFIX)/Info.plist .libs/$(3)/XTest.framework$($(4)_INFO_PLIST_INFIX)/Info.plist
|
2019-10-03 17:38:44 +03:00
|
|
|
$(Q) mkdir -p $$(dir $$@)
|
2020-12-17 20:53:16 +03:00
|
|
|
ifneq ($(2),$(3))
|
2019-10-03 17:38:44 +03:00
|
|
|
@# Check if the Info.plists are identical
|
|
|
|
$(Q) diff $$^
|
2020-12-17 20:53:16 +03:00
|
|
|
endif
|
2019-10-03 17:38:44 +03:00
|
|
|
@# Copy one of them
|
|
|
|
$(Q) $(CP) $$< $$@
|
|
|
|
|
|
|
|
.libs/$(1)/libtest.a: .libs/$(2)/libtest.a .libs/$(3)/libtest.a | .libs/$(1)
|
2021-11-24 00:02:02 +03:00
|
|
|
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
|
2019-10-03 17:38:44 +03:00
|
|
|
|
|
|
|
.libs/$(1)/libtest2.a: .libs/$(2)/libtest2.a .libs/$(3)/libtest2.a | .libs/$(1)
|
2021-11-24 00:02:02 +03:00
|
|
|
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
|
2019-10-03 17:38:44 +03:00
|
|
|
|
2021-05-13 19:45:48 +03:00
|
|
|
.libs/$(1)/libtest.dylib: .libs/$(2)/libtest.dylib .libs/$(3)/libtest.dylib | .libs/$(1)
|
2021-11-24 00:02:02 +03:00
|
|
|
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
|
2021-05-13 19:45:48 +03:00
|
|
|
|
2021-09-27 17:56:49 +03:00
|
|
|
$(4)_TARGETS += \
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
.libs/$(1)/XTest.framework$($(4)_BINARY_INFIX)/XTest \
|
|
|
|
.libs/$(1)/XTest.framework$($(4)_INFO_PLIST_INFIX)/Info.plist \
|
2019-10-03 17:38:44 +03:00
|
|
|
.libs/$(1)/XStaticObjectTest.framework/XStaticObjectTest \
|
|
|
|
.libs/$(1)/XStaticArTest.framework/XStaticArTest \
|
2021-05-13 19:45:48 +03:00
|
|
|
.libs/$(1)/libtest.dylib \
|
2019-10-03 17:38:44 +03:00
|
|
|
.libs/$(1)/libtest.a \
|
|
|
|
.libs/$(1)/libtest2.a \
|
|
|
|
|
2021-09-27 17:56:49 +03:00
|
|
|
all-local:: $$($(4)_TARGETS)
|
2019-10-03 17:38:44 +03:00
|
|
|
endef
|
2016-04-26 15:00:35 +03:00
|
|
|
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
$(eval $(call FatFrameworkTemplate,ios-fat,iphoneos,iphonesimulator,IPHONESIMULATOR))
|
2021-04-30 08:51:58 +03:00
|
|
|
ifdef INCLUDE_TVOS
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
$(eval $(call FatFrameworkTemplate,tvos-fat,tvos,tvsimulator,TVSIMULATOR))
|
2021-04-30 08:51:58 +03:00
|
|
|
endif
|
|
|
|
ifdef INCLUDE_WATCH
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
$(eval $(call FatFrameworkTemplate,watchos-fat,watchos,watchsimulator,WATCHSIMULATOR))
|
|
|
|
endif
|
|
|
|
ifdef INCLUDE_MACCATALYST
|
|
|
|
$(eval $(call FatFrameworkTemplate,maccatalyst-fat,maccatalyst,maccatalyst,MACCATALYST))
|
|
|
|
endif
|
|
|
|
ifdef INCLUDE_MAC
|
|
|
|
$(eval $(call FatFrameworkTemplate,macos-fat,macos,macos,MACOS))
|
2021-04-30 08:51:58 +03:00
|
|
|
endif
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
|
|
|
|
define FatFrameworkSymlinksTemplate
|
|
|
|
.libs/$(1)/XTest.framework/XTest: | .libs/$(1)
|
|
|
|
$(Q) mkdir -p $$(dir $$@)
|
|
|
|
$(Q) ln -fs Versions/A/XTest $$@
|
|
|
|
|
|
|
|
.libs/$(1)/XTest.framework/Resources: | .libs/$(1)
|
|
|
|
$(Q) mkdir -p $$(dir $$@)
|
|
|
|
$(Q) ln -fs Versions/A/Resources $$@
|
|
|
|
|
|
|
|
.libs/$(1)/XTest.framework/Versions/Current: | .libs/$(1)
|
|
|
|
$(Q) mkdir -p $$(dir $$@)
|
|
|
|
$(Q) ln -fs A $$@
|
|
|
|
|
2021-09-27 17:56:49 +03:00
|
|
|
$(4)_TARGETS += \
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
.libs/$(1)/XTest.framework/XTest \
|
|
|
|
.libs/$(1)/XTest.framework/Resources \
|
|
|
|
.libs/$(1)/XTest.framework/Versions/Current \
|
|
|
|
|
2021-09-27 17:56:49 +03:00
|
|
|
all-local:: $$($(4)_TARGETS)
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
endef
|
|
|
|
|
2021-04-30 08:51:58 +03:00
|
|
|
ifdef INCLUDE_MACCATALYST
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
$(eval $(call FatFrameworkSymlinksTemplate,maccatalyst-fat,maccatalyst,maccatalyst,MACCATALYST))
|
2021-04-30 08:51:58 +03:00
|
|
|
endif
|
2021-04-29 14:41:52 +03:00
|
|
|
ifdef INCLUDE_MAC
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
$(eval $(call FatFrameworkSymlinksTemplate,macos-fat,macos,macos,MACOS))
|
2021-04-29 14:41:52 +03:00
|
|
|
endif
|
2016-04-26 15:00:35 +03:00
|
|
|
|
2021-04-30 08:51:58 +03:00
|
|
|
ifdef INCLUDE_IOS
|
|
|
|
XCPLATFORMS+= iphoneos iphonesimulator
|
|
|
|
endif
|
|
|
|
ifdef INCLUDE_TVOS
|
|
|
|
XCPLATFORMS+= tvos tvsimulator
|
|
|
|
endif
|
|
|
|
ifdef INCLUDE_WATCH
|
|
|
|
XCPLATFORMS+= watchos watchsimulator
|
|
|
|
endif
|
2020-11-30 21:44:03 +03:00
|
|
|
ifdef INCLUDE_MAC
|
|
|
|
XCPLATFORMS+= macos
|
|
|
|
endif
|
2020-12-17 20:53:16 +03:00
|
|
|
ifdef INCLUDE_MACCATALYST
|
|
|
|
XCPLATFORMS+= maccatalyst
|
|
|
|
endif
|
2020-11-30 21:44:03 +03:00
|
|
|
|
2021-08-12 13:30:57 +03:00
|
|
|
define ZippedFrameworkTemplate
|
|
|
|
.libs/$(1)/XTest.framework.zip: $$($(2)_TARGETS)
|
|
|
|
$$(Q_ZIP) cd .libs/$(1) && $(ZIP) -r XTest.framework.zip XTest.framework
|
|
|
|
|
|
|
|
ZIPPED_TARGETS += .libs/$(1)/XTest.framework.zip
|
|
|
|
endef
|
|
|
|
|
|
|
|
ifdef INCLUDE_IOS
|
|
|
|
$(eval $(call ZippedFrameworkTemplate,ios-fat,IPHONESIMULATOR))
|
|
|
|
endif
|
|
|
|
ifdef INCLUDE_TVOS
|
|
|
|
$(eval $(call ZippedFrameworkTemplate,tvos-fat,TVSIMULATOR))
|
|
|
|
endif
|
|
|
|
ifdef INCLUDE_WATCH
|
|
|
|
$(eval $(call ZippedFrameworkTemplate,watchos-fat,WATCHSIMULATOR))
|
|
|
|
endif
|
|
|
|
ifdef INCLUDE_MACCATALYST
|
|
|
|
$(eval $(call ZippedFrameworkTemplate,maccatalyst-fat,MACCATALYST))
|
|
|
|
endif
|
|
|
|
ifdef INCLUDE_MAC
|
|
|
|
$(eval $(call ZippedFrameworkTemplate,macos-fat,MACOS))
|
|
|
|
endif
|
|
|
|
|
|
|
|
all-local:: $(ZIPPED_TARGETS)
|
|
|
|
zip: $(ZIPPED_TARGETS)
|
|
|
|
|
2020-11-30 21:44:03 +03:00
|
|
|
XTEST_XCFRAMEWORKS += $(foreach platform,$(XCPLATFORMS),.libs/$(platform)/XTest.framework)
|
|
|
|
XTEST_XCTARGETS += \
|
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 10:11:25 +03:00
|
|
|
$(foreach platform,$(XCPLATFORMS),.libs/$(platform)/XTest.framework.stamp) \
|
2020-11-30 21:44:03 +03:00
|
|
|
|
|
|
|
.libs/XTest.xcframework: $(XTEST_XCTARGETS) Makefile
|
|
|
|
$(Q) rm -rf $@
|
|
|
|
$(Q_GEN) $(XCODE_DEVELOPER_ROOT)/usr/bin/xcodebuild -quiet -create-xcframework $(foreach fw,$(XTEST_XCFRAMEWORKS),-framework $(fw)) -output $@
|
|
|
|
|
|
|
|
all-local:: .libs/XTest.xcframework
|
|
|
|
|
2021-11-30 20:19:22 +03:00
|
|
|
LIBTEST_XCFRAMEWORKS += $(foreach platform,$(XCPLATFORMS),.libs/$(platform)/libtest.a)
|
|
|
|
|
|
|
|
.libs/libtest.xcframework: $(LIBTEST_XCFRAMEWORKS) Makefile
|
|
|
|
$(Q) rm -rf $@
|
|
|
|
$(Q_GEN) $(XCODE_DEVELOPER_ROOT)/usr/bin/xcodebuild -quiet -create-xcframework $(foreach lib,$(LIBTEST_XCFRAMEWORKS),-library $(lib)) -output $@
|
|
|
|
|
|
|
|
all-local:: .libs/libtest.xcframework
|
|
|
|
|
|
|
|
LIBTEST2_XCFRAMEWORKS += $(foreach platform,$(XCPLATFORMS),.libs/$(platform)/libtest2.a)
|
|
|
|
|
|
|
|
.libs/libtest2.xcframework: $(LIBTEST2_XCFRAMEWORKS) Makefile
|
|
|
|
$(Q) rm -rf $@
|
|
|
|
$(Q_GEN) $(XCODE_DEVELOPER_ROOT)/usr/bin/xcodebuild -quiet -create-xcframework $(foreach lib,$(LIBTEST2_XCFRAMEWORKS),-library $(lib)) -output $@
|
|
|
|
|
|
|
|
all-local:: .libs/libtest2.xcframework
|
|
|
|
|
2021-08-12 13:30:57 +03:00
|
|
|
.libs/XTest.xcframework.zip: .libs/XTest.xcframework
|
|
|
|
$(Q_ZIP) cd .libs && $(ZIP) -r "$(notdir $@)" "$(notdir $<)"
|
|
|
|
|
|
|
|
all-local:: .libs/XTest.xcframework.zip
|
|
|
|
|
2018-02-02 13:14:44 +03:00
|
|
|
# Xamarin.Mac
|
|
|
|
|
|
|
|
MAC_CLANG = DEVELOPER_DIR=$(XCODE_DEVELOPER_ROOT) $(MAC_CC)
|
|
|
|
MAC_OBJC_CFLAGS=-ObjC++ -std=c++0x -fno-exceptions
|
2021-11-22 20:48:05 +03:00
|
|
|
MAC_CFLAGS = -mmacosx-version-min=$(MIN_MACOS_SDK_VERSION) -Wall -DMONOMAC -g
|
|
|
|
MAC_LDFLAGS = -mmacosx-version-min=$(MIN_MACOS_SDK_VERSION) -framework AppKit
|
2018-02-02 13:14:44 +03:00
|
|
|
|
|
|
|
.libs/macos/libtest.%.o: libtest.m $(EXTRA_DEPENDENCIES) | .libs/macos
|
|
|
|
$(call Q_2,OBJC, [mac]) $(MAC_CLANG) -arch $* -c $(MAC_OBJC_CFLAGS) $(MAC_CFLAGS) -o $@ $<
|
|
|
|
|
|
|
|
.libs/macos/libtest-object.%.o: libtest.m $(EXTRA_DEPENDENCIES) | .libs/macos
|
|
|
|
$(call Q_2,OBJC, [mac]) $(MAC_CLANG) -arch $* -c $(MAC_OBJC_CFLAGS) $(MAC_CFLAGS) -o $@ $< -DPREFIX=1
|
|
|
|
|
|
|
|
.libs/macos/libtest-ar.%.o: libtest.m $(EXTRA_DEPENDENCIES) | .libs/macos
|
|
|
|
$(call Q_2,OBJC, [mac]) $(MAC_CLANG) -arch $* -c $(MAC_OBJC_CFLAGS) $(MAC_CFLAGS) -o $@ $< -DPREFIX=2
|
|
|
|
|
|
|
|
.libs/macos/libtest2.%.o: libtest2.m $(EXTRA_DEPENDENCIES) | .libs/macos
|
|
|
|
$(call Q_2,OBJC, [mac]) $(MAC_CLANG) -arch $* -c $(MAC_OBJC_CFLAGS) $(MAC_CFLAGS) -o $@ $<
|
|
|
|
|
|
|
|
.libs/macos:
|
|
|
|
$(Q) mkdir -p $@
|
|
|
|
|
2016-04-26 15:00:35 +03:00
|
|
|
clean-local:: $(CLEAN_TARGETS)
|
|
|
|
|
|
|
|
include $(TOP)/mk/rules.mk
|
2020-05-12 17:38:05 +03:00
|
|
|
|
|
|
|
.SECONDARY:
|