Re: Heads up: CMake build system for libobjc

[David Chisnall]

On 13 Dec 2012, at 16:13, Quentin Mathé wrote:

> I think the GNUmakefile is pretty clean now because it's just a wrapper 
> around Makefile since November.

It does not, for example, pass the correct arguments to allow the project to 
build without warnings.

> libobjcxx appears to be correctly compiled and installed now. 

Okay, now do you want to add the logic (that's already in the CMake build) so 
that it will link libcxxrt.so or libsupc++.so and build a single libobjc.so 
when this is possible?  A few other things that it can't do:

- Easily let me select the install location as a standard system library 
install, not a GNUstep one (this requires using the Makefile directly)

- Print a list of the configurable options

- Build the LLVM optimisations

> 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.

That's a good idea.  I've implemented it in r35891.

> 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.

The equivalent is the debug 

>> 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.

I'll leave them in svn for a while, but they are no longer maintained and so 
I'd like to remove them soon.  We've already seen lots of issues from people 
picking the wrong build system to use, and I'd like to fix that.  I could, 
however, leave a stub Makefile lying around that just invoked cmake...

> 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

I'm still not sure what this is about (and it won't work on recent FreeBSD, for 
example, where cc is clang, and is the default C compiler - cmake has better 
detection for the type of compiler, which is used currently to add 
clang-specific warning-suppression flags).  Is it still broken in current 
clang?  Clang defaults to i686, so this is slightly strange, because that's 
where it will be most tested.  

I've made that change in r35892, but I still would rather see this fixed 
properly.

> # 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

I believe that this one is only required for GNUstep Make compatibility, 
because somewhere deep inside the makefiles it defines this.  It can be 
reintroduced if it's required.

> ifeq ($(findstring openbsd, `$CC -dumpmachine`), openbsd)
>  LDFLAGS += -pthread 
> else
>  LDFLAGS += -lpthread 
> endif

This is handled by CMake automatically, via the FindThreads package.

> 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.

No you didn't, you copied and pasted them, which broke the Makefile.  I've now 
reverted this change, because it meant that the portable Makefile was not 
portable any longer (it no longer worked when I typed 'make' for example).  
There is a reason that the Makefile and GNUmakefile are separate files.  
GNUisms go in the GNUmakefile.  

David

-- Sent from my Apple II