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. _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
