Another minor annoyance with the libstc++-v3 Makefile(s)

Loren James Rittle rittle@latour.rsch.comm.mot.com
Fri Jun 8 14:25:00 GMT 2001


Mark Mitchell just wrote:

> I think we GNU folks have gotten to auto-happy. :-)

> There's no point of regenerating limits.h all the time -- it's the [...]

[This reminded me that I got a bounce when I first sent this e-mail
 the other night due to adding -v3 to mailing list name.  The issues
 mentioned in here may have been fixed in the last few days, but I
 doubt it...]

In off-list, private e-mail, I wrote:

> [...] I don't understand why files are not updated like they are
> suppose to be in libstdc++-v3.

I just learned something about my problem that I will report to the
broader list.  I hope that someone can use this report to fix this
and/or tell me how I am doing something wrong.

(Here is one example of what I think is wrong behavior.)

If you remove these generated files from $srcdir/libstdc++-v3:

	config.h.in aclocal.m4 configure src/Makefile.in

Then, in a working tree that has maintainer mode enabled (and/or the
Makefile hand-edited to make it appear so), run gmake and you will see:

configure.in: 57: required file `./config.h.in' not found

In my mind, this means with some certainty that at least one
dependency is listed wrong or missing...  and it hints to me why I
could make changes to acconfig.h, yet not see them always appear as
they should in regenerated files when I ran gmake in the working tree
with maintainer mode enabled (however, with the amount of output blown
out, one was almost sure something good had to have happened ;-/).  I
believe this since it appears a built file is used before some rule
would trigger it being rebuilt (thus it appears to me that it might
take multiple passes to propagate a change through all the
configuration files and this matches my experience before I started
being much more aggressive at deleting all expected regeneration
targets).

Then there is the wasted work done:

Try this in $srcdir/libstdc++-v3:

	rm config.h.in aclocal.m4 configure src/Makefile.in

Then, run this in $objdir (as an example, you could pick almost any action):

	gmake | grep os_defines

Guess how many times we link os_defines.h?  6.

OK, that wasn't a fair test you say.  No one should be blowing away
the generated files.  How about just:

	touch $srcdir/acinclude.m4; gmake | grep os_defines

Guess how many times we link os_defines.h in this case?  5.

Something is amiss in the current libstdc++-v3 Makefile...

Regards,
Loren



More information about the Libstdc++ mailing list