[llvm-commits] CVS: */Makefile.am

On Sun, 2004-10-10, Misha Brukman asked "Why can't we use wildcards
instead of listing all the sources" and then wrote in response to my
reply:

> http://www.gnu.org/software/automake/manual/html_mono/automake.html#wildcards
>
> is your answer.

I think their "answer" is lame; we have already sacrificed portability
because we are using enough of gmake-only functionality because we
cannot depend on the system "make" being anything useful, yet gmake is
portable, and hence, the "standard".

I agree completely.

The thing about "distribute only what you list", well... maybe, but the
way "WE" do distribution is (I believe) checkout, build, test, make
clean, make dist. That way, you *know* that what you're distributing
actually works. But I'm not the distro person, that's John. :slight_smile:

Well, automake changes all that. Right now it takes John 1-2 weeks to do
a "distro". automake can produce a VALIDATED distribution automatically
with only CPU time involved. The "distcheck" target builds a
distribution candidate, produces a tar.gz of it, unpacks it, rebuilds
it, and if everything is okay, the tar.gz is good to go. This will find
ALL KINDS of subtle errors and a big part of getting the distribution
right is setting up the _SOURCES variables to list things correctly.

There's some other points not mentioned in the automake documentation.

(1) It turns out to be incredibly handy to have control over what
actually gets built when you're doing multi-platform stuff. You can
add files to directories that WON'T be compiled by anyone until you
commit changes to the Makefile.am. This allows me to commit stuff on
one platform, check it out on another, and another, and ..., build them
all and only modify the Makefile.am when its working everywhere.

(2) Despite (1) above, we'll probably try to figure out a wildcard
approach for directories that are strictly portable. I.e. we'll keep
the list of files for lib/System and anything else that needs to be
tested on multiple machines but use a wildcard in the places that are
pure/vanilla C++ and a check-in on one platform is pretty much
guaranteed to work everywhere.

