llvm dev - Jul 2008 - [LLVMdev] Is there room for another build system?

[Repost: The mailing list was down yesterday. Sorry if this is a
duplicate]

I'm evaluating CMake (1) primarily as an alternative build system for
Visual Studio users, although it can easily be a replacement for
`configure' and hand-made makefiles too, providing a single build system
for all platforms. CMake is a tool that takes a project description and
configures, generates makefiles, project files for IDEs, etc as
requested.

There are three MS C++ compilers capable of compiling LLVM: Visual
Studio 2003, 2005, 2008 and their respective "free tools"
edition. However, the project files distributed with LLVM are for
2005. This means that people using 2003 is left in the cold and people
who only have 2008 must convert the project files and, most important,
can't contribute to the maintenance of the VC++ build.

CMake can generate Visual Studio project files (for all three versions)
and NMake makefiles. This solves the schism among Visual Studio users.

Furthermore, CMake can replace `configure' and generate gmake makefiles,
project files for XCode, etc.

In just an afternoon I hacked CMake specifications for the LLVM
libraries and successfully built the fibonacci example. Most of the time
consisted on just waiting for the build to complete on each
experimentation cycle, so I stimate that was less that 2 hours of real
activity. This without previous knowledge of CMake (nor of the VC++
build). So my impression is quite favorable.

CMake just requires one plain text file named CMakeLists.txt on every
source directory, and the only maintenance is to keep up to date the
list of source files of the directory. So, the work it causes is no more
than the current VC++ build. Anyone, even those who doesn't have the
Visual Studio IDE, can do it. It's pretty trivial.

Now, my questions:

 1. General LLVM users: Are you so happy with `configure' and hand-made
 makefiles that you wont consider an alternative? If you are interested,
 I can steer my work to cover all platforms.

 2. VC++ users: Are you interested on a tool that generates project
 files or makefiles for your IDE or your free VC++ compiler, and with a
 simpler maintenance?

 3. LLVM administrators: Do you object to having a CMakeLists.txt file
 on every source directory?

Obviously, if the answer to 3 is `yes', previous questions are
irrelevant :-)

(1): http://www.cmake.org

-- 
Oscar

Hi Oscar,

On 30-Jul-08, at 9:41 AM, Óscar Fuentes wrote:
> 1. General LLVM users: Are you so happy with `configure' and hand-made
> makefiles that you wont consider an alternative? If you are  
> interested,
> I can steer my work to cover all platforms.
We (RapidMind) are very interested. We would very much like to see a  
unified build system across MSVC/Windows and gcc/Linux/OS X.

We have considered contributing such a build system, and if we were to  
do so would probably base it on SCons (http://www.scons.org/) because  
we already use SCons extensively. I have a small prototype of this.  
We're not really partial to a particular implementation though, as  
long as it allows a unified, scriptable, build environment across the  
various platforms. SCons has the nice property that its build scripts  
are Python, so you can do just about anything with it.
> 2. VC++ users: Are you interested on a tool that generates project
> files or makefiles for your IDE or your free VC++ compiler, and with a
> simpler maintenance?
Yes :)

Are you intending for your build system to support all the features of  
the existing make-based build system, e.g. running the test suite,  
supporting cross compilation, etc.?

--
Stefanus Du Toit <stefanus.dutoit at rapidmind.com>
   RapidMind Inc.
   phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463

On Jul 30, 2008, at 9:41 AM, Óscar Fuentes wrote:
> I'm evaluating CMake (1) primarily as an alternative build system for
> Visual Studio users, although it can easily be a replacement for
> `configure' and hand-made makefiles too, providing a single build  
> system
> for all platforms. CMake is a tool that takes a project description  
> and
> configures, generates makefiles, project files for IDEs, etc as
> requested.
Ok.  Killing off autoconf would be a huge bonus, but should probably  
be done as a second step.
> There are three MS C++ compilers capable of compiling LLVM: Visual
> Studio 2003, 2005, 2008 and their respective "free tools"
> edition. However, the project files distributed with LLVM are for
> 2005. This means that people using 2003 is left in the cold and people
> who only have 2008 must convert the project files and, most important,
> can't contribute to the maintenance of the VC++ build.
Yes, this is a problem.  We also support Xcode to various degrees on  
the mac, and keeping all these project files in sync with the  
makefiles is a pain.
> Furthermore, CMake can replace `configure' and generate gmake  
> makefiles,
> project files for XCode, etc.
Having one point of truth would be great.
> Now, my questions:
>
> 1. General LLVM users: Are you so happy with `configure' and hand-made
> makefiles that you wont consider an alternative? If you are  
> interested,
> I can steer my work to cover all platforms.
I would prefer to kill off makefiles if we have something better.  We  
really only want to support one build system.
> 3. LLVM administrators: Do you object to having a CMakeLists.txt file
> on every source directory?
No, particularly if it means we eventually lose the Makefile :).

