[LLVMdev] Deprecating autoconf/make?

[Eric Christopher]

On Fri, May 24, 2013 at 10:28 AM, Bob Wilson <bob.wilson at apple.com> wrote:
>
> On May 22, 2013, at 4:14 PM, Eric Christopher <echristo at gmail.com> wrote:
>
>> Hi All,
>>
>> I fear starting another centi-thread on this but I'll give it a shot.
>>
>> We're currently supporting two build systems which is definitely one
>> more than we (or I) want to support.
>>
>> I don't know of any support in autoconf past the
>> --host/--build/--target case that's not supported in cmake. I'll send
>> out an assertion here that this support isn't necessary and any system
>> that needs it can instead move to:
>>
>> build native clang
>> build next clang with some target that supplies a sysroot and a
>> -target option to the native clang
>>
>> 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?
>
> Apple needs to continue supporting various cross-builds, and while I believe you that it could be done as you suggest, it would take a bit of work to get it right for all the different ways we build clang and llvm.  I haven't seen the maintenance of configure+make to be a significant burden.  Yes, it's kind of gross to have two build systems, and it can be annoying to keep them both working, but I would much rather keep the configure+make system working so that we can invest our efforts in actually making llvm a better compiler.

This is a pretty fair point and a lot of other good points have been
made on the thread, however, let me respond to this one in particular
with a sort of summary of where I'm coming from since, as I understand
it, I may have caused a bit of excitement which is unfortunate because
I sent this rather off the cuff based on a lunch conversation to get
some discussion started:

a) the larger problem is adding new functionality to the compiler, we
can see this in libc++ and compiler-rt in particular in that they use
their own custom makefile system in order to build their libraries.
Not integrating with the project as a whole. There are aspects of the
system that don't work with cmake, and aspects that don't work with
autoconf/make. Pretty ugly.

b) It's definitely twice the work to add anything to the system. This
is pretty frustrating and people familiar with one system or the other
usually end up asking someone familiar with the other system to add
the support they're looking to add.

c) Yes, moving to a single system is definitely a bit of work. I sent
this out mostly as a "hey, let's see what's going on here since I'm
pretty sure few people think that having two build systems is a good
idea and cmake seems to cover the most cases". Part of the reason of
sending this out is an attempt to see what really is necessary to have
the whole thing (compiler, debugger, libraries, etc) build with one
system on as many hosts as possible with as much flexibility as we can
manage.

d) The timing: The timing of this message was due to 3.3 having
branched and the release cycle starting. I fully expect any effort to
move to a single build system across all of llvm to take the majority
of a release cycle with just volunteer time. This I figure gives the
most people the most time in order to deal with any internal fallout
that their various build systems need to handle and to come up with
any more blockers before we could remove any support for alternate
systems (including autoconf/make).

e) Is this possible at all? We've heard a lot on this thread of
various problems, in particular, with cross builds. The cross building
infrastructure in llvm right now is a little hacky, but it works. I
think that Richard and I worked out a couple of ideas on how to get it
going with cmake, but I'm anything but a cmake expert. I do want to
reiterate that this is definitely a requirement before we could move
forward.

f) The point of the thread then... the point of this was to get a
bunch of ideas of blockers to moving to a single build system. Two is
pretty inconvenient (though I know we're not getting much pity from
the Firefox, Safari, or Chrome people) and it's nice and clean if we
can have one.

-eric

g) One last addendum - IMO yes, cmake is horrible. It's just hopefully
 _less_ horrible than the alternatives.