autotools version possibilities

Fri Mar 19 15:56:00 GMT 2004

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/