One trick is that we want to keep llvm-config and the  
'LINK_COMPONENTS' system used when building tools.  I am sure cmake  
can handle this, but I just wanted to mention that it is important.

-Chris

Chris Lattner <clattner at apple.com> writes:
> Ok.  Killing off autoconf would be a huge bonus, but should probably  
> be done as a second step.
My plan is a staged one:

First, support MSVC++.

Second, implement what `configure' does now. MSVC++ users would be the
first ones to take advantage of this, instead of the current hack Visual
Studio does.

Finally, add capabilities for replacing current hand-made makefiles on
all platforms.

Once the work is done, killing off autoconf and hand-made makefiles is
up to you. CMake can live with them and the amount of maintenance work
it adds is minimal.

[snip]
>> 1. General LLVM users: Are you so happy with `configure' and
hand-made
>> makefiles that you wont consider an alternative? If you are  
>> interested,
>> I can steer my work to cover all platforms.
>
> I would prefer to kill off makefiles if we have something better.  We  
> really only want to support one build system.
My knowledge of the LLVM build system is far from complete, but right
now there is one feature which I think is tricky to implement on CMake:
if you add/remove a source file, the build system we have now does the
right thing. In CMake, you are required to update the list of source
files on the CMakeLists.txt file. Actually, it is possible for CMake to
read the contents of the source directory on the configure phase, but
this disallows other interesting things.

Other tricky thing is to integrate user code on the LLVM build
system. I'm thinking on people who is coding their own extensions to
LLVM, for instance, and that work outside the LLVM source tree.

I need to read again the docs about the LLVM build system.
>> 3. LLVM administrators: Do you object to having a CMakeLists.txt file
>> on every source directory?
>
> No, particularly if it means we eventually lose the Makefile :).
Okay, I'll keep working on this project then.
> One trick is that we want to keep llvm-config and the  
> 'LINK_COMPONENTS' system used when building tools.  I am sure cmake
> can handle this, but I just wanted to mention that it is important.
Actually, I plan to use llvm-config (and LINK_COMPONENTS) even for VC++
users :-). Probably as an alternative, as some Visual Studio users would
complain if Perl is a requirement for building LLVM.

-- 
Oscar

Stefanus Du Toit <sdt at rapidmind.com> writes:

[snip]
> We have considered contributing such a build system, and if we were to  
> do so would probably base it on SCons (http://www.scons.org/) because  
> we already use SCons extensively.
At first, SCons is what I intended too. But then I read about the KDE
experience and took the safe route :-)

[snip]
> Are you intending for your build system to support all the features of  
> the existing make-based build system, e.g. running the test suite,  
> supporting cross compilation, etc.?
My initial plan was: if the LLVM devs are interested, go for the whole
pie; if just VC++ people is interested, restrict to VC++. Now that Chris
showed interest, I'll aim at fully replacing the current
system. However, as I'm just learning CMake and the LLVM build system,
things will come as my technical possibilities allows.

Thanks for your feedback.

-- 
Oscar

Hi,
> CMake just requires one plain text file named CMakeLists.txt on every
> source directory, and the only maintenance is to keep up to date the
> list of source files of the directory.
can it be kept up-to-date automagically?  After all, you can query
subversion to get the list of all files in a directory.
>  1. General LLVM users: Are you so happy with `configure' and hand-made
>  makefiles that you wont consider an alternative? If you are interested,
>  I can steer my work to cover all platforms.
Do ordinary users need to have cmake if they want to build llvm?
If so, that's bad because they'll have to install it (unlike the
current setup, where only very standard tools are needed).

Ciao,

Duncan.

Duncan Sands <baldrick at free.fr> writes:
> Hi,
>
>> CMake just requires one plain text file named CMakeLists.txt on every
>> source directory, and the only maintenance is to keep up to date the
>> list of source files of the directory.
>
> can it be kept up-to-date automagically?  After all, you can query
> subversion to get the list of all files in a directory.
Yes, it can, but CMake would do this at configure time, which means that
you'll need to explicitly invoke CMake. If you alter the CMakeLists.txt
file to reflect your change, next time you invoke your build (gmake,
nmake, Visual Studio...) it automatically notices this and does the
right thing.

Please note that CMake (unlike SCons) is not a replacement for `make',
it is a makefile generator, so the amount of intelligence it can inject
on its output (makefiles, Visual Studio projects, etc) is limited.
> Do ordinary users need to have cmake if they want to build llvm?
Yes.
> If so, that's bad because they'll have to install it (unlike the
> current setup, where only very standard tools are needed).
That's something to count on the `against' side, yes.

