Re: run configure on different machines

[Guido Draheim]

Am 26.07.2013 11:27, schrieb A.P. Horst:
> On 26-7-2013 12:06, Guido Draheim wrote:
> > Am 25.07.2013 14:17, schrieb 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