[LLVMdev] UPDATE: Automake Difficulties (Long)

[Reid Spencer]

I'm re-thinking my penchant for automake. automake is great for many
standard applications that just need to get portable makefiles up and
running quickly.  However, it turns out that LLVM is "different enough"
from a standard application that automake might not be the best choice. 

Here's some of the problems I've run into:

1. There's no way to tell automake to build bytecode. Without a lot of
customization of automake itself, it just can't grok the fact that there
might be multiple ways to compile a c/c++ program producing different
results and requiring different tools. 

2. The entire llvm-test project would have to either be completely
rethought or stay the way it is, it just can't be easily automake'd
because it doesn't follow the automake pattern.

3. The llvm/test directory would require significant rework to get it to
automake correctly (via dejagnu). 

4. There's no way to avoid listing all the sources for every library
(I've tried several alternatives with no good results).

5. There's no way to install bytecode libraries somewhere separately
from other libraries.

6. Creating a distribution tarball would require additional Makefile.am
files to be inserted in all the directories under llvm/include, the
traversal of which would cause additional overhead for every non-dist
target. That's 17 gratuitous "make" processes per build.  There doesn't
seem to be a way around this.

7. I can't get automake to stop doing a double configure. That is, when
you configure all the Makefiles are updated. You then go do a build and
it thinks it needs to reconfigure again so it does it twice. This is
just a waste of time (40 seconds on my machine). 

8. automake's notion of buiding a library is very fixed. It basically
supports two things: libtool built shared libraries (linking) and ar
built libraries that are also run through ranlib.  While its possible to
override AR and LINK, there isn't a way to override RANLIB on a
per-target basis so you can't build both a regular library (requiring
RANLIB=ranlib) and a bytecode library (requiring something like
RANLIB=true) in the same directory. We have in LLVM at least 4 ways to
build libraries: regular .a, pre-linked .o (combination of .o files),
shared-library, and bytecode-library. While I figured out a hack to do
pre-linked .o, it basically uses GNU Make, not automake to make it work
and therefore breaks automake's "make" portability. 

9. There's probably a bunch of things I haven't run into yet.

SOOOOOOO ....

Instead of spending a bunch more time on trying to get automake to work,
I suggest we just fix the current makefile system to do what automake
can do. Specifically we need to:

1. Get dependency generation in a single pass like automake. This will
give us about a 30% speed up on builds .. and one of the main reasons
for moving to automake is taken away.  Estimate: 1-2 hours.

2. Get targets for building distributions and checking them. For this we
can look at what automake generates and just mimic it. Estimate: 1 day.

3. Get targets for install and uninstall working correctly and make
proper use of the install command (instead of relying on libtool) so
that installation goes faster. Estimate: 1 day.

4. Get "make check" to work by allowing any directory to have a set of
programs to be run that "check" that directory. These could be shell
scripts or whatever. Estimate: 1-2 days.

5. Integrate dejagnu/expect/other into "make check" so that our make
system can run tests that parse program output to categorize the result 
as PASS/FAIL/XFAIL/XPASS. This would eliminate our dependence on qmtest
and make all input/output for the tests be plain text that is easily
editable (instead of in a database).  Estimate: 1-2 weeks.


I am, of course, soliciting feedback on this whole idea.

Reid.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041020/c554190e/attachment.sig>