[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: automake -vs- huge projects (1st patch)
From: |
Thomas Fitzsimmons |
Subject: |
Re: automake -vs- huge projects (1st patch) |
Date: |
Tue, 30 Dec 2003 17:06:54 -0500 |
On Sat, 2003-12-27 at 21:25, Alexandre Duret-Lutz wrote:
> >>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:
>
> [...]
> adl> 1999-11-22 Tom Tromey <address@hidden>
> adl>
> adl> * automake.in (handle_single_transform_list): Generate explicit
> adl> rule for subdir objects. Fixes new addition to subobj.test.
> [...]
> adl> The other side of the coin is that dependency tracking will not
> adl> work anymore, because the dependency stuff for subdir/X.o should
> adl> go into subdir/.deps/X.Po but the default suffix rule will put
> adl> it in ./.deps/subdir/X.Po.
> [...]
> Tom> Hmm, maybe this is the issue from way back.
>
> adl> I'm not sure about this. In the past dependencies were put in
> adl> .deps/subdir/X.Po (i.e. where the suffix rule--at least
> adl> today--would put them). You moved them to subdir/.deps/X.Po on
> adl> 2002-01-20 for PR/224.
>
> I've just noticed that the above change of 1999-11-22 occurs
> just after the merge of user-dep-gen-branch. So perhaps you
> were right to think the issue was related to dependency
> tracking...
>
> Anyway, here is a first patch that disables explicit rules for
> subdir-objects without per-target flags.
>
> Random notes:
> - folding the depfile&tmpdepfile computation into depcomp shorten
> the "screen garbage" resulting from the invocation of depcomp
> by one line. This applies to all non-fastdep compilation,
> not only subdir-objects.
> - computing $depbase on-the-fly in fastdep rules adds one line
> of output, so I've arranged things so that it is only used
> when subdir-objects is set.
> - the test suite passes with GNU Make, and I've run the 14 tests
> that uses subdir-objects with BSD Make (will start a full
> check momently). Apart from this I have not yet tested this
> on a real project. I'm hoping you can test this on libgcj.
> - If you omit the NEWS chunk, the patch should also apply to
> automake-1.8 vanilla.
I tested this patch with libgcj. A test build worked fine, and
Makefile.in is *much* smaller (1.4M as opposed to 10M). The size could
still be reduced further though. I discussed the following with Tom on
IRC:
- all libgcj objects are listed in am__libgcj_la_SOURCES_DIST which is
included in DIST_SOURCES. Adding the no-dist option doesn't prevent the
SOURCES_DIST and DIST_SOURCES variables from being generated, even
though they are not used anywhere. Tom has a patch that may fix this;
I'm going to try it out.
- I've eliminated all non-essential per-target flags, but one libgcj
library still requires them. For this library, .obj, .o and .lo targets
are generated, where .lo targets alone would suffice.
- Tom suggested that DEP_FILES may be redundant. He suggested that
configure read the list of .Plo files from the am__include lines in
Makefile.in.
Anyway, this patch brings us closer to using automake-1.8 for libgcj.
Thanks!
Tom
- Re: automake -vs- huge projects, (continued)
- Re: automake -vs- huge projects, Alexandre Duret-Lutz, 2003/12/16
- Re: automake -vs- huge projects, Tom Tromey, 2003/12/16
- Re: automake -vs- huge projects, Alexandre Duret-Lutz, 2003/12/17
- Re: automake -vs- huge projects, Tom Tromey, 2003/12/30
- mailing list archives (Was: Re: automake -vs- huge projects), Alexandre Duret-Lutz, 2003/12/30
- Re: mailing list archives (Was: Re: automake -vs- huge projects), Thomas Dickey, 2003/12/30
- Re: mailing list archives, Alexandre Duret-Lutz, 2003/12/30
- Message not available
- Re: automake -vs- huge projects (1st patch), Alexandre Duret-Lutz, 2003/12/27
- Re: automake -vs- huge projects (1st patch),
Thomas Fitzsimmons <=
- Re: automake -vs- huge projects (1st patch), Alexandre Duret-Lutz, 2003/12/30
Re: automake -vs- huge projects, Ralf Corsepius, 2003/12/18