Dave,
what if you do
touch ompi/include/mpi.h.in && sleep 1 && touch config/opal_config_pthreads.m4
&& ./autogen.pl && module unload cisco/autotools/ac269-am1133-lt242 &&
./configure --prefix=$PWD/_prefix && make
autogen.pl nor configure does not touch ompi/include/mpi.h.in, and as a
consequence,
config/opal_config_pthreads.m4 is newer than ompi/include/mpi.h when
make is invoked.
then from ompi/include/Makefile:
$(srcdir)/mpi.h.in: $(am__configure_deps)
($(am__cd) $(top_srcdir) && $(AUTOHEADER))
rm -f stamp-h2
touch $@
this means $(AUTOHEADER) is invoked, and then ompi/include/mpi.h.in is
touched.
1) in this scenario, $(AUTOHEADER) is invoked for nothing, but make has
no way to know it ...
2) make will touch ompi/include/mpi.h.in so the next make invokation
will not call $(AUTOHEADER)
makes sense ?
could this be seen as an autotools flaw ?
(e.g. autogen.pl invokes autotools that should have touched
ompi/include/mpi.h.in in order to avoid
the issue discussed here)
and/or could/should this be handled in autogen.pl ?
(e.g. manually touch ompi/include/mpi.h.in and some other files)
Cheers,
Gilles
On 2015/01/06 8:25, Dave Goodell (dgoodell) wrote:
> I just attempted to reproduce this issue and was unable to. I did this on a
> RHEL6 box with master hash ce2008a:
>
> ----✂----
> $ touch config/opal_config_pthreads.m4 && ./autogen.pl && module unload
> cisco/autotools/ac269-am1133-lt242 && ./configure --prefix=$PWD/_prefix &&
> make
> ----✂----
>
> Which did exactly what I expected and only ran configure once, the time that
> I explicitly requested it to be run. I even ran it again to make sure that
> the timestamp on opal_config_ptrheads.m4 was the only source state difference
> between the two runs. So I don't know what is causing your problem, but it's
> not the rule you pointed out in the generated makefile. Perhaps you are
> building on NFS and this is causing you some timestamp headaches?
>
> -Dave
>
> On Dec 22, 2014, at 8:13 PM, Gilles Gouaillardet
> <gilles.gouaillar...@gmail.com> wrote:
>
>> Hi Dave,
>>
>> yes, i did experience this exact behaviour.
>>
>> "by accident" meant i ran autogen.pl with the required autotools versions.
>> then, i ran configure and make with the RHEL6 stock autotools (that are too
>> old for OMPI)
>> configure worked just fine, but make crashed because of outdated autotools
>>
>> if i ran make with the latest autotools, i would probably have not noticed
>> the issue.
>>
>> note the issue occurs only when make is invoked for the first time.
>> if make success, autoheader does touch mpif.h.in, so the next make do not
>> require autotools.
>>
>> if i read between the lines, it seems autoheader is not (correctly) invoked
>> by autogen.pl
>>
>> please let me know if you cannot reproduce this issue.
>> (and once again, this is a very minor annoyance, and since tarballs are
>> generated with make dist, tarballs are very likely unaffected, so bottom
>> line,
>> only developers that update m4 files can be affected)
>>
>>
>> Cheers,
>>
>> Gilles
>>
>> On Tue, Dec 23, 2014 at 2:26 AM, Dave Goodell (dgoodell)
>> <dgood...@cisco.com> wrote:
>> On Dec 22, 2014, at 2:42 AM, Gilles Gouaillardet
>> <gilles.gouaillar...@iferc.org> wrote:
>>
>>> Jeff and all,
>>>
>>> i just found "by accident" that make can require autotools.
>>>
>>> for example:
>>>
>>> from (generated) ompi/include/Makefile :
>>> $(srcdir)/mpi.h.in: $(am__configure_deps)
>>> ($(am__cd) $(top_srcdir) && $(AUTOHEADER))
>>> rm -f stamp-h2
>>> touch $@
>>>
>>> and $(am__configure_deps) is a bunch (all?) of .m4 files.
>>>
>>> from a pragmatic point of view, it means that if update a m4 file, run
>>> autogen.pl and configure,
>>> then, the first invokation of make will run $(AUTOHEADER)
>> Gilles,
>>
>> Have you actually experienced this exact behavior? The sequence you mention
>> above shouldn't cause autoheader to be invoked by make. Running autogen.pl
>> will invoke autoheader after the m4 files were touched, so the mpi.h.in file
>> will be newer than its m4 dependencies, which should mean that this make
>> rule won't be executed.
>>
>> -Dave
>>
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/12/16713.php
>>
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/12/16717.php
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/01/16734.php
