[LLVMdev] Deprecating autoconf/make?

[Renato Golin]

On 23 May 2013 00:14, Eric Christopher <echristo at gmail.com> wrote:

> Can anyone see good a reason not to move to cmake as our only build
> configuration system and drop future support for autoconf + makefiles
> now that 3.3 has branched?
>

Hi Eric,

The main issue I can see is that all buildbots currently use autoconf and
changing it is not a simple matter of using CMake. It's embedded in the
python library and might not be trivial to migrate. Also, the release test
relies heavily on it, though this one would be easier to change, I think...

What I think we should be asking ourselves first is: Shouldn't we migrate
all uses of autoconf for CMake? Except for some rants and a few minor bugs
that should be fixed anyway (if not by us, by CMake), I can't see a reason
why not move to one build system.

If that's going to be ready for 3.4, I don't know, and I wouldn't make an
effort to deprecate autoconf on any future release *before* our main
systems stopped depending on it.

I currently use CMake+Ninja on native builds on both x86 and ARM without
problems, but I agree that cross-compilation is not yet mastered. If we fix
these, and move buildbots to CMake, I guess you'll be able to ask that same
question again.

Regarding the test-suite, I don't think we should move *all* LLVM projects
to CMake at the same time. It would be great to have them all using CMake,
and we can (should) strive to do that, but it's not necessary to migrate
all or nothing, all at once. However, once we decided that we'll go with
CMake, for the sake of simplicity, I think we should enforce that every
LLVM (official) project uses CMake as well.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/ffba85b0/attachment.html>