This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: config.h.in wants to be free^Wrebuilt
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: phil at jaj dot com
- Date: Tue, 19 Mar 2002 00:34:17 -0600 (CST)
- Subject: Re: config.h.in wants to be free^Wrebuilt
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
In article <20020318151045.A24224@disaster.basement.lan> you write:
> But in testing, I found that config.h.in gets rebuilt even with our
> current setup, i.e., just run autoheader and you get a different output
If you guys don't mind, I would like to "beat the dead horse" for a
moment. I notice this issue after every commit by some people to the
generated files. I don't think the problem, if any, is people
forgetting to run autoheader.
Most recently, the change Phil just added back in originally came in
my -r1.49 commit (however, close inspection will reveal this thunk to
have randomly appeared and disappeared over the life of the file).
-r1.50 was checked in by Ben and it inverted the thunk again. I know
both Phil and Ben correctly run autoheader. I always uncomment the
rules in the Makefile and then rebuild auto* files in a built tree.
Since Phil gets my answer for config.h.in, I assume my approach is
OK. ;-)
-r1.51 also checked in by Ben flipped nothing (i.e. only the newly
inserted macro was propagated into config.h.in).
The real question is: ``Why is the output not stable?'' I have no
answer to the question other than we all use a sightly different set
of auto* tools and they take some information from the local
$prefix/share not just files under central control...
The other real question is: ``Does it matter?'' I don't know. I find
it to be annoying since it makes it just that much harder to study a
pending patch.
If my theory is correct, then Ben should be able to touch:
configure.in and rebuild config.h.in. He will see a change.
Regards,
Loren