Chuck Robey wrote:>>>> >>>> >>> Uh? My FreeBSD installment has `make' and no `gmake'. `make' is indeed >>> BSD make. >>> > > In your FreeBSD system, do an "ls -d /var/db/pkg/gmake*" and see if any > directory shows up. If it does, then the only argument you can have is what > name you installed it under, not whether it's there or not, it is. GNU Make, > and NOT BSD Make, will respond to the -v parameter with version info. BSD make > won't do that. > > >>> So, to recap, right now LLVM svn builds fine on FreeBSD 7.2 using BSD >>> `make' with the makefiles generated by cmake. >>> >>> >> I quickly browsed the CMake 2.6.2 source and their does not seem to be a >> special case for BSD in the makefile generator code. >> It seems that the makefiles generated by cmake use the subset of >> features that is shared by BSD make and GNU make >> (http://www.cmake.org/pipermail/cmake/2004-March/004881.html), so >> building with either BSD make or GNU make should work. >> >> However, I also noticed that KDE4 uses CMake these days and on a page >> (http://techbase.kde.org/Getting_Started/Build/KDE4/FreeBSD) that >> describes building on FreeBSD it says "Sometimes, building with *make* >> can fail on some modules. You should try using *gmake* instead." So >> perhaps YMMV... >> > > [snip] > > It's NOT possible to make a single Makefile, one that has conditionals in it, be > compatible with both bmake and gmake, because their conditionals don't look > alike. It's possible to produce a bmake or gmake compatible makefile, but I > haven't seen any project do that, actually. Certainly, you can write (for the > autoconf) a Makefile.in that would be compatible with bmake, but I never saw > that actually done, have you? >You assume that the makefiles CMake produces need to do some kind of conditional stuff. I don't think they do anything like that, as that has already been resolved on a higher level, i.e. with CMake's own little language used in the CMakeLists.txt files. In fact, the generated makefiles DO seem to be usable by both GNU make and BSD make. Here's an example of "the other way around": BSD make on a Gentoo Linux system building LLVM from CMake-generated makefiles: 23:15|melis at juggle2:~/c/llvm-svn> svn up U include/llvm/Analysis/ScalarEvolution.h U tools/bugpoint/CrashDebugger.cpp U lib/Analysis/ScalarEvolution.cpp U lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp U lib/CodeGen/SelectionDAG/LegalizeDAG.cpp U lib/Target/ARM/ARMBuildAttrs.h U lib/Target/X86/README.txt U lib/Transforms/Scalar/IndVarSimplify.cpp Updated to revision 72399. 23:15|melis at juggle2:~/c/llvm-svn> cd ../llvm-svn-build/ 23:16|melis at juggle2:~/c/llvm-svn-build> ccmake . # configure, generate 23:16|melis at juggle2:~/c/llvm-svn-build> gmake -v GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i686-pc-linux-gnu 23:17|melis at juggle2:~/c/llvm-svn> bmake -v # checking that this is indeed BSD make, and not GNU make usage: bmake [-BeikNnqrstWX] [-D variable] [-d flags] [-f makefile] [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file] [-V variable] [variable=value] [target ...] 23:17|melis at juggle2:~/c/llvm-svn-build> bmake [ 6%] Built target LLVMSupport [ 8%] Built target LLVMSystem [ 13%] Built target tblgen [ 13%] Building Intrinsics.gen... [ 14%] Built target intrinsics_gen [ 20%] Built target LLVMCore [ 33%] Built target LLVMCodeGen Scanning dependencies of target LLVMSelectionDAG [ 33%] Building CXX object lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/LegalizeDAG.cpp.o [ 33%] Building CXX object lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/LegalizeVectorOps.cpp.o Linking CXX static library ../../libLLVMSelectionDAG.a [ 37%] Built target LLVMSelectionDAG [ 39%] Built target LLVMAsmPrinter [ 40%] Built target LLVMBitReader [ 41%] Built target LLVMBitWriter Scanning dependencies of target LLVMTransformUtils [ 41%] Building CXX object lib/Transforms/Utils/CMakeFiles/LLVMTransformUtils.dir/LCSSA.cpp.o Linking CXX static library ../../libLLVMTransformUtils.a [ 47%] Built target LLVMTransformUtils etc... So when using CMake you only need to know ITS configuration file syntax and none of the GNU make/BSD make stuff. That's the whole point of CMake: giving you a high-level cross-platform build environment that hides the actual build tools used (make on Unices, Visual Studio on Windows, etc). Regards, Paul
Paul Melis wrote:> You assume that the makefiles CMake produces need to do some kind of > conditional stuff. I don't think they do anything like that, as that has > already been resolved on a higher level, i.e. with CMake's own little > language used in the CMakeLists.txt files. In fact, the generated > makefiles DO seem to be usable by both GNU make and BSD make. > Here's an example of "the other way around": BSD make on a Gentoo Linux > system building LLVM from CMake-generated makefiles:[massive eliding] I've said this VERY often now, I can't see why no one ever refers to it. I said that, for FreeBSD, when they bring llvm into their build, it's a virtual certainty that the BSD style makefiles will be added to the llvm build, probably in some parallel dir tree, inside FreeBSD. This will be done in a way that affects the llvm project not one little bit, you won't even be aware of it, but I don't see anyone who is going to be willing to toss away the BSD build system, which allows modification of the BSD build as it suits, to instead try to bring in a brand new build system that works totally differently than our present one, and allows no ability to change the build from the BSD build environment. The current build of llvm on FreeBSD is managed from the FreeBSD ports system, and uses whatever your build system offers. In bringing it into our base build, we want some more control, some more build standardization, as long as we can manage this without bothering you, and we CAN do this, we've been doing it for years now with gcc. The GNU folks probably aren't (in the main) even aware of this. I do want to answer your point about conditionals: they ARE there in the CMake-generated GNU Make-Makefiles, allowing a user of GNU Make to have some local control (as they are used to) over their local environment without having to learn CMake. If such is deemed needed for GNU Make, why is it ok to treat anyone using a BSD Make system as a poor cousin? Not that it's going to really affect us (we'll be using our own tree of Makefiles) but it rankles. Those old SYSV Makefiles are only there because they're the stupidest. I could offer you BSD Makefile templates, if someone in llvm would learn enough CMake to figure out how to integrate them into CMake. Cmake is your tool, not mine, remember. However, as I said in the first paragraph, maybe it's better for you to just ignore things, because llvm builds for most folks as it stands. If it matters (and I don't think it really does) I like the way that some build systems used to do it, which was to maintain Makefile sets for each OS. Let each of those OSes supply their own Makefiles to you. A system like this could be engineered with little bother, and the things that change (like new source files) be managed with simple scripts, and less maintenance from you than your present system. Everybody gets the very best local integration, your problems are far less, and every one is happy. On top of that, anyone who finds a build problem on their local build environment (for whatever reason) is more likely to have a simpler time fixing it. That's my opinion, but don't bother to argue it, because I know it doesn't matter in this discussion, and it's just my own opinion. However, even if you used my suggestion, it would still be fairly likely that the folks in the BSD systems would want to have their own makefiles, since they CAN do this without bothering you. I couldn't say for sure, then, really.> > Regards, > Paul > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi, Chuck Robey wrote:> Paul Melis wrote: > >> You assume that the makefiles CMake produces need to do some kind of >> conditional stuff. I don't think they do anything like that, as that has >> already been resolved on a higher level, i.e. with CMake's own little >> language used in the CMakeLists.txt files. In fact, the generated >> makefiles DO seem to be usable by both GNU make and BSD make. >> Here's an example of "the other way around": BSD make on a Gentoo Linux >> system building LLVM from CMake-generated makefiles: >> > > [massive eliding] > > I've said this VERY often now, I can't see why no one ever refers to it. I > said that, for FreeBSD, when they bring llvm into their build, it's a virtual > certainty that the BSD style makefiles will be added to the llvm build, probably > in some parallel dir tree, inside FreeBSD. This will be done in a way that > affects the llvm project not one little bit, you won't even be aware of it, but > I don't see anyone who is going to be willing to toss away the BSD build system, > which allows modification of the BSD build as it suits, to instead try to bring > in a brand new build system that works totally differently than our present one, > and allows no ability to change the build from the BSD build environment. >This is getting way off-topic, apologies to the rest of the list, but out of curiousity, did you check how KDE4 is built on FreeBSD? I don't have a FreeBSD system, but from everything I read (including the ports pages) it seems the KDE4 packages in ports do have a few BSD makefiles, but they call CMake to do the actual building. So you might have some configuration switches available when running bmake, but the build system wasn't REPLACED, it was merely augmented (or wrapped if you like). For LLVM I could imagine the FreeBSD devs doing the same, but completely redoing the makefiles (as you have now more than once told us you suspect will happen) just because you prefer BSD make over GNU make or CMake seems like a complete waste of time.> The current build of llvm on FreeBSD is managed from the FreeBSD ports system, > and uses whatever your build system offers. In bringing it into our base build, > we want some more control, some more build standardization, as long as we can > manage this without bothering you, and we CAN do this, we've been doing it for > years now with gcc. The GNU folks probably aren't (in the main) even aware of this. >I'm not an LLVM dev, so I can't respond to these things other than saying that if that is the way the FreeBSD devs want to go I won't stop them.> I do want to answer your point about conditionals: they ARE there in the > CMake-generated GNU Make-Makefiles, allowing a user of GNU Make to have some > local control (as they are used to) over their local environment without having > to learn CMake.I'm not sure what kind of local control you mean here, but when I build packages that use CMake (VTK, OpenSceneGraph, LLVM, all quite frequently) my usage of GNU make can be put in a very limited list: make, make install, make clean. All other configuration/build settings are done through CMake. It occurs to me that we have a fundamentally different view on the *purpose* of makefiles when using CMake. For me, they are an implementation detail, as CMake is my entry point for controling a build. I wouldn't care if makefiles weren't used at all, but I suspect the CMake devs did not want to duplicate lots of the handy stuff make can do for you (like dependency checking) in the CMake tools itself, so makefiles where chosen as CMake's implementation 'platform'. This in contrast with something like SCons, which basically duplicates everything make can do and then some. On the other hand, you, it seems (to me), want (some) control through makefiles no matter what. You have every right to want that, of course, but I don't see the added value. Looking at some of the stuff in FreeBSD ports, however, it seems bsd make is also used for managing package dependencies and much more, stuff that is done with dedicated tools on other distributions (like rpm, debs, ebuilds). So if all this time you were talking about the use of bmake *on that level* then we have been completely miscommunicating. Package management is something that should be done per distribution, and shouldn't influence a library's build system.> If such is deemed needed for GNU Make, why is it ok to treat > anyone using a BSD Make system as a poor cousin? Not that it's going to really > affect us (we'll be using our own tree of Makefiles) but it rankles. Those old > SYSV Makefiles are only there because they're the stupidest. I could offer you > BSD Makefile templates, if someone in llvm would learn enough CMake to figure > out how to integrate them into CMake. Cmake is your tool, not mine, remember. > However, as I said in the first paragraph, maybe it's better for you to just > ignore things, because llvm builds for most folks as it stands. >I can only reiterate what I told you before: the makefiles generated by CMake are supposedly usable for building with both bmake and gmake. If not, it is probably a bug.> If it matters (and I don't think it really does) I like the way that some build > systems used to do it, which was to maintain Makefile sets for each OS. Let > each of those OSes supply their own Makefiles to you. A system like this could > be engineered with little bother, and the things that change (like new source > files) be managed with simple scripts, and less maintenance from you than your > present system. Everybody gets the very best local integration, your problems > are far less, and every one is happy. On top of that, anyone who finds a build > problem on their local build environment (for whatever reason) is more likely to > have a simpler time fixing it. That's my opinion, but don't bother to argue it, > because I know it doesn't matter in this discussion, and it's just my own opinion. >I think I'm done with this discussion.... Paul