(3) Another thing you'll run into is the FINDPATH macro function in the
Makefile.rules.am. This is a hack currently implemented for simplicity
in the tools/*/Makefile.am files. What we eventually want to do is put
all the libraries into one directory and use a -L option to
find them.

(4) We've recently discovered that executable size is about 1/2 with
automake build. This might be due to the use of -O2 option, but since
its mostly debug output in the executables, this is unlikely. There was
probably an error in the existing makefiles that duplicated the debug
info (just guessing).

(5) Automake isn't a panacea, it has its warts like anything else. I
just happen to think that the benefits out weigh the costs. We get
perfect installs, simplified distribution builds (everyone can do it),
automated testing ("make check"), perfect dependency generation, etc. As
for warts, you've already asked the most frequently raised objection
(listing source files). There are a few others, like RANLIB (can't
override it on a per-target basis). To me, these are small price to pay
for the benefits. There aren't many other things that automake doesn't
do exceptionally well.

In any event, this is all a grand experiment. We're doing this to see if
it is (a) possible, (b) worthwhile to convert to automake. We need to
make a list of pros and cons and that can only be done after people have
tried it and used it for a while.

Reid.

Reid Spencer wrote:

On Sun, 2004-10-10, Misha Brukman asked "Why can't we use wildcards
instead of listing all the sources" and then wrote in response to my
reply:

http://www.gnu.org/software/automake/manual/html_mono/automake.html#wildcards

is your answer.

I think their "answer" is lame; we have already sacrificed portability
because we are using enough of gmake-only functionality because we
cannot depend on the system "make" being anything useful, yet gmake is
portable, and hence, the "standard".

I agree completely.

The thing about "distribute only what you list", well... maybe, but the
way "WE" do distribution is (I believe) checkout, build, test, make
clean, make dist. That way, you *know* that what you're distributing
actually works. But I'm not the distro person, that's John. :slight_smile:

Typically, I do the following:

Checkout LLVM with release tag.
Make Distro.
Unpackage distro.
Build Distro.
Test Distro.

Yes, I'm paranoid.
:slight_smile:

Well, automake changes all that. Right now it takes John 1-2 weeks to do
a "distro". automake can produce a VALIDATED distribution automatically
with only CPU time involved. The "distcheck" target builds a
distribution candidate, produces a tar.gz of it, unpacks it, rebuilds
it, and if everything is okay, the tar.gz is good to go. This will find
ALL KINDS of subtle errors and a big part of getting the distribution
right is setting up the _SOURCES variables to list things correctly.

FWIW, I don't believe that the build system for LLVM proper is the problem. I think the problems stem from the following:

o) The llvm-gcc binary distributions take awhile due to the following complications:
  o After building it, I put the build into a cfrontend directory and add copyright files and fixheader scripts.
  o For systems in which I don't want to deal with header file licensing issues (i.e. Solaris and MacOS X), I remove all of the system headers that GCC fixed when I built it.
  o Building llvm-gcc and LLVM is sort of a chicken and egg problem. I have to build LLVM, then llvm-gcc, and then build llvm/runtime and install it into the llvm-gcc binary tree. And if something gets fixed in LLVM, it might change the libraries created by llvm/runtime, so keeping everything in sync is kind of a pain.

o) Problems which don't affect day to day work typically don't get fixed until release time. Despite many people's efforts to fix bugs immediently when they show up in the nightly tester, problems slip through because our day to day priorities don't allow us to fix every problem.

Part of that two weeks is one week worth of hurriedly fixing bugs that we've neglected (because for releases, we want everything that worked in the previous release to work in this current release).

Chris has recommended that we schedule some "cleaning up" time more regularly to relieve this burden.

o) We support 3 platforms in-house (one of which gets neglected), and each new platform that I can build increases the problems caused by the two things above.

I believe the two best things that we can do to shorten releases is the following:

1. Re-arrange the LLVM and LLVM-GCC builds to build in one fell swoop. I checkout out, I type make, and it all builds. This requires moving parts of llvm/runtime into llvm-gcc, or making llvm-gcc an LLVM project, or some other approach.

2. Schedule some time at least a month before the release to start polishing LLVM and fix regressions that haven't already been tackled, per Chris's suggestion.

I don't believe automake will make releases go any faster because it doesn't solve the 2 problems listed above. The LLVM core works pretty well; it's the interaction with llvm-gcc that is problematic.

That said, I'm not against automake. I just want to point out what I think the release bottlenecks are.

-- John T.

John,

The point I was trying to make (and obviously didn't) was that because
automake can make the mechanics of building/testing/packaging a release
so much easier (one command), it is possible for this to be automated
regularly (e.g. nightly test). Consequently, the problems only seen when
building a distribution would be available much sooner than the week
before the release. Distribution problems would be detected like any
other bug and reported from the nightly tester. One other benefit of
its simplification is that developers can also easily type one command
before going to bed and see what they get in the morning. This would
also help us find those tricky distribution bugs faster. Each developer
could generate the same results independently and (hopefully) hasten the
bug fixing process.

FWIW, I agree that the current situation with llvm-gcc is not ideal, but
most of us just build llvm-gcc once and forget about it. The real
solution here is to endow LLVM with its own C/C++ compiler and bootstap,
but that's a longer strategy.

Reid.

FWIW, this would be very valuable in its own right, in addition to making
the release easier to manage. Ideally, I would like to make the LLVM core
not depend or provide any C/C++ FE related stuff at all.

-Chris

I would like this too. My own project is writing a front end for my own
language, and while it'll be a long time before I have to worry about
it, I do wonder how I will eventually package it up with LLVM. Being
able to leave out any C/C++ FE related stuff would certainly simplify
things.

While I agree this would be the best solution, realistically I'm not
sure it will ever happen. Writing a fully ANSI compliant C/C++ FE might
well be harder than the rest of LLVM combined. "Full compliance" is the
operative phrase. Coming up with something that mostly complies is much
easier, but pointless. Look at how many years it has taken the major
C++ compilers to be as compliant as they are, and they're still not
perfect (not even g++).

I agree, but I see the problem slightly differently. C++ *is* a complex
language, and implementing it is certainly not something to be taken
lightly. The bigger problem in my mind is that it's a moving target:
there are continuing revisions (TC1 is one part of it, there are more
revisions for C++0x), and the standard library takes a lot of effort to
implement efficiently.

If someone was interested in doing this, it would probably take a small
team of people a couple of years to get something useful. That said, if
someone seriously wants to do this, let me know. :slight_smile:

-Chris

FWIW, I agree that the current situation with llvm-gcc is not ideal, but
most of us just build llvm-gcc once and forget about it. The real
solution here is to endow LLVM with its own C/C++ compiler and bootstap,
but that's a longer strategy.

Reid.

While I agree this would be the best solution, realistically I'm not
sure it will ever happen. Writing a fully ANSI compliant C/C++ FE might
well be harder than the rest of LLVM combined. "Full compliance" is the
operative phrase. Coming up with something that mostly complies is much
easier, but pointless. Look at how many years it has taken the major
C++ compilers to be as compliant as they are, and they're still not
perfect (not even g++).

I agree, but I see the problem slightly differently. C++ *is* a complex
language, and implementing it is certainly not something to be taken
lightly. The bigger problem in my mind is that it's a moving target:
there are continuing revisions (TC1 is one part of it, there are more
revisions for C++0x), and the standard library takes a lot of effort to
implement efficiently.

I agree for both reasons. Writing and maintaining a new, compliant C++ front-end is neither practical nor worthwhile, as long as our current one can continue to be used.

If someone was interested in doing this, it would probably take a small
team of people a couple of years to get something useful. That said, if
someone seriously wants to do this, let me know. :slight_smile:

Or consider taking on alternative, much higher priority, tasks such as writing front-ends for CIL or Fortran (90, 95 or 2000)!

FYI to all, Alkis is actively working on a JVM front-end.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/