On Thursday, December 13, 2012 17:13 CET, Quentin Mathé <[email protected]> wrote: > Hi David, > > Le 13 déc. 2012 à 14:40, David Chisnall a écrit : > > > Hello the list, > > > Those following svn will have seen this in the libobjc2 commit log: > > >> Add CMake build system for libobjc2. This will replace the existing > > >> build > >> systems after some further testing. > >> >> Currently, we have three build systems for libobjc2: > >> >> - GNUmakefile, which provides a number of options but not very cleanly > >> >> (i.e. > >> the only way of knowing what they are is to read the source) and doesn't > >> correctly build the Objective-C++ runtime. > > I think the GNUmakefile is pretty clean now because it's just a wrapper > around Makefile since November. libobjcxx appears to be correctly compiled > and installed now. The GNUmakefile doesn't use GNUstep Make anymore, but just > relies on gnustep-config to install libobjc2 in a manner that respects > GNUstep rules. This works really well and means there is little duplication > between Makefile and GNUmakefile. > > >> - Makefile.clang, which is experimental, doesn't really work, and confuses > >> people. > > Yes. > > >> The new CMake system: > >> >> - Correctly installs in a GNUstep location if one exists, or in a system > >> location otherwise. This is configurable at build time. > > It should use gnustep-config to retrieve the right install paths and figure > out the installation domain. > For example: gnustep-config --installation-domain-for=libobjc2 > > By looking up the install domain in this way, you can be sure > /etc/GNustep/installation-domains.conf will be respected if it exists. > > >> - Provides inspectable options for all of the configuration choices (run > >> ccmake > >> to see them all) > >> - Easily supports cross-compilation and out-of-tree builds > >> - Is easy to extend and inspect > >> - Automatically builds the LLVM optimisations (which already use CMake, as > >> it's > >> the only clean way of building LLVM optimisations out of tree) and can be > >> easily configured not to if they are not required. > >> - Will build a single libobjc.so for platforms that provide a separate C++ > >> runtime and a separate libobjcxx for ones that don't. > >> - Can generate build files for make, ninja, XCode, Eclipse, and Visual > >> Studio > > ok > > It would be great if the CMakeLists.txt was able to interpret 'debug=yes' and > 'strip=yes' options since these are commonly used. I don't know their > equivalents for CMake. > > > I will be removing the other build systems soon, so please test this, > > Please don't remove the GNUmakefile and the Makefile too quickly. We have a > build system that works and is well tested. I strongly suggest to keep both > Makefile and GNUmakefile in place for the 1.7 release. They could then be > removed in 0.18 or 0.19. > > It looks like CMakeLists.txt miss some workarounds from the Makefile: > > # Hack to support -03 and get the __sync_* GCC builtins work > # -O3 requires -march=i586 on Linux x86-32, otherwise Clang compiles # > programs that segfaults if -fobjc-nonfragile-abi is used. > ifneq ($(findstring gcc, $(CC)),) # TODO: Detect target CPU even if > GNUstep.sh is not sourced > ifeq ($(GNUSTEP_TARGET_CPU), ix86) > CFLAGS += -march=i586 > endif > endif > > # Hack to get mingw to provide declaration for strdup (since it is > non-standard) > # TODO: Detect mingw32 target even if GNUstep.sh is not sourced > ifeq ($(GNUSTEP_TARGET_OS), mingw32) > ${LIBOBJC}_CPPFLAGS += -U__STRICT_ANSI__ > endif > > ifeq ($(findstring openbsd, `$CC -dumpmachine`), openbsd) > LDFLAGS += -pthread else > LDFLAGS += -lpthread endif
with OpenBSD 5.2 and onward, this should not be needed anymore, but if its there, it doesn't harm. Sebastian > > The first workaround for supporting the non-fragile ABI on Linux is important > in my case, I don't know about the two other hacks. But I suppose some people > need them. I ported these from the old GNUmakefile to the Makefile. > > Cheers, > Quentin. > _______________________________________________ > Gnustep-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
