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