[LLVMdev] Building LLVM with cmake on FreeBSD

Paul Melis llvm at assumetheposition.nl
Wed May 27 14:20:17 PDT 2009


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



More information about the llvm-dev mailing list