is configure+make dead yet?

Note that the LLVM documentation (e.g., ) treats the configure-and-make build system as canonical, and I recall when I first used the cmake build system, I was told that one thing I was trying to do was unsupported in the cmake build (I’ve forgotten what it was though).

Charles Davis <cdavis@mymail.mines.edu> writes:

Now hold on there. I thought Daniel was supposed to be working on a
new build system, based almost entirely in Python, specifically
because he thought CMake was, uh... inadequate (to say the
least). I've CC'd him in the hopes of getting his opinion.

It's curious how things pervade through the time... The "new build
system" that you mention was (is?) a unification layer on top (or
between, or whatever) of both existing build systems, supposedly for
decreasing maintenance work and for adding shiny,
not-yet-specified-but-extremely-cool features. Now LLVM may end with a
single build system but with the unification layer still attached that
adds nothing but obfuscation, complexity and the python requirement for
building LLVM.

Oh irony.

[snip]

As do the Debian/Ubuntu packaging scripts. I'm sure that they can be
changed to use the cmake build system instead, but someone will have to
do the work.

This issue comes up every once in a while. I'm sure that there are other
LLVM users who prefer autoconf over cmake and therefore appreciate that
LLVM still supports it. Of course, that's a matter of preference and
experience and I can understand that the LLVM developers have better
things to do than supporting two separate build systems. I just wished
that the favoured alternative wasn't cmake. :wink:

Albert

Oscar,

Anton, I've posted this information several times on this list, IIRC
some of them after you claimed that cmake can't cross-compile, so I hope
this is cleared once and for all:
http://llvm.org/docs/CMake.html#cross

cmake certainly can crosscompile. But will you please provide the
exact list of options / flags which is necessary to cross-compile
llvm/clang from, say, linux/darwin to mingw32?
Note that tablege and some support libs need to be configured / built
for both build and host systems, so, this certainly won't work out of
the box :slight_smile:

OK, I'm speaking up: We *really* need configure+make to stick around a bit longer. Daniel has had to spend lots of time on other projects that came up, especially fighting against compile time performance regressions, so the new LLVM build system has not made much progress recently. As discussed in depth before, Cmake is not a good solution for us and we need configure+make to keep working until we have a suitable replacement.

So what would we need to change in cmake to make it a good solution for you?

Cheers,
/Manuel

There's this:
'address sanitizer does not work if clang is built with CMake'
<http://llvm.org/bugs/show_bug.cgi?id=12272>

(PS: +1 for switching to CMake.)

Hi Nick,

FWIW, I felt some pain moving from autoconf to cmake. However, once I got familiar with controlling camke a little better and editing CMakeLists.txt, the comfort grew and I came to appreciate its advantages over autoconf. CMakeLists.txt are far easier to create and to maintain and I wouldn't really mind if autoconf would be deprecated here. I understand that the transition would be perhaps painful to many and at the same time, but, except for any particular situations that cmake doesn't cover, I think that it would be for the better.

I don't care much about make, but configure is important for the
bootstrap of LLVM and Clang on NetBSD. Requiring cmake (or Python for
that matter) would be very heavy.

Joerg

Do you have something against tool that makes usage of cmake at least hardly bearable?

Hi

Speaking about a good existing build system in python, there is waf : http://code.google.com/p/waf/
It is in my opinion far more better than cmake on any point (performance, flexibility, easy to use, …) …

Please don’t bring up yet-another-build-system. The only build systems that are relevant to this discussion are CMake and autoconf+make, i.e., those that are already supported by LLVM/Clang and in active use by a significant portion of the LLVM/Clang community.

  • Doug

I think this is premature, although I consider it a worthy goal. Right now, the only motivation we have for removing “configure+make” is that we don’t like having two build systems, but that’s not good enough.

Some things that CMake needs to do well for it to become the only way to build LLVM/Clang:

  • Optionally build and install compiler-rt
  • Optionally build and install libc++
  • Ease-to-use cross-compilation support
  • Documentation to make it easy to understand how to do the above
  • LLDB?
  • LLVM testsuite support

And some value-add that might make CMake motivating for others:

  • Easy bootstrap

  • Build packages/installers

  • Doug

