Re: AM_DEFAULT_SOURCE_EXT

[Ralf Wildenhues]

Hi Akim,

* Akim Demaille wrote on Mon, Nov 17, 2008 at 09:47:31AM CET:
> >>> "RW" == Ralf Wildenhues <address@hidden> writes:
> 
>  > hope I'm not going on your nerves yet .. ;-)

> Well, I'm the one who should plead guilty :(  I apologize to be so not
> responsive.

Don't worry.

>  > The only thing that is missing from portable make is that an inference
>  > rule
>  >   SUFFIXES = -bla .c
>  >   -bla.c:
>  >    generate foo.c from foo-bla
> 
>  > is not Posix-conforming (but in practice supported by several make
>  > implementations).
> 
> I did not know it was not.  Why not?  I thought that SUFFICES suffixes
> to describe all the possible situations.

Well, SUFFIXES suffices for automake.  It turns into .SUFFIXES which
suffices for most make implementations out there.  However, SUSv3
describes:

|      Inference rules are formatted as follows:
|
|  target:
|  <tab>command
|  [<tab>command]...
|  line that does not begin with <tab> or #
|
|      The application shall ensure that the target portion is a valid
| target name (see Target Rules ) of the form .s2 or .s1.s2 (where .s1 and
| .s2 are suffixes that have been given as prerequisites of the .SUFFIXES
| special target and s1 and s2 do not contain any slashes or periods.) If
| there is only one period in the target, it is a single-suffix inference
| rule.  Targets with two periods are double-suffix inference rules.
| Inference rules can have only one target before the colon.

so with anything other than exactly one leading dot in the suffix, we
leave the Posix realm here.

> My point about dropping the dot was really just to make it easier to
> describe a _tool_ connected to an extension, rather that a _rule_.
> But it's really a weak issue, maybe we can find an alternative syntax
> if there is really a need.

I think we can.

Cheers,
Ralf