This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: config.h.in wants to be free^Wrebuilt


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]