Re: [OMPI devel] GNU Automake 1.14 released

[Fabrício Zimmerer Murta]

I think autotools has a concept of disallowing symlinks as it seems symlinks 
can't be done in a portable way, and the goal of autotools is making 
projects portable.

Well, if the autotools user feels like using symlinks, then it must be 
expected to break portability wherever you take your autoconfiscated code 
to. A choice to the user. Maybe in the case, as the project is bound to 
specific compilers, it would not be a problem to loose portability a bit 
more by considering symbolic linking around.

-----Original Message----- 
From: Jeff Squyres (jsquyres)
Sent: Tuesday, September 03, 2013 4:24 pm
To: Open MPI Developers
Cc: Automake List
Subject: Re: [OMPI devel] GNU Automake 1.14 released

How about sym linking the source file?  Then you would only need a single 
Makefile.am; you can use different flags depending on which source file you 
compile.

While somewhat gross, it's not totally disgusting, and it should work to the 
same effect...?


On Aug 30, 2013, at 4:16 AM, Bert Wesarg <address@hidden> wrote:

> Hi,
>
> On Fri, Jun 21, 2013 at 2:01 PM, Stefano Lattarini
> <address@hidden> wrote:
> > We are pleased to announce the GNU Automake 1.14 minor release.
> >
> >
> >  - The next major Automake version (2.0) will unconditionally activate
> >    the 'subdir-objects' option.  In order to smooth out the transition,
> >    we now give a warning (in the category 'unsupported') whenever a
> >    source file is present in a subdirectory but the 'subdir-object' is
> >    not enabled.  For example, the following usage will trigger such a
> >    warning:
> >
> >        bin_PROGRAMS = sub/foo
> >        sub_foo_SOURCES = sub/main.c sub/bar.c
>
> we don't understand how this warning should 'smooth' the transition to
> post-1.14 in our project.
>
> Here is our situation:
>
> We have a source file which needs to be compiled twice. But with
> different compilers. Thus we can't use per-target flags and we use two
> separate Makefile.am files for this. Because the compilation rules are
> nearly identical, we use a Makefile.common.inc.am file which will be
> included by both Makefile.am's. Here is the directory layout (the
> complete reduced testcase is attached):
>
> src/foo.c
> src/Makefile.am
> src/Makefile.common.inc.am
> src/second/Makefile.am
>
> The src/Makefile.am looks like:
>
> ---- 8< src/Makefile.am 8< ---
> SUBDIRS = second
>
> MY_SRCDIR=.
> include Makefile.common.inc.am
>
> bin_PROGRAMS=foo
> foo_SOURCES=$(FOO_COMMONSOURCES)
> ---- >8 src/Makefile.am >8 ---
>
> ---- 8< src/second/Makefile.am 8< ---
> CC=$(top_srcdir)/bin/wrapper
>
> MY_SRCDIR=..
> include ../Makefile.common.inc.am
>
> bin_PROGRAMS=foo-wrapped
> foo_wrapped_SOURCES=$(FOO_COMMONSOURCES)
> ---- >8 src/second/Makefile.am >8 ---
>
> ---- 8< src/Makefile.common.inc.am 8< ---
> FOO_COMMONSOURCES = $(MY_SRCDIR)/foo.c
> ---- >8 src/Makefile.common.inc.am >8 ---
>
> This works with automake 1.13.4 as expected. Now, with automake 1.14
> we get the newly introduced warning mentioned above in the release
> statements. Now enabling subdir-objects is not yet an option for us,
> because we use variables in the _SOURCES list and bug 13928 [1] hits
> us.
>
> So what would be the best transition in this situation? We don't want
> to remove the Makefile.common.inc.am to avoid the resulting redundancy
> in the two Makefile.am files. We also can't use the newly introduced
> %reldir%, because it also throws the warning, and also want to
> maintain compatibly with pre-1.14 automake.
>
> Any guidance is more than welcomed.
>
> Kind Regards,
> Matthias Jurenz & Bert Wesarg
>
> [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928
> <foo-subdir-objects-warnings.tar.gz>_______________________________________________
> devel mailing list
> address@hidden
> http://www.open-mpi.org/mailman/listinfo.cgi/devel


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