Hi, Óscar Fuentes wrote:> Chuck Robey <chuckr at telenix.org> writes: > > >>> Just checked that the makefiles generated by cmake work with `make' on >>> FreeBSD 7.2 x86. The build fails while building `opt' because libdl is >>> missing. >>> >> They absolutely do work, even on FreeBSD-current( I run that here), >> but not using the native make (the one built as part of "make world" >> which is a direct descendant of "pmake". You have to use the GNU >> make, >> > > Uh? My FreeBSD installment has `make' and no `gmake'. `make' is indeed > BSD make. > > 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... Regards, Paul
Paul Melis wrote:> Hi, > > Óscar Fuentes wrote: >> Chuck Robey <chuckr at telenix.org> writes: >> >> >>>> Just checked that the makefiles generated by cmake work with `make' on >>>> FreeBSD 7.2 x86. The build fails while building `opt' because libdl is >>>> missing. >>>> >>> They absolutely do work, even on FreeBSD-current( I run that here), >>> but not using the native make (the one built as part of "make world" >>> which is a direct descendant of "pmake". You have to use the GNU >>> make,Both BSD Make and GNU make run on FreeBSD (as long as you do install GNU Make, because it's not part of the base install, however 90% of folks will install it. They coexist with no problem.>>> >> 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...Let me explain a bit. Things that are part of FreeBSD ports are built using whatever build tool is called for, but if it's brought in as part of the FreeBSD base code (as I expect llvm will be) then there will be additional Makefiles provided by FreeBSD programmers (in separate directories, they won't interfere or overwrite the Makefiles that come with llvm, they'll just use source pathing to refer to the source files, and force the build to be run via BSD Make) so that the build can be guided by the BSD Make. Unless you understand how Make works (and this feature works for both GNU Make and BSD Make, if under different names, the GNU Make folks call this VPATH) then you might not even realize that BSD Make is in control. I would. There is already a llvm *port*, it's using whatever is native to llvm, it looks like CMake is provided, but GNU Make compatible Makefiles (via configure) are being used. I looked at the Makefiles being produced, they're not bmake compatible. I don't care what they claim, look at the actual Makefiles being produced. I already gave you a couple of very easy to spot sentinels, ways you can absolutely prove the code is or is not GNU Make(gmake), or BSD Make (bmake): look for the conditionals, they don't look alike, and they aren't cross compatible. One obvious example is the gmake uses "ifeq" there bmake uses ".if (var1==var2)". If you spot a "ifeq" then you can argue that it's bmake all you want, you'd still be wrong. I don't know CMake all that well, I believe it can generate gmake compatible Makefiles, but if it puts something like "ifeq" into the Makefiles it produces, then don't believe the documentation that says it's cross compatible with BSD, it won't be, the ifeq constructs are clear evidence. 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?
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
@Chuck Robey Before you pass judgment on CMake quit using those existing makefiles or the configure scripts. They are NOT GENERATED BY CMAKE. Start by downloading CMAKE from http://cmake.org/ and continue the process outlined in the build instructions that we keep trying to tell you to use and you keep ignoring completely. Perhaps you didn't understand what I said earlier when I said we are TRANSITIONING AWAY from AUTOTOOLS/CONFIGURE. They are still present in the build because the transition away from them isn't complete yet. CMake doesn't require those files at all since it does its thing totally differently.