xamarin
/
xamarin-macios
зеркало из
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
xamarin-macios/tests/test-libraries/Makefile

382 строки
15 KiB
Makefile
Исходник Обычный вид История

Make logic not depend on the checkout directory being named 'xamarin-macios'. (#129)
2016-06-06 13:18:52 +03:00
TOP=../..
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
include $(TOP)/Make.config
[Runtime] Don't skip dynamic user type checking as long as dynamic registration is supported. (#11588) When checking whether a type is a user type or not, we might have to do a dynamic check if the dynamic registrar is available. Otherwise we may run into a situation where the static registrar ran during the app build, but then the app loaded additional assemblies at runtime, and those assemblies contained user types that were registered using the dynamic registrar, so the static registrar doesn't know about those custom types (in other words: we need to check at runtime).
2021-05-18 17:28:09 +03:00
SUBDIRS += custom-type-assembly
[tests] Add test-libraries.
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
[tests] Generate some trampoline and registrar tests. Generate trampoline and registrar tests that tests if a return type requires objc_msgSend or objc_msgSend_stret. Now it's much easier to test new return types (a single line of code), which avoids a _lot_ of copy-pasting, and makes sure all the different variations are tested properly. These new tests found several bugs, which are fixed in subsequent commits.
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 \
[monotouch-test] Move generated files out of the "all test files" wildcard. (#2958) monotouch-test has a wildcard to automatically include new test files, but this should not include generated files, because: * The generated files are generated when needed, which means we can't rely on the wildcard to trigger their generation, because the wildcard won't find them before they exist, and as such msbuild won't detect that they're needed. * This means the generated files must be listed separately, but in that case they shouldn't be found by the wildcard too, because that leads to: /Library/Frameworks/Mono.framework/Versions/5.4.0/lib/mono/msbuild/15.0/bin/Roslyn/Microsoft.CSharp.Core.targets(84,5): error MSB3105: The item "ObjCRuntime/TrampolineTest.generated.cs" was specified more than once in the "Sources" parameter. Duplicate items are not supported by the "Sources" parameter. So move the generated files to a different directory, so that the wildcard doesn't find them.
2017-11-06 19:16:32 +03:00
RegistrarTest.generated.cs \
TrampolineTest.generated.cs \
[tests] Generate some trampoline and registrar tests. Generate trampoline and registrar tests that tests if a return type requires objc_msgSend or objc_msgSend_stret. Now it's much easier to test new return types (a single line of code), which avoids a _lot_ of copy-pasting, and makes sure all the different variations are tested properly. These new tests found several bugs, which are fixed in subsequent commits.
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 \
[monotouch-test] Move generated files out of the "all test files" wildcard. (#2958) monotouch-test has a wildcard to automatically include new test files, but this should not include generated files, because: * The generated files are generated when needed, which means we can't rely on the wildcard to trigger their generation, because the wildcard won't find them before they exist, and as such msbuild won't detect that they're needed. * This means the generated files must be listed separately, but in that case they shouldn't be found by the wildcard too, because that leads to: /Library/Frameworks/Mono.framework/Versions/5.4.0/lib/mono/msbuild/15.0/bin/Roslyn/Microsoft.CSharp.Core.targets(84,5): error MSB3105: The item "ObjCRuntime/TrampolineTest.generated.cs" was specified more than once in the "Sources" parameter. Duplicate items are not supported by the "Sources" parameter. So move the generated files to a different directory, so that the wildcard doesn't find them.
2017-11-06 19:16:32 +03:00
RegistrarTest.generated%cs \
TrampolineTest.generated%cs \
[tests] Generate some trampoline and registrar tests. Generate trampoline and registrar tests that tests if a return type requires objc_msgSend or objc_msgSend_stret. Now it's much easier to test new return types (a single line of code), which avoids a _lot_ of copy-pasting, and makes sure all the different variations are tested properly. These new tests found several bugs, which are fixed in subsequent commits.
2016-10-07 13:48:01 +03:00
testgenerator.exe: testgenerator.cs Makefile
$(Q) mcs -out:$@ $<
$(GENERATED_FILES_PATTERN): testgenerator.exe
$(Q) mono --debug $<
[tests] Add test-libraries.
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
[tests] Add test-libraries.
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 \
[tests] Add test-libraries.
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) \
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
.libs/$(1)/XStaticObjectTest.framework/XStaticObjectTest \
.libs/$(1)/XStaticArTest.framework/XStaticArTest \
.libs/$(1)/libtest.dylib \
[tests] Add test for bug #43689.
2017-01-26 15:38:39 +03:00
.libs/$(1)/libtest2.a \
[tests] Add test-libraries.
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 \
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
[tests] Generate some trampoline and registrar tests. Generate trampoline and registrar tests that tests if a return type requires objc_msgSend or objc_msgSend_stret. Now it's much easier to test new return types (a single line of code), which avoids a _lot_ of copy-pasting, and makes sure all the different variations are tested properly. These new tests found several bugs, which are fixed in subsequent commits.
2016-10-07 13:48:01 +03:00
all-local:: $$($(2)_TARGETS) $(GENERATED_FILES)
[tests] Add test-libraries.
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 $$@
[tests] Add test-libraries.
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
[tests] Add test-libraries.
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 $$@
[test-libraries] Don't include all the dependencies in the ar archives we create. (#9167) We only want the *.o files in the *.a archives, not the source files (*.m files).
2020-07-23 16:37:39 +03:00
$$(call Q_2,AR [$(1)]) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar cru $$@ $$<
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
[mtouch] Make sure native symbols from third-party libraries are preserved in dylibs. Fixes #51548. The native linker treats object files (.o) and static libraries (.a files, which are archives of .o files) differently. The native linker will always include object files into the executable: $ echo "void xxx () {}" > foo.m $ clang -c foo.m -o foo.o -arch x86_64 $ ld foo.o -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64 $ nm foo.dylib 0000000000000fe0 T _xxx However, if the object file is inside a static library: $ echo "void xxx () {}" > foo.m $ clang -c foo.m -o foo.o -arch x86_64 $ ar cru foo.a foo.o $ ld foo.a -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64 $ nm foo.dylib <no output> This means that our testing library (libtest.a) which is a fat library of _object files_, do not show the problems reported in bug #51548. So: a) I've fixed the creation of libtest.a to be a fat library of _static libraries_. This causes the `FastDev_LinkWithTest` test to fail exactly like in bug #51548. b) I've made mtouch pass `-u <native symbol>` to the native linker, for every native symbol referenced in a managed assembly, when creating a dylib. Amazingly this seems to work fine even with symbols to Objective-C classes (`_OBJC_CLASS_$_<class name>`). c) This also required adding support for collecting the Objective-C names of all managed types registered with Objective-C to the linker. The information is already available in the static registrar, but that would require us to make sure the static registrar is executed before compiling dylibs, which means those two tasks won't be able to run in parallel (also there's no guarantee we'll even run the static registrar). https://bugzilla.xamarin.com/show_bug.cgi?id=51548
2017-01-18 12:25:58 +03:00
.libs/$(1)/libtest.a: $$(foreach arch,$(3),.libs/$(1)/libtest.$$(arch).a)
[tests] Add test-libraries.
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 $$@
[tests] Add test for bug #43689.
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 $$@
[mtouch] Make sure native symbols from third-party libraries are preserved in dylibs. Fixes #51548. The native linker treats object files (.o) and static libraries (.a files, which are archives of .o files) differently. The native linker will always include object files into the executable: $ echo "void xxx () {}" > foo.m $ clang -c foo.m -o foo.o -arch x86_64 $ ld foo.o -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64 $ nm foo.dylib 0000000000000fe0 T _xxx However, if the object file is inside a static library: $ echo "void xxx () {}" > foo.m $ clang -c foo.m -o foo.o -arch x86_64 $ ar cru foo.a foo.o $ ld foo.a -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64 $ nm foo.dylib <no output> This means that our testing library (libtest.a) which is a fat library of _object files_, do not show the problems reported in bug #51548. So: a) I've fixed the creation of libtest.a to be a fat library of _static libraries_. This causes the `FastDev_LinkWithTest` test to fail exactly like in bug #51548. b) I've made mtouch pass `-u <native symbol>` to the native linker, for every native symbol referenced in a managed assembly, when creating a dylib. Amazingly this seems to work fine even with symbols to Objective-C classes (`_OBJC_CLASS_$_<class name>`). c) This also required adding support for collecting the Objective-C names of all managed types registered with Objective-C to the linker. The information is already available in the static registrar, but that would require us to make sure the static registrar is executed before compiling dylibs, which means those two tasks won't be able to run in parallel (also there's no guarantee we'll even run the static registrar). https://bugzilla.xamarin.com/show_bug.cgi?id=51548
2017-01-18 12:25:58 +03:00
.libs/$(1)/libtest-object.a: $$(foreach arch,$(3),.libs/$(1)/libtest-object.$$(arch).a)
[tests] Add test-libraries.
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 $$@
[mtouch] Make sure native symbols from third-party libraries are preserved in dylibs. Fixes #51548. The native linker treats object files (.o) and static libraries (.a files, which are archives of .o files) differently. The native linker will always include object files into the executable: $ echo "void xxx () {}" > foo.m $ clang -c foo.m -o foo.o -arch x86_64 $ ld foo.o -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64 $ nm foo.dylib 0000000000000fe0 T _xxx However, if the object file is inside a static library: $ echo "void xxx () {}" > foo.m $ clang -c foo.m -o foo.o -arch x86_64 $ ar cru foo.a foo.o $ ld foo.a -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64 $ nm foo.dylib <no output> This means that our testing library (libtest.a) which is a fat library of _object files_, do not show the problems reported in bug #51548. So: a) I've fixed the creation of libtest.a to be a fat library of _static libraries_. This causes the `FastDev_LinkWithTest` test to fail exactly like in bug #51548. b) I've made mtouch pass `-u <native symbol>` to the native linker, for every native symbol referenced in a managed assembly, when creating a dylib. Amazingly this seems to work fine even with symbols to Objective-C classes (`_OBJC_CLASS_$_<class name>`). c) This also required adding support for collecting the Objective-C names of all managed types registered with Objective-C to the linker. The information is already available in the static registrar, but that would require us to make sure the static registrar is executed before compiling dylibs, which means those two tasks won't be able to run in parallel (also there's no guarantee we'll even run the static registrar). https://bugzilla.xamarin.com/show_bug.cgi?id=51548
2017-01-18 12:25:58 +03:00
.libs/$(1)/libtest-ar.a: $$(foreach arch,$(3),.libs/$(1)/libtest-ar.$$(arch).a)
[tests] Add test-libraries.
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
Make makefiles compatible with make 4.3. (#8573) In make 4.3 the pattern `.libs/watchos/%.arm64_32.dylib` in mk/rules.mk takes precedence over the pattern `.libs/watchos/libtest.%.dylib` in tests/test-libraries/Makefile when the pattern replacements are 'libtest' and 'arm64_32' respectively, because the former is shorter. This seems to be a bug (in make 3.81) that has been fixed, because that's the documented behavior. Rewrite the logic to not use a pattern target in test/test-libraries/Makefile.
2020-05-12 17:38:05 +03:00
.libs/$(1)/libtest.x86.dylib: ARCH=i386
[runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. (#10739) * [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. * [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst. This also fixes a build error: error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan. * Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst. * [tests] Update to not run the StartWWAN test on Mac Catalyst. * Update conditional logic. * Fix build with newer make versions.
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)
[msbuild/dotnet] Add support for NativeReference items. Fixes #11061. * Pass any native references to the LinkNativeCode task so that they're linked with the main executable. * Copy frameworks and dynamic libraries to the app bundle (also add support for MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework / dynamic library to the app bundle). * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
2021-05-13 19:45:48 +03:00
$$(Q) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool -id @rpath/libtest.dylib $$@
[runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. (#10739) * [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. * [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst. This also fixes a build error: error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan. * Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst. * [tests] Update to not run the StartWWAN test on Mac Catalyst. * Update conditional logic. * Fix build with newer make versions.
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)
[msbuild/dotnet] Add support for NativeReference items. Fixes #11061. * Pass any native references to the LinkNativeCode task so that they're linked with the main executable. * Copy frameworks and dynamic libraries to the app bundle (also add support for MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework / dynamic library to the app bundle). * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
2021-05-13 19:45:48 +03:00
$$(Q) $(XCODE_DEVELOPER_ROOT)/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool -id @rpath/libtest.dylib $$@
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/$(1)/libtest.dylib: $$(foreach arch,$(3),.libs/$(1)/libtest.$$(arch).dylib)
[tests] Add test-libraries.
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)
Clone files if possible whenever it makes sense. (#5049) Cloning is faster when supported, and it also saves disk space.
2018-10-29 18:09:30 +03:00
$$(Q) $(CP) $$^ $$@
[msbuild/dotnet] Add support for NativeReference items. Fixes #11061. * Pass any native references to the LinkNativeCode task so that they're linked with the main executable. * Copy frameworks and dynamic libraries to the app bundle (also add support for MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework / dynamic library to the app bundle). * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
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 $$@
[tests] Add test-libraries.
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)
Clone files if possible whenever it makes sense. (#5049) Cloning is faster when supported, and it also saves disk space.
2018-10-29 18:09:30 +03:00
$$(Q) $(CP) $$^ $$@
[tests] Add test-libraries.
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):
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
$$(Q) mkdir -p $$@
endef
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
# 1: platform infix
# 2: platform variable
# 3: architectures
# 4: platform name
# 5: min version
# 6: os
[tests] Build test libraries for [ios|tvos]simulator-arm64 This turned out a bit complicated, because we're lipo'ing together both the simulator and device slices, and that doesn't work anymore when ARM64 is both a simulator and a device architecture. The solution is a custom lipo logic that doesn't include the simulator version of the ARM64 architecture in the final binary.
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)))
Add support for binding projects in Mac Catalyst. Fixes #10286. (#10295) * [tests] Build test-libraries for Mac Catalyst. * [msbuild] Add support for Mac Catalyst binding projects. * [mtouch] Allow frameworks for Mac Catalyst apps. * [mtouch] Put frameworks in the expected location for Mac Catalyst apps. * [msbuild] Create the Resources directory before trying to put files in it.
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)))
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
ifdef INCLUDE_TVOS
[tests] Build test libraries for [ios|tvos]simulator-arm64 This turned out a bit complicated, because we're lipo'ing together both the simulator and device slices, and that doesn't work anymore when ARM64 is both a simulator and a device architecture. The solution is a custom lipo logic that doesn't include the simulator version of the ARM64 architecture in the final binary.
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)))
Add support for binding projects in Mac Catalyst. Fixes #10286. (#10295) * [tests] Build test-libraries for Mac Catalyst. * [msbuild] Add support for Mac Catalyst binding projects. * [mtouch] Allow frameworks for Mac Catalyst apps. * [mtouch] Put frameworks in the expected location for Mac Catalyst apps. * [msbuild] Create the Resources directory before trying to put files in it.
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)))
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
endif
ifdef INCLUDE_WATCH
Add support for binding projects in Mac Catalyst. Fixes #10286. (#10295) * [tests] Build test-libraries for Mac Catalyst. * [msbuild] Add support for Mac Catalyst binding projects. * [mtouch] Allow frameworks for Mac Catalyst apps. * [mtouch] Put frameworks in the expected location for Mac Catalyst apps. * [msbuild] Create the Resources directory before trying to put files in it.
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)))
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
endif
[tests] Build the native test library for macOS and create a binding project for it. (#3373) * [tests] Build the native test library for macOS and create a binding project for it. Also add the new binding project to the xammac and link all XM test projects, which allows us to stop excluding tests that require the native library and the corresponding bindings. * [tests] Include more tests in xammac_tests. * [tests] Correctly ignore the ObjC exception tests in release mode.
2018-02-02 13:14:44 +03:00
ifdef INCLUDE_MAC
Rename any *OSX_SDK_VERSION variables to *MACOS_SDK_VERSION. (#13411) This makes it easier to iterate over all the *_SDK_VERSION variables in template code, because they're all named using the standard platform names we use elsewhere.
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))
Add support for binding projects in Mac Catalyst. Fixes #10286. (#10295) * [tests] Build test-libraries for Mac Catalyst. * [msbuild] Add support for Mac Catalyst binding projects. * [mtouch] Allow frameworks for Mac Catalyst apps. * [mtouch] Put frameworks in the expected location for Mac Catalyst apps. * [msbuild] Create the Resources directory before trying to put files in it.
2020-12-17 20:53:16 +03:00
endif
ifdef INCLUDE_MACCATALYST
[runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. (#10739) * [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. * [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst. This also fixes a build error: error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan. * Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst. * [tests] Update to not run the StartWWAN test on Mac Catalyst. * Update conditional logic. * Fix build with newer make versions.
2021-03-03 09:48:07 +03:00
$(eval $(call Template,maccatalyst,MACCATALYST,x86_64 arm64,MacCatalyst,$(MACCATALYST_COMMON_CFLAGS)))
[tests] Build the native test library for macOS and create a binding project for it. (#3373) * [tests] Build the native test library for macOS and create a binding project for it. Also add the new binding project to the xammac and link all XM test projects, which allows us to stop excluding tests that require the native library and the corresponding bindings. * [tests] Include more tests in xammac_tests. * [tests] Correctly ignore the ObjC exception tests in release mode.
2018-02-02 13:14:44 +03:00
endif
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
[tests] Build a macOS/arm64 version of libtest. (#11364) Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
2021-04-29 14:41:52 +03:00
.libs/ios-fat .libs/tvos-fat .libs/watchos-fat .libs/maccatalyst-fat .libs/macos-fat:
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
$(Q) mkdir -p $@
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
define LibTemplate
.libs/$(4)/libtest.$(1).a: $(2) $(3) | .libs/$(4)
[tests] Add test-libraries.
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
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
all-local:: $$($(5)_TARGETS)
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
endef
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
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))
[build] Skip building stuff that isn't enabled. (#11385)
2021-04-30 08:51:58 +03:00
ifdef INCLUDE_TVOS
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
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))
[build] Skip building stuff that isn't enabled. (#11385)
2021-04-30 08:51:58 +03:00
endif
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
[build] Skip building stuff that isn't enabled. (#11385)
2021-04-30 08:51:58 +03:00
ifdef INCLUDE_WATCH
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
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))
[build] Skip building stuff that isn't enabled. (#11385)
2021-04-30 08:51:58 +03:00
endif
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
[build] Skip building stuff that isn't enabled. (#11385)
2021-04-30 08:51:58 +03:00
ifdef INCLUDE_MACCATALYST
[runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. (#10739) * [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. * [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst. This also fixes a build error: error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan. * Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst. * [tests] Update to not run the StartWWAN test on Mac Catalyst. * Update conditional logic. * Fix build with newer make versions.
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))
[build] Skip building stuff that isn't enabled. (#11385)
2021-04-30 08:51:58 +03:00
endif
Add support for binding projects in Mac Catalyst. Fixes #10286. (#10295) * [tests] Build test-libraries for Mac Catalyst. * [msbuild] Add support for Mac Catalyst binding projects. * [mtouch] Allow frameworks for Mac Catalyst apps. * [mtouch] Put frameworks in the expected location for Mac Catalyst apps. * [msbuild] Create the Resources directory before trying to put files in it.
2020-12-17 20:53:16 +03:00
[tests] Build a macOS/arm64 version of libtest. (#11364) Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
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
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
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 $$@)
[tests] Build test libraries for [ios|tvos]simulator-arm64 This turned out a bit complicated, because we're lipo'ing together both the simulator and device slices, and that doesn't work anymore when ARM64 is both a simulator and a device architecture. The solution is a custom lipo logic that doesn't include the simulator version of the ARM64 architecture in the final binary.
2021-11-24 00:02:02 +03:00
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
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 $$@)
[tests] Build test libraries for [ios|tvos]simulator-arm64 This turned out a bit complicated, because we're lipo'ing together both the simulator and device slices, and that doesn't work anymore when ARM64 is both a simulator and a device architecture. The solution is a custom lipo logic that doesn't include the simulator version of the ARM64 architecture in the final binary.
2021-11-24 00:02:02 +03:00
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
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)
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
$(Q) mkdir -p $$(dir $$@)
[tests] Build test libraries for [ios|tvos]simulator-arm64 This turned out a bit complicated, because we're lipo'ing together both the simulator and device slices, and that doesn't work anymore when ARM64 is both a simulator and a device architecture. The solution is a custom lipo logic that doesn't include the simulator version of the ARM64 architecture in the final binary.
2021-11-24 00:02:02 +03:00
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
[tests] Add test-libraries.
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
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
$(Q) mkdir -p $$(dir $$@)
Add support for binding projects in Mac Catalyst. Fixes #10286. (#10295) * [tests] Build test-libraries for Mac Catalyst. * [msbuild] Add support for Mac Catalyst binding projects. * [mtouch] Allow frameworks for Mac Catalyst apps. * [mtouch] Put frameworks in the expected location for Mac Catalyst apps. * [msbuild] Create the Resources directory before trying to put files in it.
2020-12-17 20:53:16 +03:00
ifneq ($(2),$(3))
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
@# Check if the Info.plists are identical
$(Q) diff $$^
Add support for binding projects in Mac Catalyst. Fixes #10286. (#10295) * [tests] Build test-libraries for Mac Catalyst. * [msbuild] Add support for Mac Catalyst binding projects. * [mtouch] Allow frameworks for Mac Catalyst apps. * [mtouch] Put frameworks in the expected location for Mac Catalyst apps. * [msbuild] Create the Resources directory before trying to put files in it.
2020-12-17 20:53:16 +03:00
endif
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
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)
[tests] Build test libraries for [ios|tvos]simulator-arm64 This turned out a bit complicated, because we're lipo'ing together both the simulator and device slices, and that doesn't work anymore when ARM64 is both a simulator and a device architecture. The solution is a custom lipo logic that doesn't include the simulator version of the ARM64 architecture in the final binary.
2021-11-24 00:02:02 +03:00
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/$(1)/libtest2.a: .libs/$(2)/libtest2.a .libs/$(3)/libtest2.a | .libs/$(1)
[tests] Build test libraries for [ios|tvos]simulator-arm64 This turned out a bit complicated, because we're lipo'ing together both the simulator and device slices, and that doesn't work anymore when ARM64 is both a simulator and a device architecture. The solution is a custom lipo logic that doesn't include the simulator version of the ARM64 architecture in the final binary.
2021-11-24 00:02:02 +03:00
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
[msbuild/dotnet] Add support for NativeReference items. Fixes #11061. * Pass any native references to the LinkNativeCode task so that they're linked with the main executable. * Copy frameworks and dynamic libraries to the app bundle (also add support for MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework / dynamic library to the app bundle). * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
2021-05-13 19:45:48 +03:00
.libs/$(1)/libtest.dylib: .libs/$(2)/libtest.dylib .libs/$(3)/libtest.dylib | .libs/$(1)
[tests] Build test libraries for [ios|tvos]simulator-arm64 This turned out a bit complicated, because we're lipo'ing together both the simulator and device slices, and that doesn't work anymore when ARM64 is both a simulator and a device architecture. The solution is a custom lipo logic that doesn't include the simulator version of the ARM64 architecture in the final binary.
2021-11-24 00:02:02 +03:00
$(Q) ./lipo-remove-sim-arm64.sh $$@ $$^
[msbuild/dotnet] Add support for NativeReference items. Fixes #11061. * Pass any native references to the LinkNativeCode task so that they're linked with the main executable. * Copy frameworks and dynamic libraries to the app bundle (also add support for MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework / dynamic library to the app bundle). * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
2021-05-13 19:45:48 +03:00
[tests] Fix some make logic in test-libraries. Use the right template variable in the template expansion to avoid duplicating variable names.
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 \
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/$(1)/XStaticObjectTest.framework/XStaticObjectTest \
.libs/$(1)/XStaticArTest.framework/XStaticArTest \
[msbuild/dotnet] Add support for NativeReference items. Fixes #11061. * Pass any native references to the LinkNativeCode task so that they're linked with the main executable. * Copy frameworks and dynamic libraries to the app bundle (also add support for MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework / dynamic library to the app bundle). * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
2021-05-13 19:45:48 +03:00
.libs/$(1)/libtest.dylib \
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/$(1)/libtest.a \
.libs/$(1)/libtest2.a \
[tests] Fix some make logic in test-libraries. Use the right template variable in the template expansion to avoid duplicating variable names.
2021-09-27 17:56:49 +03:00
all-local:: $$($(4)_TARGETS)
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
endef
[tests] Add test-libraries.
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))
[build] Skip building stuff that isn't enabled. (#11385)
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))
[build] Skip building stuff that isn't enabled. (#11385)
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))
[build] Skip building stuff that isn't enabled. (#11385)
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 $$@
[tests] Fix some make logic in test-libraries. Use the right template variable in the template expansion to avoid duplicating variable names.
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 \
[tests] Fix some make logic in test-libraries. Use the right template variable in the template expansion to avoid duplicating variable names.
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
[build] Skip building stuff that isn't enabled. (#11385)
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))
[build] Skip building stuff that isn't enabled. (#11385)
2021-04-30 08:51:58 +03:00
endif
[tests] Build a macOS/arm64 version of libtest. (#11364) Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
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))
[tests] Build a macOS/arm64 version of libtest. (#11364) Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
2021-04-29 14:41:52 +03:00
endif
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
[build] Skip building stuff that isn't enabled. (#11385)
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
[msbuild] Add support for `.xcframework` (#10046) This is done early so we can resolve the inner framework, inside the xcframework, and let the existing framework support do most of the work. The resolving code has unit tests. Custom projects for "NoEmbedding" exists for all supported platforms and executed by xharness. A sample `xcframework` with tests projects is also available [here](https://github.com/spouliot/xcframework). The xcframework test case is based on Rolf's earlier/partial implementation. https://github.com/rolfbjarne/xamarin-macios/commit/xcframework Things to note: Do not rename a framework (like XTest) to use it in an xcframework (like XCTest). That will fail at codesign but won't give anything useful. You might think signing the framework (instead of the inner binary) would solve it. It does, as it codesign, but then the app crash at startup. At some point you realize some symbols are still using XTest (not XCTest) and then you can delete several other weird workarounds (like for `ld`) because all of it was cause by this never identified rename. dSYM support (and tests) to be done in a separate PR.
2020-11-30 21:44:03 +03:00
ifdef INCLUDE_MAC
XCPLATFORMS+= macos
endif
Add support for binding projects in Mac Catalyst. Fixes #10286. (#10295) * [tests] Build test-libraries for Mac Catalyst. * [msbuild] Add support for Mac Catalyst binding projects. * [mtouch] Allow frameworks for Mac Catalyst apps. * [mtouch] Put frameworks in the expected location for Mac Catalyst apps. * [msbuild] Create the Resources directory before trying to put files in it.
2020-12-17 20:53:16 +03:00
ifdef INCLUDE_MACCATALYST
XCPLATFORMS+= maccatalyst
endif
[msbuild] Add support for `.xcframework` (#10046) This is done early so we can resolve the inner framework, inside the xcframework, and let the existing framework support do most of the work. The resolving code has unit tests. Custom projects for "NoEmbedding" exists for all supported platforms and executed by xharness. A sample `xcframework` with tests projects is also available [here](https://github.com/spouliot/xcframework). The xcframework test case is based on Rolf's earlier/partial implementation. https://github.com/rolfbjarne/xamarin-macios/commit/xcframework Things to note: Do not rename a framework (like XTest) to use it in an xcframework (like XCTest). That will fail at codesign but won't give anything useful. You might think signing the framework (instead of the inner binary) would solve it. It does, as it codesign, but then the app crash at startup. At some point you realize some symbols are still using XTest (not XCTest) and then you can delete several other weird workarounds (like for `ld`) because all of it was cause by this never identified rename. dSYM support (and tests) to be done in a separate PR.
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) \
[msbuild] Add support for `.xcframework` (#10046) This is done early so we can resolve the inner framework, inside the xcframework, and let the existing framework support do most of the work. The resolving code has unit tests. Custom projects for "NoEmbedding" exists for all supported platforms and executed by xharness. A sample `xcframework` with tests projects is also available [here](https://github.com/spouliot/xcframework). The xcframework test case is based on Rolf's earlier/partial implementation. https://github.com/rolfbjarne/xamarin-macios/commit/xcframework Things to note: Do not rename a framework (like XTest) to use it in an xcframework (like XCTest). That will fail at codesign but won't give anything useful. You might think signing the framework (instead of the inner binary) would solve it. It does, as it codesign, but then the app crash at startup. At some point you realize some symbols are still using XTest (not XCTest) and then you can delete several other weird workarounds (like for `ld`) because all of it was cause by this never identified rename. dSYM support (and tests) to be done in a separate PR.
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
[msbuild/tests] Add support for xcframeworks with static libraries in them. (#13459) * [tests] Create a libtest.xcframework and libtest2.xcframework * [tests] Make bindings-test and bindings-test2 use an xcframework instead of plain static library * [msbuild] Add support for xcframeworks with static libraries in them. * List the frameworks libtest needs. * [tests] Update .NET unit tests according to test project changes. * [tests] Add new test to verify that packing an old-style binding project doesn't work.
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
[tests] Build the native test library for macOS and create a binding project for it. (#3373) * [tests] Build the native test library for macOS and create a binding project for it. Also add the new binding project to the xammac and link all XM test projects, which allows us to stop excluding tests that require the native library and the corresponding bindings. * [tests] Include more tests in xammac_tests. * [tests] Correctly ignore the ObjC exception tests in release mode.
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
Rename any *OSX_SDK_VERSION variables to *MACOS_SDK_VERSION. (#13411) This makes it easier to iterate over all the *_SDK_VERSION variables in template code, because they're all named using the standard platform names we use elsewhere.
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
[tests] Build the native test library for macOS and create a binding project for it. (#3373) * [tests] Build the native test library for macOS and create a binding project for it. Also add the new binding project to the xammac and link all XM test projects, which allows us to stop excluding tests that require the native library and the corresponding bindings. * [tests] Include more tests in xammac_tests. * [tests] Correctly ignore the ObjC exception tests in release mode.
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 $@
[tests] Add test-libraries.
2016-04-26 15:00:35 +03:00
clean-local:: $(CLEAN_TARGETS)
include $(TOP)/mk/rules.mk
Make makefiles compatible with make 4.3. (#8573) In make 4.3 the pattern `.libs/watchos/%.arm64_32.dylib` in mk/rules.mk takes precedence over the pattern `.libs/watchos/libtest.%.dylib` in tests/test-libraries/Makefile when the pattern replacements are 'libtest' and 'arm64_32' respectively, because the former is shorter. This seems to be a bug (in make 3.81) that has been fixed, because that's the documented behavior. Rewrite the logic to not use a pattern target in test/test-libraries/Makefile.
2020-05-12 17:38:05 +03:00
.SECONDARY: