[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: convert a pattern rule to a suffix rule

From: Ralf Wildenhues
Subject: Re: convert a pattern rule to a suffix rule
Date: Thu, 26 Aug 2010 19:35:20 +0200
User-agent: Mutt/1.5.20 (2010-04-22)


please don't top-post on this mailing list, thak you.

* YuGiOhJCJ Mailing-List wrote on Thu, Aug 26, 2010 at 09:43:44AM CEST:
> On Wed, 25 Aug 2010 20:37:04 +0200 Ralf Wildenhues wrote:
> > * YuGiOhJCJ Mailing-List wrote on Wed, Aug 25, 2010 at 11:14:15AM CEST:
> > > But we can use a old fashioned suffix rule which is portable. The
> > > problem is when the prerequisites arn't in the same directory than the
> > > target and when the prerequisites have no suffix.
> > 
> > Then you cannot use suffix rules in a portable way, unfortunately;
> > you can get around the directory fairly portably by setting something
> > like
> >   VPATH = @srcdir@:../src:@srcdir@/../src
> > 
> > in the and then forget about the directory (but you need a
> > new Autoconf for this to work because we recently found an Autoconf bug
> > in this area), but single suffix rules work the other way round; see for
> > example `info Autoconf "Single Suffix Rules"'.
> > 
> > If you don't want to require GNU make, the only fully portable way I
> > know is to spell out the rule for each target.

> You say pattern rules and suffix rules are not portable. Also, the
> only way to be portable is to to spell out the rule for each target.
> So, can you tell me why autoreconf complains only when I use pattern
> rules and not when I use suffix rules?

There is a misunderstanding here.  I did not mean to say that suffix
rules in general are not portable.  Suffix rules in general are
portable.  However, for your specific issue, portable suffix rules do
not suffice for two reasons: 1) the directory prefix, 2) the empty
target suffix.  (1) is fixable by VPATH means, (2) is not fixable
portably.  So, for the *specific situation* which you described,
per-target rules are the only fully portable alternative.

You are right that automake does not complain about the (1) and (2)
types of unportabilities, because, well, there is just no way to spell
out (2) with suffix rules.

Hope that helps.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]