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!
Nick
There are definitely missing features in cmake. I’m actually working on adding one of them: support for compiler-rt. There are likely some others.
That said, I actually agree – I think that cmake, while ugly, can be made to support all of our use cases. There are some use cases that autoconf+make can’t support, so I’d rather we just pick cmake and bang on it until it works the way we want.
Please dont remove it yet. I'm relying on configure's '--enable-libcpp' flag to compile LLVM/clang using clang++ and libc++. I couldnt find an equivalent using cmake. Please see my mails titled "Compiling libc++ from within llvm (3.1)" and "Build llvm/clang with cmake vs configure produces different set of artifacts".
If you have any suggestions, I'm most willing to try it out. I dont know enough about CMake but I tried to go through the cmake build files.
Thanks,
ashok
Hi Nick,
I don't see a reason to keep it, but I would like you to check that all buildbots are moved over to cmake. The Polly buildbots are, but I have doubts about the other buildbots.
Tobi
FWIW, I’m also under the impression that Apple’s internal release process depends on configure+make as well.
clang/llvm are advertised as being independent of Apple. There's a ton of companies using the project, but we should let them speak-up if they *really* need it to stay around.
+1 for removing autoconf dep
Oh come on, I’m trying to help relay information. ;] I’m not saying we’re beholden, I’m saying we do have actual users of this. :: eye roll ::
I posted earlier but seems it didnt catch anybody's attention.
Please dont remove it yet. I'm relying on configure's '--enable-libcpp'
flag to compile LLVM/clang using clang++ and libc++. I couldnt find an
equivalent using cmake. Please see my mails titled "Compiling libc++
from within llvm (3.1)" and "Build llvm/clang with cmake vs configure
produces different set of artifacts".
If you have any suggestions, I'm most willing to try it out. I dont know
enough about CMake but I tried to go through the cmake build files.
Thanks,
ashok
Hi 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!
most of my builders are using configure + make, so will need to be converted.
Fortunately, all the build machines seem to have cmake installed.
Ciao, Duncan.
Hi Nick,
If nobody pipes up, I might actually try actually removing it!
I think cmake system lacks many features of autoconf system. In
addition to already said thing, I think the major missing thing is
cross-compilation support.
You can easy cross-compile llvm/clang via standard
--build/--host/--target flags. If you will show that this will be
possible by cmake - then everything will be fine 
I managed to use:
CC=clang CXX=clang++ CXXFLAGS="-stdlib=libc++ -I <libcxxdir..." cmake...
to cause it to use clang++ with libc++ to build LLVM/clang.
But now I run into bug 10646 (http://llvm.org/bugs/show_bug.cgi?id=10646). Can somebody comment on when the patch will be available on trunk. I can apply the patch to my local copy but would like to avoid local changes.
tia,
ashok
I fixed that bug a while ago. Also I build LLVM and Clang with libc++
daily using CMake and it works just fine.
- Michael Spencer
Can you post your build commands? I'm on Linux (Ubuntu).
tia
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.
On the other hand, +1 for gutting autoconf. I hate it, and it needs to die.
Chip
P.S. – Chandler, please increase the font size in your mail client. It’s very small and hard to read.
Why so complicated?
Use ccmake and don't suffer anymore!
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!
There are definitely missing features in cmake. I’m actually working on adding one of them: support for compiler-rt. There are likely some others.
That said, I actually agree – I think that cmake, while ugly, can be made to support all of our use cases. There are some use cases that autoconf+make can’t support, so I’d rather we just pick cmake and bang on it until it works the way we want.
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.
I’d be interested what about CMake is inadequate. The way CMake is used in llvm seems somewhat suboptimal, but I don’t see how doing the same thing in python would be better …
(not saying that cmake is perfect)
Cheers,
/Manuel
Now there's a construct that I never expected to see anyone utter seriously...
David
It never was about writing a build system in python to replace existing one, it was about unifying the way (libraries) dependencies are expressed in LLVM by cmake and configure/make.
– Jean-Daniel
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, …) …
2012/6/21 Jean-Daniel Dupas <devlists@shadowlab.org>
Anton Korobeynikov <anton@korobeynikov.info> writes:
I think cmake system lacks many features of autoconf system. In
addition to already said thing, I think the major missing thing is
cross-compilation support.
You can easy cross-compile llvm/clang via standard
--build/--host/--target flags. If you will show that this will be
possible by cmake - then everything will be fine
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
About the "many features" that cmake lacks, can you provide a list,
please? (supposing those features actually are useful for LLVM
developers. I know that the configure+make build does things missing on
the cmake build, but the later does things missing on the former too.) I
asked for that list of missing features multiple times on this list, and
nobody ever came with anything.