bug-gnulib
[Top][All Lists]
Advanced

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

Re: should an empty "pkgdata_DATA" cause creation of $(pkgdatadir) by "m


From: Stefano Lattarini
Subject: Re: should an empty "pkgdata_DATA" cause creation of $(pkgdatadir) by "make install"?
Date: Thu, 15 Mar 2012 21:03:39 +0100

Hi Eric, sorry for the delay.

On 03/13/2012 04:09 PM, Eric Blake wrote:
> On 03/13/2012 08:55 AM, Robert Boehne wrote:
>>>
>>> So we're in a sort of a tie here: some users think that the current
>>> Automake
>>> behaviour is a feature (and I lean toward that position), other ones
>>> (with
>>> Ralf among them, apparently) believe it's a bug.  Hmmm.  What now?
>>>
>>> Regards,
>>>    Stefano
>>
>> I would agree with the "feature" camp.  Users should be able to create 
>> an empty $(pkgdatadir) - suppose that empty directory is populated by
>> other methods.  They should also be able to not create $(pkgdatadir) as
>> well as a non-empty $(pkgdatadir).
> 
> I like the idea of installing empty directories by default, as a
> feature, but can also see the arguments for omitting a directory.  What
> about a compromise:
> 
> By default, we create the empty directory:
> 
> pkgdata_DATA =
> 
> But with the noinst flag, a directory can be specifically marked for no
> creation unless it later has contents:
> 
> noinst_pkgdata_DATA =
> 
> For the sake of conditional concatenation, we should either allow:
> 
> noinst_pkgdata_DATA =
> if COND
>   pkgdata_DATA += file
> endif
> 
> or else make the documentation explicit that to conditionally install
> contents to a directory, but to omit the directory if no contents are
> present, then you must do:
> 
> noinst_pkgdata_DATA =
> pkgdata_DATA =
> if COND
>   pkgdata_DATA += file
> endif
> 
> Either way, the semantics are that if there are contents in a directory,
> then the directory is created; if the conditions make it so there are no
> contents in a directory, then the directory is created _unless_ the
> noinst_ prefix also appeared with that directory.
> 
Honestly, this seems to me an excessively complex semantic to obtain an
effect that can be easily expressed with trivial install hooks ...  And
Bruno's answer later in thread has swayed my opinion towards the "bug,
not feature" field.  I will follow up in an answer to his message (likely
tomorrow).

Regards,
  Stefano



reply via email to

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