[Pcsclite-muscle] Incorrect use of Autoconf to expand variables in plaintext files

[Kirill Elagin]

Hello,

First, here is a concrete instance of this issue. In pcsclite 1.9.2
`EnvironmentFile=` was added to the `etc/pcscd.service.in` file. If
you look at a machine that has this (or newer) version installed, you
will find in `/etc/systemd/system/pcscd.service` this line:

```
EnvironmentFile=-${prefix}/etc/default/pcscd
```

It results in the following error reported to the system journal:

```
systemd[1]: /etc/systemd/system/pcscd.service:9: EnvironmentFile= path
is not absolute, ignoring: ${prefix}/etc/default/pcscd
```

The root cause is that `AC_CONFIG_FILES` is used, arguably somewhat
incorrectly, to replace all kinds of variables in all kinds of files,
while it is meant to only list makefiles. Quite often, this is not a
problem, since those variables just get replaced by correct values and
that’s it, however some variables do not get expanded fully, for
example, the @sysconfdir@ variable used in `pcscd.service.in` is
replaced with literal `${prefix}/etc` by default as can be seen above.

As [Autoconf documentation](https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/Installation-Directory-Variables.html#Installation-Directory-Variables)
explains, this is done intentionally – literal `${prefix}` is used as
part of the replacement value since @sysconfdir@ is supposed to be
used only in makefiles where it will be processed by Make. The
documentation explicitly calls out this practice:

“A corollary is that you should not use these variables except in makefiles.”

“Similarly, you should not rely on AC_CONFIG_FILES to replace bindir
and friends in your shell scripts and other files.”

Then it goes on to give an example of how a full replacement can be
achieved with the help of Make and sed, however I am not exactly sure
if this is a standard practice or if there is a better solution these
days.

In addition to that, pcsc-lite (ab)uses `AC_CONFIG_FILES` to replace
variables in some other files too, however this does not cause
problems since, as far as I can tell, all of those variables are of
the kind that gets expanded fully – with one notable exception: the
variables used in `src/libpcsclite.pc.in` are also not being expanded
fully, so they remain in the generated file, however, luckily, .pc
files allow references to other variables defined in the same file and
due to a convenient coincidence the names of the variables used by
`./configure` and defined in the `libpcsclite.pc` match. I don’t know,
I mean, this still sounds a little fragile to me and I think it would
be better to switch to some more robust solution.

Cheers,
Kirill