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

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

Add build system.
2016-04-21 11:59:27 +03:00
mono_root=$(MONO_PATH)
builds_root=$(TOP)/builds
# helpful rules to compile things for the various architectures
[runtime] integrate mono 2017-10 (#2905) * Update the function name used to initialize libmono-profiler-log, its called mono_profiler_init_log () now. * [builds] Pass --with-cross-offsets= to crosstv's configure. * Bump mono to 2017-08. * Bump mono to 2017-08. * Force disable 'futimens' and 'utimensat' so that we build with Xcode 9. This is also needed to build with Xcode 8.3 on High Sierra. * Remove old AppleTls implementation. * Bump mono. * Bump mono to 2017-08. * Bump mono to 2017-08 * Reenable link-keep-resources-2 test - This reverts commit 76b759ef22c06cda3ba30aba1ac0d45634e4fbf4. - 2017-08 has linker fix * Bump mono to 2017-10 * Revert "Bump mono to 2017-10" This reverts commit bb7832724e18f8578449e46426382a537f3f4823. * Bump system mono to 2017-10 * Bump embedded mono to 2017-10 * [runtime] reflect eglib move https://github.com/mono/mono/commit/9be68f8952ea0e1aad582bfe2f47bad71aee2cc7 * bump mono * [btouch] remove Security.Tls usage from test * [mtouch tests] update the function name used to initialize libmono-profiler-log, its called mono_profiler_init_log () now. see https://github.com/mono/mono/commit/ea4e4a9ef6fc42570a23026adbe826cf7248290e fixes: ``` 1) Failed : Xamarin.MTouch.Profiling(tvOS) _mono_profiler_startup_log Expected: collection containing "_mono_profiler_startup_log" But was: < "_mono_profiler_init_log" > at Xamarin.MTouch.Profiling (Xamarin.Profile profile) [0x00106] in <511889694a624cc9a50e0e9b259b05c5>:0 2) Failed : Xamarin.MTouch.Profiling(watchOS) _mono_profiler_startup_log Expected: collection containing "_mono_profiler_startup_log" But was: < "_xamarin_get_block_descriptor", "_mono_profiler_init_log" > at Xamarin.MTouch.Profiling (Xamarin.Profile profile) [0x00106] in <511889694a624cc9a50e0e9b259b05c5>:0 ``` * [mmptest] update log profiler options. https://github.com/mono/mono/commit/826558a4af624bc0acaea98ec39784e65d278091 deprecated the dash prefix for the mlpd path. `noallocs` or `nocalls` are not needed, neither of them are default anymore. * [mmptest] fix link-keep-resources-2 test to cope with more corlib resources. another corlib resource (mscorlib.xml) was added: https://github.com/mono/mono/commit/11e95169e787#diff-2d1c64decd91d9a6e8842ab0f0e9438d * Revert "[mmptest] fix link-keep-resources-2 test to cope with more corlib resources." This reverts commit 350eb3c174288bbffcc3b7acb15cadb913af25b7. * [XHarness] Add the Mono.Data.Tds tests. * Address comments from rolf in the review. * [mmp regresssion tests] bump mono linker, so mscorlib.xml gets stripped the test was failing in that way: > Executing link-keep-resources-2... > [FAIL] i18n 4/2 data files present: charinfo.nlp, collation.core.bin, collation.tailoring.bin, mscorlib.xml also update the output, because it's actually expected at least three elements. fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=59277 * bump mono fixes crash in tvOS: https://github.com/mono/mono/pull/5812 * bump mono for updated BCL tests see https://github.com/mono/mono/pull/5820 * [mono] set 2017-10 branch in .gitmodules * [macos] Fix guiunit error on clean builds by depending on correct copy (#2912) * [macos] Fix guiunit error on clean builds by depending on correct copy - From a clean build making a BCL test would error due to the non-mobile guiunit not being built - This was because the Makefile-mac.inc target was incorrect - This was because xharness assumed that non variation based targets were always Modern - However, BCL tests are Full, not Modern * Code review change * Swap to var to reduce diff * Revert changes in the paths for GuiUnit. * [XHarness] Add the System.IO.Compression bcl tests. (#2918) * [XHarness] Add the System.IO.Compression bcl tests. * [XHarness] Add bcl tests for System.IO.Compression.FileSystem. (#2924) * [XHarness] Add the System.IO.Compression bcl tests. * Ensure that resources are correctly copied in the bundles. * [XHarness] Add bcl tests for System.IO.Compression.FileSystem. * As per review, make the Mac test app name match the tests that are ran. * [XHarness] Add Mono.CSharp tests on ios. (#2927) * [XHarness] Add Mono.CSharp tests on ios. * Bump mono to bring changes in the mono.csharp tests. * [xtro-sharpie] fix TypeDefinition access due to Cecil change * Bump mono * bump mono fixes - https://bugzilla.xamarin.com/show_bug.cgi?id=60480 - https://bugzilla.xamarin.com/show_bug.cgi?id=60482 * bump mono more fixes around conflicting paths when tests are run in parallel. * Bump for mono/mono@2017-10
2017-11-14 23:30:08 +03:00
COMMON_I:= -I. -I$(mono_root) -I$(mono_root)/mono/eglib -I$(mono_root)/mono/metadata
SIM32_I := $(COMMON_I) -I$(BUILD_DESTDIR)/simulator86/include/mono-2.0 -I$(builds_root)/simulator86 -I$(builds_root)/simulator86/mono/eglib
SIM64_I := $(COMMON_I) -I$(BUILD_DESTDIR)/simulator64/include/mono-2.0 -I$(builds_root)/simulator64 -I$(builds_root)/simulator64/mono/eglib
DEV7_I := $(COMMON_I) -I$(BUILD_DESTDIR)/target7/include/mono-2.0 -I$(builds_root)/target7 -I$(builds_root)/target7/mono/eglib
DEV7s_I := $(COMMON_I) -I$(BUILD_DESTDIR)/target7s/include/mono-2.0 -I$(builds_root)/target7s -I$(builds_root)/target7s/mono/eglib
DEV64_I := $(COMMON_I) -I$(BUILD_DESTDIR)/target64/include/mono-2.0 -I$(builds_root)/target64 -I$(builds_root)/target64/mono/eglib
SIMW_I := $(COMMON_I) -I$(BUILD_DESTDIR)/watchsimulator/include/mono-2.0 -I$(builds_root)/watchsimulator -I$(builds_root)/watchsimulator/mono/eglib
DEVW_I := $(COMMON_I) -I$(BUILD_DESTDIR)/targetwatch/include/mono-2.0 -I$(builds_root)/targetwatch -I$(builds_root)/targetwatch/mono/eglib
SIM_TV_I:= $(COMMON_I) -I$(BUILD_DESTDIR)/tvsimulator/include/mono-2.0 -I$(builds_root)/tvsimulator -I$(builds_root)/tvsimulator/mono/eglib
DEV_TV_I:= $(COMMON_I) -I$(BUILD_DESTDIR)/targettv/include/mono-2.0 -I$(builds_root)/targettv -I$(builds_root)/targettv/mono/eglib
Add build system.
2016-04-21 11:59:27 +03:00
define NativeCompilationTemplate
## ios simulator
.libs/ios/%$(1).x86.o: %.m $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,OBJC, [ios]) $(SIMULATOR_CC) $(SIMULATOR86_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(SIM32_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).x86.o: %.c $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,CC, [ios]) $(SIMULATOR_CC) $(SIMULATOR86_CFLAGS) $$(EXTRA_DEFINES) $(SIM32_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).x86.o: %.s $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,ASM, [ios]) $(SIMULATOR_CC) $(SIMULATOR86_CFLAGS) $$(EXTRA_DEFINES) $(SIM32_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).x86.dylib: | .libs/ios
$$(call Q_2,LD, [ios]) $(SIMULATOR_CC) $(SIMULATOR86_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(BUILD_DESTDIR)/simulator86/lib -fapplication-extension
Use @rpath instead of @executable_path in dylibs. (#1552) Use @rpath instead of @executable_path in dylibs, since it allows us to be more flexible when placing dylibs in the app. In particular with this change it's trivial to put libmonosgen-2.0.dylib in the container app, and reference it from extensions.
2017-01-24 22:24:32 +03:00
$(Q) install_name_tool -change $(realpath $(BUILD_DESTDIR)/simulator86/lib/libmonosgen-2.0.dylib) @rpath/libmonosgen-2.0.dylib $$@
Add build system.
2016-04-21 11:59:27 +03:00
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
.libs/ios/%$(1).x86.framework: | .libs/ios
$$(call Q_2,LD, [ios]) $(SIMULATOR_CC) $(SIMULATOR86_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_IOSSIMULATOR_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
.libs/ios/%$(1).x86_64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,OBJC, [ios]) $(SIMULATOR_CC) $(SIMULATOR64_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(SIM64_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).x86_64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,CC, [ios]) $(SIMULATOR_CC) $(SIMULATOR64_CFLAGS) $$(EXTRA_DEFINES) $(SIM64_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).x86_64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,ASM, [ios]) $(SIMULATOR_CC) $(SIMULATOR64_CFLAGS) $(SIM64_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).x86_64.dylib: | .libs/ios
$$(call Q_2,LD, [ios]) $(SIMULATOR_CC) $(SIMULATOR64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(BUILD_DESTDIR)/simulator64/lib -fapplication-extension
Use @rpath instead of @executable_path in dylibs. (#1552) Use @rpath instead of @executable_path in dylibs, since it allows us to be more flexible when placing dylibs in the app. In particular with this change it's trivial to put libmonosgen-2.0.dylib in the container app, and reference it from extensions.
2017-01-24 22:24:32 +03:00
$(Q) install_name_tool -change $(realpath $(BUILD_DESTDIR)/simulator64/lib/libmonosgen-2.0.dylib) @rpath/libmonosgen-2.0.dylib $$@
Add build system.
2016-04-21 11:59:27 +03:00
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
.libs/ios/%$(1).x86_64.framework: | .libs/ios
$$(call Q_2,LD, [ios]) $(SIMULATOR_CC) $(SIMULATOR64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_IOSSIMULATOR_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
## ios device
.libs/ios/%$(1).armv7.o: %.m $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,OBJC, [ios]) $(DEVICE_CC) $(DEVICE7_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(DEV7_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).armv7.o: %.c $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,CC, [ios]) $(DEVICE_CC) $(DEVICE7_CFLAGS) $$(EXTRA_DEFINES) $(DEV7_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).armv7.dylib: | .libs/ios
$$(call Q_2,LD, [ios]) $(DEVICE_CC) $(DEVICE7_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(BUILD_DESTDIR)/target7/lib -fapplication-extension
Use @rpath instead of @executable_path in dylibs. (#1552) Use @rpath instead of @executable_path in dylibs, since it allows us to be more flexible when placing dylibs in the app. In particular with this change it's trivial to put libmonosgen-2.0.dylib in the container app, and reference it from extensions.
2017-01-24 22:24:32 +03:00
$(Q) install_name_tool -change $(realpath $(BUILD_DESTDIR)/target7/lib/libmonosgen-2.0.dylib) @rpath/libmonosgen-2.0.dylib $$@
Add build system.
2016-04-21 11:59:27 +03:00
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
.libs/ios/%$(1).armv7.framework: | .libs/ios
$$(call Q_2,LD, [ios]) $(DEVICE_CC) $(DEVICE7_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
.libs/ios/%$(1).armv7s.o: %.m $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,OBJC, [ios]) $(DEVICE_CC) $(DEVICE7S_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(DEV7s_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).armv7s.o: %.c $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,CC, [ios]) $(DEVICE_CC) $(DEVICE7S_CFLAGS) $$(EXTRA_DEFINES) $(DEV7s_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).armv7s.dylib: | .libs/ios
$$(call Q_2,LD, [ios]) $(DEVICE_CC) $(DEVICE7S_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(BUILD_DESTDIR)/target7s/lib -fapplication-extension
Use @rpath instead of @executable_path in dylibs. (#1552) Use @rpath instead of @executable_path in dylibs, since it allows us to be more flexible when placing dylibs in the app. In particular with this change it's trivial to put libmonosgen-2.0.dylib in the container app, and reference it from extensions.
2017-01-24 22:24:32 +03:00
$(Q) install_name_tool -change $(realpath $(BUILD_DESTDIR)/target7s/lib/libmonosgen-2.0.dylib) @rpath/libmonosgen-2.0.dylib $$@
Add build system.
2016-04-21 11:59:27 +03:00
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
.libs/ios/%$(1).armv7s.framework: | .libs/ios
$$(call Q_2,LD, [ios]) $(DEVICE_CC) $(DEVICE7S_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
.libs/ios/%$(1).arm64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,OBJC, [ios]) $(DEVICE_CC) $(DEVICE64_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(DEV64_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).arm64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/ios
$$(call Q_2,CC, [ios]) $(DEVICE_CC) $(DEVICE64_CFLAGS) $$(EXTRA_DEFINES) $(DEV64_I) -g $(2) -c $$< -o $$@
.libs/ios/%$(1).arm64.dylib: | .libs/ios
$$(call Q_2,LD, [ios]) $(DEVICE_CC) $(DEVICE64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(BUILD_DESTDIR)/target64/lib -fapplication-extension
Use @rpath instead of @executable_path in dylibs. (#1552) Use @rpath instead of @executable_path in dylibs, since it allows us to be more flexible when placing dylibs in the app. In particular with this change it's trivial to put libmonosgen-2.0.dylib in the container app, and reference it from extensions.
2017-01-24 22:24:32 +03:00
$(Q) install_name_tool -change $(realpath $(BUILD_DESTDIR)/target64/lib/libmonosgen-2.0.dylib) @rpath/libmonosgen-2.0.dylib $$@
Add build system.
2016-04-21 11:59:27 +03:00
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
.libs/ios/%$(1).arm64.framework: | .libs/ios
$$(call Q_2,LD, [ios]) $(DEVICE_CC) $(DEVICE64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/Frameworks -fapplication-extension -miphoneos-version-min=8.0
Add build system.
2016-04-21 11:59:27 +03:00
## watch simulator
.libs/watchos/%$(1).x86.o: %.m $(EXTRA_DEPENDENCIES) | .libs/watchos
$$(call Q_2,OBJC, [watchos]) $(SIMULATOR_CC) $(SIMULATORWATCH_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(SIMW_I) -g $(2) -c $$< -o $$@
.libs/watchos/%$(1).x86.o: %.c $(EXTRA_DEPENDENCIES) | .libs/watchos
$$(call Q_2,CC, [watchos]) $(SIMULATOR_CC) $(SIMULATORWATCH_CFLAGS) $$(EXTRA_DEFINES) $(SIMW_I) -g $(2) -c $$< -o $$@
.libs/watchos/%$(1).x86.o: %.s $(EXTRA_DEPENDENCIES) | .libs/watchos
$$(call Q_2,ASM, [watchos]) $(SIMULATOR_CC) $(SIMULATORWATCH_CFLAGS) $$(EXTRA_DEFINES) $(SIMW_I) -g $(2) -c $$< -o $$@
.libs/watchos/%$(1).x86.dylib: | .libs/watchos
$$(call Q_2,LD, [watchos]) $(SIMULATOR_CC) $(SIMULATORWATCH_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(BUILD_DESTDIR)/watchsimulator/lib -fapplication-extension
Use @rpath instead of @executable_path in dylibs. (#1552) Use @rpath instead of @executable_path in dylibs, since it allows us to be more flexible when placing dylibs in the app. In particular with this change it's trivial to put libmonosgen-2.0.dylib in the container app, and reference it from extensions.
2017-01-24 22:24:32 +03:00
$(Q) install_name_tool -change $(realpath $(BUILD_DESTDIR)/watchsimulator/lib/libmonosgen-2.0.dylib) @rpath/libmonosgen-2.0.dylib $$@
Add build system.
2016-04-21 11:59:27 +03:00
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
.libs/watchos/%$(1).x86.framework: | .libs/watchos
$$(call Q_2,LD, [watchos]) $(SIMULATOR_CC) $(SIMULATORWATCH_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_WATCHSIMULATOR_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
## watch device
.libs/watchos/%$(1).armv7k.o: %.m $(EXTRA_DEPENDENCIES) | .libs/watchos
$$(call Q_2,OBJC, [watchos]) $(DEVICE_CC) $(DEVICEWATCH_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(DEVW_I) -g $(2) -c $$< -o $$@
.libs/watchos/%$(1).armv7k.o: %.c $(EXTRA_DEPENDENCIES) | .libs/watchos
$$(call Q_2,CC, [watchos]) $(DEVICE_CC) $(DEVICEWATCH_CFLAGS) $$(EXTRA_DEFINES) $(DEVW_I) -g $(2) -c $$< -o $$@
.libs/watchos/%$(1).armv7k.dylib: | .libs/watchos
$$(call Q_2,LD, [watchos]) $(DEVICE_CC) $(DEVICEWATCH_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(BUILD_DESTDIR)/targetwatch/lib -fapplication-extension
Use @rpath instead of @executable_path in dylibs. (#1552) Use @rpath instead of @executable_path in dylibs, since it allows us to be more flexible when placing dylibs in the app. In particular with this change it's trivial to put libmonosgen-2.0.dylib in the container app, and reference it from extensions.
2017-01-24 22:24:32 +03:00
$(Q) install_name_tool -change $(realpath $(BUILD_DESTDIR)/targetwatch/lib/libmonosgen-2.0.dylib) @rpath/libmonosgen-2.0.dylib $$@
Add build system.
2016-04-21 11:59:27 +03:00
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
.libs/watchos/%$(1).armv7k.framework: | .libs/watchos
$$(call Q_2,LD, [watchos]) $(DEVICE_CC) $(DEVICEWATCH_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_WATCHOS_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
## tv simulator
.libs/tvos/%$(1).x86_64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/tvos
$$(call Q_2,OBJC, [tvos]) $(SIMULATOR_CC) $(SIMULATORTV_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(SIM_TV_I) -g $(2) -c $$< -o $$@
.libs/tvos/%$(1).x86_64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/tvos
$$(call Q_2,CC, [tvos]) $(SIMULATOR_CC) $(SIMULATORTV_CFLAGS) $$(EXTRA_DEFINES) $(SIM_TV_I) -g $(2) -c $$< -o $$@
.libs/tvos/%$(1).x86_64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/tvos
$$(call Q_2,ASM, [tvos]) $(SIMULATOR_CC) $(SIMULATORTV_CFLAGS) $$(EXTRA_DEFINES) $(SIM_TV_I) -g $(2) -c $$< -o $$@
.libs/tvos/%$(1).x86_64.dylib: | .libs/tvos
$$(call Q_2,LD, [tvos]) $(SIMULATOR_CC) $(SIMULATORTV_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(BUILD_DESTDIR)/tvsimulator/lib -fapplication-extension
Use @rpath instead of @executable_path in dylibs. (#1552) Use @rpath instead of @executable_path in dylibs, since it allows us to be more flexible when placing dylibs in the app. In particular with this change it's trivial to put libmonosgen-2.0.dylib in the container app, and reference it from extensions.
2017-01-24 22:24:32 +03:00
$(Q) install_name_tool -change $(realpath $(BUILD_DESTDIR)/tvsimulator/lib/libmonosgen-2.0.dylib) @rpath/libmonosgen-2.0.dylib $$@
Add build system.
2016-04-21 11:59:27 +03:00
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
.libs/tvos/%$(1).x86_64.framework: | .libs/tvos
$$(call Q_2,LD, [tvos]) $(SIMULATOR_CC) $(SIMULATORTV_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_TVSIMULATOR_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
## tv device
.libs/tvos/%$(1).arm64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/tvos
$$(call Q_2,OBJC, [tvos]) $(DEVICE_CC) $(DEVICETV_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(DEV_TV_I) -g $(2) -c $$< -o $$@
.libs/tvos/%$(1).arm64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/tvos
$$(call Q_2,CC, [tvos]) $(DEVICE_CC) $(DEVICETV_CFLAGS) $$(EXTRA_DEFINES) $(DEV_TV_I) -g $(2) -c $$< -o $$@
.libs/tvos/%$(1).arm64.dylib: | .libs/tvos
$$(call Q_2,LD, [tvos]) $(DEVICE_CC) $(DEVICETV_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(BUILD_DESTDIR)/targettv/lib -fapplication-extension
Use @rpath instead of @executable_path in dylibs. (#1552) Use @rpath instead of @executable_path in dylibs, since it allows us to be more flexible when placing dylibs in the app. In particular with this change it's trivial to put libmonosgen-2.0.dylib in the container app, and reference it from extensions.
2017-01-24 22:24:32 +03:00
$(Q) install_name_tool -change $(realpath $(BUILD_DESTDIR)/targettv/lib/libmonosgen-2.0.dylib) @rpath/libmonosgen-2.0.dylib $$@
Add build system.
2016-04-21 11:59:27 +03:00
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
.libs/tvos/%$(1).arm64.framework: | .libs/tvos
$$(call Q_2,LD, [tvos]) $(DEVICE_CC) $(DEVICETV_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_TVOS_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
endef
$(eval $(call NativeCompilationTemplate,,-O2))
$(eval $(call NativeCompilationTemplate,-debug,-DDEBUG))
.libs/ios .libs/watchos .libs/tvos:
$(Q) mkdir -p $@