Re: autotools version possibilities

[Ranjit Mathew <rmathew at hotmail dot com>]

Alexandre Oliva wrote:
>>Has any one else noticed that even the top-level
>>Makefile.in has bloated considerably in 3.4/3.5
>>v/s 3.3?
> 
> 
>>That automake thingy is acting real funky I say!
> 
> 
> Yes, indeed.  Isn't it amazing that automake could cause growth to a
> file that isn't even generated using automake? :-) :-)
> 
> Top-level Makefile.in is produced by AutoGen, a completely separate
> beast.

~blush~

My ignorance of auto* really shows through, doesn't it?

:-(

Given that Benjamin had said:
benjamin> At this point, libstc++ would like to standardize on the
benjamin> current release versions of these tools.
benjamin> automake == 1.8.2
[...]

To which Tom had responded:
> libjava is in a weird situation again.  The released versions of
> automake generate a Makefile.in that is much too large to be seriously
> considered.  We've got a fix for this, but I think it won't show up
> until 1.9
[...]

I assumed that automake was the "culprit". It was
reinforced by this "NEWS"-item from the automake
CVS:
----------------------------- 8< -----------------------------
* Makefile.in bloat reduction.

  - Inference rules are used to compile sources in subdirectories when
    the `subdir-objects' option is used and no per-target flags are
    used.  This should reduce the size of some projects a lot, because
    Automake used to output an explicit rule for each such object in
    the past.

  - Automake no longer outputs three rules (.o, .obj, .lo) for each
    object that must be built with explicit rules.  It just outputs
    the rules required to build the kind of object considered: either
    the two .o and .obj rules for usual objects, or the .lo rule for
    libtool objects.
----------------------------- 8< -----------------------------

Sorry!

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT hotmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/