Re: Heads up: CMake build system for libobjc

[Quentin Mathé]

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

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.