I propose premake [1]. It also has nice performance, flexibility, and ease of use, but does not require Python
and can produce machine-independent Makefiles. It also support generation of native projects for
Visual Studio and Xcode (as compared to CMake which inserts calls to itself everywhere).

[1] http://industriousone.com/premake

Premake is pretty good, I use it in all my personal projects, though
I'm not sure if it would be a good choice for LLVM.

So I read that ccmake is a UI for viewing/modifying cmake project settings. I've tried to do it using an editor but was not very easy (I'm a cmake newbie). Michael said that he builds LLVM/Clang with libc++ without any problems, I'll check with him before trying out ccmake.

Thanks

Is there anybody who is certain that our autoconf dependency needs to stay
around? Are there developers stuck on systems that don't have a recent
enough cmake in their most recent release, or maybe are using some
features from configure+make that the cmake build system doesn't
implement?

If nobody pipes up, I might actually try actually removing it!

I think this is premature, although I consider it a worthy goal.

I agree, I just had no way of knowing how premature. There was no
list, people aren't in the habit of filing bugs for missing features
and I haven't seen any migration-looking commits landing in a while.

Right now,
the only motivation we have for removing "configure+make" is that we don't
like having two build systems, but that's not good enough.

I want to add support for --compress-debug-sections to the assembler.
That means that I'd like to add a new optional dependency (on zlib) to
llvm, and couldn't. The problem is that I can't run AutoRegen.sh even
after searching for the right versions of all the autoconfy bits.
Debian has a "snapshot" server with every version of every package
they've ever had, and even that failed me; I found autoconf 2.59 and
2.61, but no 2.60.

From my point of view, that's a crisis. I'm sure we'll figure

something out, but right now I'm thinking "I can't do my job because
of the build system".

Some things that CMake needs to do well for it to become the only way to
build LLVM/Clang:
  - Optionally build and install compiler-rt
  - Optionally build and install libc++
  - Ease-to-use cross-compilation support
  - Documentation to make it easy to understand how to do the above
  - LLDB?
  - LLVM testsuite support

And some value-add that might make CMake motivating for others:
  - Easy bootstrap
  - Build packages/installers

Thanks for this list!

Nick

Is there anybody who is certain that our autoconf dependency needs to stay around? Are there developers stuck on systems that don’t have a recent enough cmake in their most recent release, or maybe are using some features from configure+make that the cmake build system doesn’t implement?

If nobody pipes up, I might actually try actually removing it!

I think this is premature, although I consider it a worthy goal. Right now, the only motivation we have for removing “configure+make” is that we don’t like having two build systems, but that’s not good enough.

Here here. Thanks for writing up this detailed and accurate response.

Some things that CMake needs to do well for it to become the only way to build LLVM/Clang:

  • Optionally build and install compiler-rt
  • Optionally build and install libc++

FYI, I’m currently in-flight working on the first of these, and planning to work on the second afterward.

  • Ease-to-use cross-compilation support
  • Documentation to make it easy to understand how to do the above
  • LLDB?
  • LLVM testsuite support

I think David might be interested in this. However, the way LNT is structured, I don’t think this is a requisite: it is now much more common to build the testsuite independently of llvm/clang, and hand it a set of pre-built binaries.

And some value-add that might make CMake motivating for others:

  • Easy bootstrap
  • Build packages/installers

A couple more:

  • Support for ninja if you happen to have it (and no cost if you don’t) gives you faster rebuilds.
  • Slightly better support for the new Tooling infrastructure.

I want to add support for --compress-debug-sections to the assembler.
That means that I'd like to add a new optional dependency (on zlib) to
llvm, and couldn't. The problem is that I can't run AutoRegen.sh even
after searching for the right versions of all the autoconfy bits.
Debian has a "snapshot" server with every version of every package
they've ever had, and even that failed me; I found autoconf 2.59 and
2.61, but no 2.60.

What worked for me is downloading all the bits from
http://ftp.gnu.org/gnu/. In my home directory I have:

~/inst/auto-llvm # autohell versions that llvm wants
~/inst/auto-gcc #autohell versions that gcc wants
...

Cheers,
Rafael

Derp? It's listed right here: http://ftp.gnu.org/gnu/autoconf/

--Owen