run configure on different machines

[A.P. Horst]

Hello,

for several projects we use autoconf for configuration and checking. Now
a colleague of mine checked out one of these projects, tried to
configure it (seemingly succeeded), but the build failed. It turns out
that config.h generated by configure is full of #undef [something].
Nothing is defined, not even PACKAGE. In fact, there is also an #undef
PACKAGE.
How can this be? Isn't configure supposed to work across machines?
The problem got solved by him running autoreconf -i. But I do not think
this is how it is supposed to be.


Arie

[Guido Draheim]

Post by A.P. Horst
Hello,
for several projects we use autoconf for configuration and checking. Now a colleague of mine checked out one of these projects, tried to configure it (seemingly succeeded), but the build failed. It turns out that config.h generated by configure is
full of #undef [something]. Nothing is defined, not even PACKAGE. In fact, there is also an #undef PACKAGE.
How can this be? Isn't configure supposed to work across machines?
The problem got solved by him running autoreconf -i. But I do not think this is how it is supposed to be.

There can be multiple possible reasons for that behviour.
First of all, I am wondering whether you have committed
the config.h file to the version control repository - if
so then delete it and add it to the ignore-files list.

Also state the automake-version as some version have tried
to be very minimalistic about recompiling when unnecessary.
Since some version control systems will have an interesting
handling of file mtime it might turn out that the makefile
rules were setup so that it thought there is no need to
regenerate the config.h - please check the mtimes of the
files that you would expect to get configure-generated.

cheers, Guido

[A.P. Horst]

Post by Guido Draheim

Post by A.P. Horst
Hello,
for several projects we use autoconf for configuration and checking.
Now a colleague of mine checked out one of these projects, tried to
configure it (seemingly succeeded), but the build failed. It turns
out that config.h generated by configure is
full of #undef [something]. Nothing is defined, not even PACKAGE. In
fact, there is also an #undef PACKAGE.
How can this be? Isn't configure supposed to work across machines?
The problem got solved by him running autoreconf -i. But I do not
think this is how it is supposed to be.

There can be multiple possible reasons for that behviour.
First of all, I am wondering whether you have committed
the config.h file to the version control repository - if
so then delete it and add it to the ignore-files list.
Also state the automake-version as some version have tried
to be very minimalistic about recompiling when unnecessary.
Since some version control systems will have an interesting
handling of file mtime it might turn out that the makefile
rules were setup so that it thought there is no need to
regenerate the config.h - please check the mtimes of the
files that you would expect to get configure-generated.

There are no configure generated files in the repos, we have a strict
policy to never configure in the source tree. So config.h is freshly
generated.
The automake version of both my colleague and mine is 1.11.1, and
autoconf version are both 2.68.
Gets weirder by the minute, doesn't it?

Arie

[Guido Draheim]

Post by Guido Draheim

Post by A.P. Horst
Hello,
for several projects we use autoconf for configuration and checking. Now a colleague of mine checked out one of these projects, tried to configure it (seemingly succeeded), but the build failed. It turns out that config.h generated by configure is
full of #undef [something]. Nothing is defined, not even PACKAGE. In fact, there is also an #undef PACKAGE.
How can this be? Isn't configure supposed to work across machines?
The problem got solved by him running autoreconf -i. But I do not think this is how it is supposed to be.

There can be multiple possible reasons for that behviour.
First of all, I am wondering whether you have committed
the config.h file to the version control repository - if
so then delete it and add it to the ignore-files list.
Also state the automake-version as some version have tried
to be very minimalistic about recompiling when unnecessary.
Since some version control systems will have an interesting
handling of file mtime it might turn out that the makefile
rules were setup so that it thought there is no need to
regenerate the config.h - please check the mtimes of the
files that you would expect to get configure-generated.

There are no configure generated files in the repos, we have a strict policy to never configure in the source tree. So config.h is freshly generated.
The automake version of both my colleague and mine is 1.11.1, and autoconf version are both 2.68.
Gets weirder by the minute, doesn't it?

Nah, such things do can happen - with the "#undef PACKAGE" it
seems that the configure-stream (value cache) is borken. As far
as you use "automake" that sounds more like a problem in that
realm. I had problems with different *.in from different automake
versions and then there was the splendid idea to try to do an
implicit autoreconf to avoid it. The generated makefile-rules
have changed over the years and you want to check the automake
versions are about the same on all the machines of your developers.
(see how many rpm-packages will autoreconf any software before
doing an actual configure-run just because of that).

have fun, Guido