bug#19370: Acknowledgement (LT 2.4.4 regression (vs. 2.4.2))

[Jeff Squyres (jsquyres)]

On Jan 5, 2015, at 5:10 PM, Gary V. Vaughan <address@hidden> wrote:

> A bummer indeed.  I suppose this may very well be fixed in autoconf master... 
> though I'm too lazy to check :-)

:-)

Is this something that needs to be reported to the Autoconf devs, or is this 
already a known issue?

If it's not already a known issue, I'm guessing that Open MPI may not be the 
only project to run into this bug once other projects start upgrading to LT 
2.4.4 (although, admittedly, there may not be many that embed libltdl).

>> Just to be clear: you're saying that I should invoke libtoolize *before* 
>> [snip]
> 
> Pretty much, although without the LIBTOOLIZE=true setting before calling 
> autoreconf, it will run wastefully run libtoolize a second time, which may or 
> may not throw the timestamps out of sync again, depending how careful I was 
> about preserving filestamps in generated files from the libtoolize code when 
> their content does not change.  I'd recommend keeping that setting, just in 
> case.

Ahhh... I see.  I thought that the mailer had munged your previous mail and 
there were some quotes missing from your original suggestion.  Now I grok what 
you are suggesting: setting LIBTOOLIZE to effectively be a no-op so that 
autoreconf won't *actually* invoke libtoolize again.  Got it.

> The crux of the matter is that if you run `aclocal -I m4` and then put more 
> files that configure.ac calls out to into m4, then the next run of `aclocal 
> -I m4` necessarily generates a new and different aclocal.m4 (with m4_includes 
> for the new files replacing verbatim copies of the /usr/share/aclocal 
> contents).

Ok, I think I see.

> Another option you have, should you worry about maintaining your own 
> autogen.sh script to keep track of changes in upstream autotools dependencies 
> and invocation ordering, is to use my bootstrap script (as used by libtool 
> itself and m4 among others, and maintained separately at 
> http://github.com/gvvaughan/bootstrap).  This nicely future-proofs you 
> against upstream changes, or addition of internationalization or gnulib to 
> your projects.

That's a good suggestion; many thanks.

I'm a little hesitant to do it, however, simply because I'd prefer to get the 
Autotools fixed correctly such that autoreconf works properly.  That's 
(supposedly) the officially-recommended Way Of Doing Things, and it should 
work.  Perhaps that's naive, but I'd like to stick with the Office Way as much 
as possible.  As such, a 2-line workaround is much more attractive than a 
complicated non-office bootstrap script that we will potentially need to 
continually refresh from your github.

Make sense?

So I think the crux of this particular issue comes down to: do we need to 
report this to the Autoconf devs?

-- 
Jeff Squyres
address@hidden
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/