Hi,
On Tuesday 03 September 2013 16:01:30 Ralph Castain wrote:
> I still don't see an issue with just detecting the version of automake being
> used, and setting a conditional that indicates whether or not to use
> explicitly include the subdir. Seems like a pretty trivial solution.
Ralph, sorry,
I still don't see an issue with just detecting the version of automake being
used, and setting a conditional that indicates whether or not to use explicitly
include the subdir. Seems like a pretty trivial solution.
On Sep 3, 2013, at 3:49 PM, "Jeff Squyres (jsquyres)"
wrote:
> On Sep 3, 2013
On 09/04/2013 09:10 AM, Miles Bader wrote:
"Jeff Squyres (jsquyres)" writes:
We've been using sym links in the OMPI project for years in order to
compile a series of .c files in 2 different ways. It's portable to
all the places that we need/want it.
Hmm, how about just "cp" ...? :]
Autoconf
"Jeff Squyres (jsquyres)" writes:
> We've been using sym links in the OMPI project for years in order to
> compile a series of .c files in 2 different ways. It's portable to
> all the places that we need/want it.
Hmm, how about just "cp" ...? :]
-miles
--
80% of success is just showing up. -
er 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,
On Sep 3, 2013, at 6:45 PM, FabrÃcio Zimmerer Murta
wrote:
> 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
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
Hi,
On Fri, Jun 21, 2013 at 2:01 PM, Stefano Lattarini
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 giv
* Stefano Lattarini (stefano.lattar...@gmail.com) wrote:
> [Re-adding the list, sorry for the confusion]
>
> On 08/12/2013 06:16 AM, Eric Dorland wrote:
> > * Stefano Lattarini (stefano.lattar...@gmail.com) wrote:
> >> Hi everybody.
> >
> > (You didn't reply to the list, did you mean that?)
> >
>
[Re-adding the list, sorry for the confusion]
On 08/12/2013 06:16 AM, Eric Dorland wrote:
> * Stefano Lattarini (stefano.lattar...@gmail.com) wrote:
>> Hi everybody.
>
> (You didn't reply to the list, did you mean that?)
>
No, thanks for noticing. I'm re-adding the list.
>> Sorry for the delay,
* Dan Kegel (d...@kegel.com) wrote:
> On Thu, Aug 8, 2013 at 4:43 PM, Eric Dorland wrote:
> >> That sounds kind of risky, promises of compatibility notwithstanding.
> >
> > Can you elaborate why?
>
> No. I'm just being paranoid. But there is good precedent for
> paranoia being the right setting
On Thu, Aug 8, 2013 at 4:43 PM, Eric Dorland wrote:
>> That sounds kind of risky, promises of compatibility notwithstanding.
>
> Can you elaborate why?
No. I'm just being paranoid. But there is good precedent for
paranoia being the right setting in matters of backwards compatibility.
> If the
* Dan Kegel (d...@kegel.com) wrote:
> On Thu, Aug 8, 2013 at 2:39 PM, Eric Dorland wrote:
> > Previously I would upgrade the automake package to the latest version
> > and add a new binary package for the previous version. So, for
> > example, if automake was at version 1.10 and 1.11 was released
On Thu, Aug 8, 2013 at 2:39 PM, Eric Dorland wrote:
> Previously I would upgrade the automake package to the latest version
> and add a new binary package for the previous version. So, for
> example, if automake was at version 1.10 and 1.11 was released
> upstream I would update the automake packa
* Eric Dorland (e...@debian.org) wrote:
> Hi Stefano,
>
> I was just getting around to packaging this for Debian and I have a
> question. Given the new versioning scheme shouldn't the APIVERSION (as
> defined in configure.ac) be 1.13 and not 1.14? Or more precisely, does
> it make sense for the bi
On Fri, Jun 21, 2013 at 8:01 AM, Stefano Lattarini
wrote:
> We are pleased to announce the GNU Automake 1.14 minor release.
>
> This release comes with two important changes:
>
> 1. It introduces a new feature aimed at making the implementation
> of non-recursive build systems more convenie
Hi Stefano,
I was just getting around to packaging this for Debian and I have a
question. Given the new versioning scheme shouldn't the APIVERSION (as
defined in configure.ac) be 1.13 and not 1.14? Or more precisely, does
it make sense for the binary to be renamed given that this release
should ha
We are pleased to announce the GNU Automake 1.14 minor release.
This release comes with two important changes:
1. It introduces a new feature aimed at making the implementation
of non-recursive build systems more convenient and manageable
(thanks to the new support for the '%reldir%'
18 matches
Mail list logo
