Re: Heads up: CMake build system for libobjc

[Quentin Mathé]

Le 13 déc. 2012 à 17:56, David Chisnall a écrit :

> 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

Just to be clear. I don't think using CMake is bad idea. Since LLVM 
optimizations relies on it, the choice makes sense. 

I was just pointing the fact that the GNUmakefile was much better than it used 
to be.

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

ok, great. I'll give it a test.

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

ok

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

ok

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

Yes, it's pretty weird. The last time, I tried whether this workaround was 
needed, it was around three weeks ago.

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

ok, thanks.

>> 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 just didn't know that conditionals are not supported by Make. I'm even quite 
surprised to learn that they aren't.

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

Well, the whole point behind my change was to ensure people using the Makefile 
were not going to encounter the same issue.  It took me a long time to track 
down the problem. It seemed silly to fix it just for the GNUmakefile users. 

Quentin.