Chuck Robey <chuckr at telenix.org> writes:>> Doesn't CMake support the BSD toolchain? > > OK, I checked the llvm-2.5 Makefiles. They have constructs in them > which cannot be used in any BSD Makefile (such as the form of > conditionals: ifndef is a GNU Makeism), and won't run on any BSD Make. > I know BSD Make and GNU Make well enough, but I doon't know much about > Cmake, I can say that all of the makefiles I saw in llvm would (1) > refuse to run on BSD make and (2) make no use whatever of the large > set of BSD Make template files that always reside in /usr/share/mk.The makefiles distributed with LLVM have nothing to do with cmake. Before devoting your time to implement yet-another-build-specification for LLVM, it is worth checking that the makefiles generated by cmake are indeed incompatible with BSD make. There are mixed reports on the 'Net. This is a simple guide for using cmake with LLVM: http://www.llvm.org/docs/CMake.html> What I could offer, would be to capture a llvm build as done with the current > Makefile setup,The current LLVM makefile setup is far from trivial. Plus this would generate yer another maintenance point.> and create a set of BSD Makefiles which would work with BSD > Makefiles and cooperate with the BSD template Makefiles (such as bsd.prog.mk, > bsd.lib.mk, etc). I think that the only thing that CMake is offering you is > that snazzy buildtime clock, but I think that's all.Speaking as the original implementator of the LLVM cmake build spec, I couldn't care less about the build time progress indicator. What cmake provides is a single, fairly simple specification that covers lots of platforms and build tools.> If you folks felt this would be desireable. If llvm gets brought into > any BSD, it's going to have to be created by the BSD involved, anyhow > ... well nearly all, I've seen recently that OpenBSD seems to be > making use of outside makefiles in outside sourced things like Perl. > But it would surely need BSD Makefiles for FreeBSD, and I'm pretty > sure for NetBSD also. They're not all that difficult to add in, I > could do that for you if you wanted.If incompatibilities of cmake and BSD make are found, maybe the cmake people can fix them once is made clear that those issues are blocking widespread usage on the BSD community. I can provide some help addressing specific issues with the LLVM cmake specification (not with cmake itself). -- Óscar
Hi, just chiming in here... Óscar Fuentes wrote:> [...] > > This is a simple guide for using cmake with LLVM: > > http://www.llvm.org/docs/CMake.html > > The makefiles distributed with LLVM have nothing to do with cmake. >From the few times I tried building LLVM with CMake I got the impressionthat it wasn't completely mature yet (the "TODO" sections in the page you mention above reinforce that impression). I remember at least one other build error in the past, related to building a non-X86 backend. With current svn I get: %> mkdir llvm-svn-build %> cd llvm-svn-build/ %> ccmake ../llvm-svn # Basically only tweak the install prefix in ccmake, configure, generate %> make ... [ 2%] Built target LLVMSupport [ 3%] Built target LLVMSystem Linking CXX executable ../../bin/tblgen ../../lib/libLLVMSystem.a(Mutex.cpp.o): In function `llvm::sys::Mutex::tryacquire()': Mutex.cpp:(.text+0x3f): undefined reference to `pthread_mutex_trylock' ../../lib/libLLVMSystem.a(Mutex.cpp.o): In function `llvm::sys::Mutex::Mutex(bool)': Mutex.cpp:(.text+0x1bb): undefined reference to `pthread_mutexattr_init' Mutex.cpp:(.text+0x216): undefined reference to `pthread_mutexattr_settype' Mutex.cpp:(.text+0x256): undefined reference to `pthread_mutexattr_setpshared' Mutex.cpp:(.text+0x2a3): undefined reference to `pthread_mutexattr_destroy' ../../lib/libLLVMSystem.a(Mutex.cpp.o): In function `llvm::sys::Mutex::Mutex(bool)': Mutex.cpp:(.text+0x309): undefined reference to `pthread_mutexattr_init' Mutex.cpp:(.text+0x364): undefined reference to `pthread_mutexattr_settype' Mutex.cpp:(.text+0x3a4): undefined reference to `pthread_mutexattr_setpshared' Mutex.cpp:(.text+0x3f1): undefined reference to `pthread_mutexattr_destroy' collect2: ld returned 1 exit status make[2]: *** [bin/tblgen] Error 1 make[1]: *** [utils/TableGen/CMakeFiles/tblgen.dir/all] Error 2 make: *** [all] Error 2 This is on a Core2Duo 32-bit Gentoo Linux system, where building with ./configure; make succeeds without problems. Best regards, Paul
Óscar Fuentes wrote:>> If you folks felt this would be desireable. If llvm gets brought into >> any BSD, it's going to have to be created by the BSD involved, anyhow >> ... well nearly all, I've seen recently that OpenBSD seems to be >> making use of outside makefiles in outside sourced things like Perl. >> But it would surely need BSD Makefiles for FreeBSD, and I'm pretty >> sure for NetBSD also. They're not all that difficult to add in, I >> could do that for you if you wanted. > > If incompatibilities of cmake and BSD make are found, maybe the cmake > people can fix them once is made clear that those issues are blocking > widespread usage on the BSD community. I can provide some help > addressing specific issues with the LLVM cmake specification (not with > cmake itself). >I never said it would block anything at all, and it won't. The BSD people will easily add in their own Makefiles. I can never understand why so many people find building Makefiles so terribly difficult, they seem simple enough to me. What you've folks accomplished WRT to LLVM and CLANG, now that's impressive! The Makefiles, sorry, that's kindergartener level stuff )(at least to me, and I don't intend any sort of insult in anything you wrote). It's certainly, easily possible to mrite truly complex Makefiles, but they don't need to be that way. I find it rather trivial to go from a listing of a successful build to making the makefile that drives it, a trivial task. If doing any of this is truly complex in CMake, well, that seems to me to be a comment in itself ... it's not in BSD Make. Someone said that maybe CMake is already compatible with BSD make, so I quicly went into one of your Makefiles and took out the first incompatibility I found. Means ONLY that CMake != BSD Make, that's all. Looks to me to be a great deal more like GNU Make, isn't that so? I'm going to offer you the patches, and leave it up to you whatever you do with it. I'll feel good about it, and if you decide that the best use is throw them away, that's your decision, I'm not going to do anything past answer any questions that occur. My own feeling is that adding in the ability to generate BSD Makefiles from Cmake files is going to tremendously compllicate the ability to fix build problems, things that would be simpler for folks on their (whatever)BSD systems to just add in their own makefiles on their own systems. BSD Make is going to make that easy enough to do, without even having to remove whatever makefiles you place in there. It'd leave things far more easy to troubleshoot. So, use it or don't, let's not argue the thing, ok?
Hi, Paul Melis wrote:> Hi, just chiming in here... > > Óscar Fuentes wrote: > >> [...] >> >> This is a simple guide for using cmake with LLVM: >> >> http://www.llvm.org/docs/CMake.html >> >> The makefiles distributed with LLVM have nothing to do with cmake. >> > >From the few times I tried building LLVM with CMake I got the impression > that it wasn't completely mature yet (the "TODO" sections in the page > you mention above reinforce that impression). I remember at least one > other build error in the past, related to building a non-X86 backend. > > With current svn I get: > > %> mkdir llvm-svn-build > %> cd llvm-svn-build/ > %> ccmake ../llvm-svn > # Basically only tweak the install prefix in ccmake, configure, generate > %> make > ... > [ 2%] Built target LLVMSupport > [ 3%] Built target LLVMSystem > Linking CXX executable ../../bin/tblgen > ../../lib/libLLVMSystem.a(Mutex.cpp.o): In function > `llvm::sys::Mutex::tryacquire()': > Mutex.cpp:(.text+0x3f): undefined reference to `pthread_mutex_trylock' > ../../lib/libLLVMSystem.a(Mutex.cpp.o): In function > `llvm::sys::Mutex::Mutex(bool)': > Mutex.cpp:(.text+0x1bb): undefined reference to `pthread_mutexattr_init' > Mutex.cpp:(.text+0x216): undefined reference to `pthread_mutexattr_settype' > Mutex.cpp:(.text+0x256): undefined reference to > `pthread_mutexattr_setpshared' > Mutex.cpp:(.text+0x2a3): undefined reference to `pthread_mutexattr_destroy' > ../../lib/libLLVMSystem.a(Mutex.cpp.o): In function > `llvm::sys::Mutex::Mutex(bool)': > Mutex.cpp:(.text+0x309): undefined reference to `pthread_mutexattr_init' > Mutex.cpp:(.text+0x364): undefined reference to `pthread_mutexattr_settype' > Mutex.cpp:(.text+0x3a4): undefined reference to > `pthread_mutexattr_setpshared' > Mutex.cpp:(.text+0x3f1): undefined reference to `pthread_mutexattr_destroy' > collect2: ld returned 1 exit status > make[2]: *** [bin/tblgen] Error 1 > make[1]: *** [utils/TableGen/CMakeFiles/tblgen.dir/all] Error 2 > make: *** [all] Error 2 > > This is on a Core2Duo 32-bit Gentoo Linux system, where building with > ./configure; make succeeds without problems. >I see the cmake build scripts were quickly updated, builds fine now with r72277 :) Paul
Paul Melis <llvm at assumetheposition.nl> writes:> Hi, just chiming in here... > > Óscar Fuentes wrote: >> [...] >> >> This is a simple guide for using cmake with LLVM: >> >> http://www.llvm.org/docs/CMake.html >> >> The makefiles distributed with LLVM have nothing to do with cmake. >>From the few times I tried building LLVM with CMake I got the impression > that it wasn't completely mature yet (the "TODO" sections in the page > you mention above reinforce that impression).What's immature is the documentation, mostly because it tries to go beyond what's really required. But on the other hand anyone who knows how to use cmake shouldn't need the documentation, except perhaps for the part that explains some variables specific to the LLVM build. (That part is complete). A TODO on the web page doesn't mean that the feature is missing. Cross compiling, for instance, should work (it worked when I tried months ago) but it is not documented. You need to read the cmake documentation for learning how to cross-compile. Right now the only fundamental thing missing on the cmake build spec is running the tests.> I remember at least one other build error in the past, related to > building a non-X86 backend. > > With current svn I get:[snip]> Mutex.cpp:(.text+0x3f): undefined reference to `pthread_mutex_trylock' > ../../lib/libLLVMSystem.a(Mutex.cpp.o): In function > `llvm::sys::Mutex::Mutex(bool)':[snip] Thanks! Fixed. BTW, bug reports are welcome. -- Óscar
Chuck Robey <chuckr at telenix.org> writes: [snip]> Someone said that maybe CMake is already compatible with BSD make, so > I quicly went into one of your Makefiles and took out the first > incompatibility I found. Means ONLY that CMake != BSD Make, that's > all. Looks to me to be a great deal more like GNU Make, isn't that > so?As said on my previous reply to you, the makefiles distributed with LLVM are not related to CMake. [snip]> My own feeling is that adding in the ability to generate BSD Makefiles > from Cmake files is going to tremendously compllicate the ability to > fix build problems,Maybe there is a common misunderstanding here. CMake is not a build tool, it is a build generator tool. That means that it competes with the GNU autotools, for instance, but not with make, or gmake. CMake generates makefiles (or project files for XCode, Visual Studio, etc) so it actually requires some other tool (`make' in your case) for the actual build. This is why I'm suggesting that you should check if CMake generates makefiles compatible with BSD make, instead of writing (and maintaining) them yourself. LLVM is a fast moving target: adding, moving and removing source files and library requirements is common. Ah, and as you may prefer to avoid the autotools, you need a BSD-specific config.h file, don't you? In principle, CMake can provide this too. Please note that I'm just trying to avoid some possibly unnecesary work, in the case that the current stuff we have does what you need. [snip] -- Óscar