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

[Eli Schwartz]

On 1/18/21 11:24 PM, Nick Bowler wrote:
> On 2021-01-18, Stefan Koch <stefan.koch10@gmail.com> 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

OpenPGP_signature
Description: OpenPGP digital signature