Re: Expansion of @libexecdir@ in .desktop.in file includes ${exec_prefix}

[Nick Bowler]

On 2021-01-19, Eli Schwartz <eschwartz@archlinux.org> wrote:
> On 1/18/21 11:24 PM, Nick Bowler wrote:
>> This is the only way to make your package follow the GNU coding
>> standards, which says users must be able to override these variables
>> on the make command line.  For example:
>>
>>    % ./configure
>>    % make install prefix=/some/where
>>
>> is supposed to work.  So to make that happen, the rule of thumb is only
>> reference the installation variables in your makefiles.
>
> And here I was under the impression those variables are intentionally
> not expanded during AC_CONFIG_FILES, so that e.g. pkg-config files
> (which do support parsing variables defined earlier in the file) could
> be configured .pc.in -> .pc and have ./configure --prefix='/usr'
> --libdir='${prefix}/lib' actually insert '${prefix}/lib' into the .pc
> file rather than '/usr/lib'.

The gory details for these varables, including rationale for why they
work the way they do and also notes on how to use them correctly, is
all in the Autoconf manual[1].

This includes the note:

  "... you should not use these variables except in makefiles."

and

  "... you should not rely on AC_CONFIG_FILES to replace bindir and
   friends in your shell scripts and other files; instead, let make
   manage their replacement.

along with examples of make rules to do it properly.

> Certainly, it's traditional to create these files via configure, not
> make, but modifying the install prefix during "make install" would
> produce rather incorrect output there, whether you've run "make" or not.
>
> (Yes, GNU projects which presumably must follow the GNU coding
> standards, nevertheless distribute pkg-config files like this.)

GNU packages are not immune to mistakes.

> It's rather doubtful you'd be able to rely on rebuilding built objects
> that embed those options on the compiler command line either, if you run
> make && make prefix=/something/else install.

If you build with one prefix and then install with another, a package
complying with the GNU coding standards will not rebuild anything when
installing.  It would generally take extra work to get such rebuilding
to happen anyway.

[1] 
https://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables

Cheers,
  Nick