-- 
Oscar

Duncan Sands wrote:
> Do ordinary users need to have cmake if they want to build llvm?
> If so, that's bad because they'll have to install it (unlike the
> current setup, where only very standard tools are needed).
That's not the only problem with cmake. The autotools may be a big and 
ugly beast, but that's because they're trying to solve a big and ugly 
problem for which there is no silver bullet. And they are still much 
more comprehensive than cmake. I've considered cmake time and again for 
my own projects, but I don't think that it's quite there yet. Here are 
some points worth considering: http://www.remlab.net/op/cmake.shtml 
(Some of these may already be addressed in newer cmake versions, I 
haven't checked recently.)

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag

>
>
> 2. VC++ users: Are you interested on a tool that generates project
> files or makefiles for your IDE or your free VC++ compiler, and with a
> simpler maintenance?
>
Yes!

Already with a feature request - can it test for the required tools  
(bison/flex) are present and usable?

Cheers
George

On Jul 30, 2008, at 12:59 PM, George Russell wrote:
>>
>>
>> 2. VC++ users: Are you interested on a tool that generates project
>> files or makefiles for your IDE or your free VC++ compiler, and  
>> with a
>> simpler maintenance?
>>
>
> Yes!
>
> Already with a feature request - can it test for the required tools
> (bison/flex) are present and usable?
I don't think flex is required.  Bison is currently needed for one  
file (llvmAsmParser.y) AFAIK, which really needs to be rewritten anyway.

-Chris

George Russell <grrussel at googlemail.com> writes:
> Already with a feature request - can it test for the required tools  
> (bison/flex) are present and usable?
Yes, at configure time.

Thanks for your feedback.

-- 
Oscar

On Wed, Jul 30, 2008 at 6:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> I'm evaluating CMake (1) primarily as an alternative build system for
> Visual Studio users, although it can easily be a replacement for
> `configure' and hand-made makefiles too, providing a single build
system
> for all platforms. CMake is a tool that takes a project description and
> configures, generates makefiles, project files for IDEs, etc as
> requested.
I've been using CMake already with LLVM for some time. I've managed to
build most of the libraries, though there are some issues left and I
haven't tested the things I don't use. I posted about it on this list
twice already but I didn't get any response.

The latest one is here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-June/015541.html

It has a patch attached, so you can use the code if it's useful.


Regards,
Kevin André

Hi Kevin.

HyperQuantum <hyperquantum at gmail.com> writes:
> I've been using CMake already with LLVM for some time. I've managed
to
> build most of the libraries, though there are some issues left and I
> haven't tested the things I don't use. I posted about it on this
list
> twice already but I didn't get any response.
>
> The latest one is here:
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-June/015541.html
>
> It has a patch attached, so you can use the code if it's useful.
I found your work yesterday while searching the archives, and planned to
contact you once started with the non-VC++ platforms. Your work will be
very useful. Let's see if I solve the problems you found.

Thanks!

-- 
Oscar

Óscar Fuentes wrote:
> CMake just requires one plain text file named CMakeLists.txt on every
> source directory, and the only maintenance is to keep up to date the
> list of source files of the directory.
Has anyone read "Recursive Make Considered Harmful"?

    http://miller.emu.id.au/pmiller/books/rmch/
    http://aegis.sourceforge.net/auug97.pdf

I have been using single top level Makefiles (and automake Makefile.am)
for some time. For me they are far more reliable and maintainable. I have
not yet tried CMake.

For a large project using a single top level Makefile see the Linux
kernel sources.

Does CMake not support a non-recursive style usage?

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"The music business is a cruel and shallow money trench, a long
 plastic hallway where thieves and pimps run free, and good men
 die like dogs. There's also a negative side."
   -- Hunter S. Thompson

On Thursday 31 July 2008, Erik de Castro Lopo wrote:
> Óscar Fuentes wrote:
> > CMake just requires one plain text file named CMakeLists.txt on every
> > source directory, and the only maintenance is to keep up to date the
> > list of source files of the directory.
>
> Has anyone read "Recursive Make Considered Harmful"?
>
>     http://miller.emu.id.au/pmiller/books/rmch/
>     http://aegis.sourceforge.net/auug97.pdf
>
> I have been using single top level Makefiles (and automake Makefile.am)
> for some time. For me they are far more reliable and maintainable. I have
> not yet tried CMake.
>
> For a large project using a single top level Makefile see the Linux
> kernel sources.
>
> Does CMake not support a non-recursive style usage?
Certainly, you can just use one top level CMakeLists.txt if you want. But I am 
not convinced that the issue of the paper are still valid for cmake.

-- 
Cyrille Berger

Óscar Fuentes wrote:
> I'm evaluating CMake (1) primarily as an alternative build system for
> Visual Studio users, although it can easily be a replacement for
> `configure' and hand-made makefiles too, providing a single build
system
> for all platforms. CMake is a tool that takes a project description and
> configures, generates makefiles, project files for IDEs, etc as
> requested.
As a potential user of LLVM, I'm very happy to see some activity around 
the build system. If my company goes the LLVM route, we will want good 
support for building LLVM from the command-line both on Windows (MSVC + 
MinGW) and on Linux. I'm a little bit concerned by the fact that VS 
projects will be the only way to build LLVM with MSVC. Will the 
CMake-based approach support generating makefiles for MSVC builds?

I also have some concerns on the approach followed by CMake, but I've 
never tried it, so I might be completely wrong. The first concern is 
that generating makefiles, solutions, projects forces the build system 
to inherit the limitations of the supported underlying build tools; for 
instance, generated makefiles will still use timestamps to trigger 
recompilations, instead of digests on the content (which is much more 
robust and can avoid a lot of useless recompilations). Another typical 
limitation of make is the way dependencies are computed. With CMake, are 
dependencies computed when makefiles are generated, or by makefiles 
themselves? In both case, I guess the developer needs to perform some 
explicit action when dependencies changes, otherwise things might work 
well on his current tree but fail in a clean checkout.

Also, if Makefiles are to be generated for Windows, things like 
supporting pathnames properly and escaping is really tricky (or does 
CMake do a perfect job here?). Since most developpers won't be able to 
test their changes to the build system on all platforms, I expect the 
system to be broken quite often.

An approach like scons, which does not rely on legacy tools, seems more 
robust to me. At least we can expect a similar behavior of the build 
system on all the supported platforms. I haven't tried scons itself, but 
my company is happily using the OMake build system

http://omake.metaprl.org/index.html

OMake has binary packages for several architecture and it does not 
depend on external tools. It comes with a cross-platform and high-level 
shell built-in. Automatic dependencies are computed dynamically, and 
recompilation is triggered by digests, not timestamps. We build our 
entire system on Windows (both with MSVC and MinGW) and on Linux, and we 
are very happy with it. If anyone is interested to evalute whether OMake 
would be a good solution for LLVM, I'm willing to provide help and some 
resources (although I won't be able to do the whole thing myself).


-- Alain

Alain Frisch <alain.frisch at lexifi.com> writes:

[questions which are specific of CMake and not LLVM-related should be
directed to its mailing list. See www.cmake.org]
> Will the CMake-based approach support generating makefiles for MSVC
> builds?
Yes.
> generated makefiles will still use timestamps to trigger 
> recompilations, instead of digests on the content
Makefiles uses timestamps, as this is the way makefiles work, other
build tools supported by CMake could use digests, I don't know.
> With CMake, are dependencies computed when makefiles are generated, or
> by makefiles themselves?  In both case, I guess the developer needs to
> perform some explicit action when dependencies changes, otherwise
> things might work well on his current tree but fail in a clean
> checkout.
AFAIK, when you modify an implicit dependency (i.e. add/remove an
#include to some .cpp file) or an explicit one (i.e. add/remove a source
file from a library or executable, change the list of libraries that an
executable uses, etc) CMake-generated makefiles do the right thing,
which may include re-generating the makefiles themselves. I don't know
about Visual Studio project files.
> Also, if Makefiles are to be generated for Windows, things like 
> supporting pathnames properly and escaping is really tricky (or does 
> CMake do a perfect job here?).
Quoting may be an issue. This all depends on what external tools you
need to invoke. For compilers and linkers, CMake does the right thing,
unless you use absolute Windows paths and then execute CMake on Unix,
etc.
> An approach like scons, [snip] but 
> my company is happily using the OMake build system
[snip]

CMake and SCons are different beasts. SCons (and OMake?) are `make'
replacements, while CMake is a configuration/makefile generator.

Anyways, for the time being, I'm committed to CMake. I don't mind others
trying different tools and, if you come with a new LLVM build system
that supports VC++ 2003 and up, I'll happily throw away my work with
CMake.

-- 
Oscar