gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Heads up: CMake build system for libobjc


From: Sebastian Reitenbach
Subject: Re: Heads up: CMake build system for libobjc
Date: Thu, 13 Dec 2012 17:34:34 +0100
User-agent: SOGoMail 2.0.3

On Thursday, December 13, 2012 17:13 CET, Quentin Mathé <address@hidden> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev








reply via email to

[Prev in Thread] Current Thread [Next in Thread]