autoconf
[Top][All Lists]
Advanced

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

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


From: Stefan Koch
Subject: Re: Expansion of @libexecdir@ in .desktop.in file includes ${exec_prefix}
Date: Wed, 20 Jan 2021 01:32:07 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

Thank you Nick, Eli and Florian

I have solved the issue based on your suggestons in a simplified way.

1. Created a template .desktop file
2. Inserted the libexecdir from the Makefile

https://github.com/kochstefan/usbauth-all/commit/062630bde0e27a5a6dce49819fc7c8ce64ff5964

Best regards

Stefan

Am 19.01.21 um 06:49 schrieb 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





reply via email to

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