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

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

 



On 1/18/21 11:24 PM, Nick Bowler wrote:
On 2021-01-18, Stefan Koch <stefan.koch10@xxxxxxxxx> wrote:
The line:
Exec=@libexecdir@/usbauth-notifier/usbauth-notifier

from
https://github.com/kochstefan/usbauth-all/blob/master/usbauth-notifier/data/usbauth-notifier.desktop.in

will expanded to:
Exec=${exec_prefix}/libexec/usbauth-notifier/usbauth-notifier

But desktop-Files doesn't allow variables.

Do you have an idea how to get the line expanded to:
Exec=/usr/libexec/usbauth-notifier/usbauth-notifier

without the ${exec_prefix} variable?

The normal way to do this is to perform the necessary substitutions in
make rules, as in make rules you can use make variables which will be
expanded correctly.

Alternately you could generate the entire file from a make rule which
might be reasonable for a small file like this.

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'.

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.)

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.

...

I'd still, like you, recommend creating desktop files during make, not configure, because they're not supposed to do variable interpretation at runtime.

There's a handy snippet for an "edit" command in Makefile.am, described here:
https://www.gnu.org/software/autoconf/manual/autoconf-2.70/html_node/Installation-Directory-Variables.html

--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux