autoconf
[Top][All Lists]
Advanced

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

Re: Using @bindir@ etc. in C headers


From: Nick Bowler
Subject: Re: Using @bindir@ etc. in C headers
Date: Fri, 5 Jun 2020 12:18:08 -0400

On 05/06/2020, Florian Weimer <fweimer@redhat.com> wrote:
> * Nick Bowler:
>
>>> It would like to get config.status expansion going, among other things.
>>> It's nice to consolidate these things in a single place, and avoid
>>> scattering such constructs and several places.
>>>
>>> What do you think about this?
>>
>> Autoconf is to be used as part of build systems that comply with the GNU
>> coding standards and these standards say that the user can set prefix
>> etc.
>> on either the make command line or the configure command line.
>>
>> In other words, the following should produce a working installation
>> (assuming a clean build):
>>
>>   ./configure
>>   make prefix=/some/where install
>>
>> Substituting installation directories into C source files at configure
>> time is probably not going to work in this case.  This is why the manual
>> recommends using make rules to do it.
>
> For the install target, the prefix= setting should not trigger
> recompilation and thus does not affect what gets baked into binaries.
> Instead, it should only affect installed paths.  The config.status
> approach makes it more likely that this happens.

Hence why I stated the assumption of a clean build where the "install"
target will also build the package, since I didn't want to worry about
this detail in a simple example.

> I can't find a reference that you should be able to specify prefix= on
> the make command line for a non-install target.

GCS 7.2.5 "Variables for Installation Directories"[1]

  Installers are expected to override these values when calling
  make (e.g., make prefix=/usr install) or configure (e.g., configure
  --prefix=/usr).

[1] https://www.gnu.org/prep/standards/standards.html#Directory-Variables

Cheers,
  Nick



reply via email to

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