Re: Using @bindir@ etc. in C headers

[Nick Bowler]

On 05/06/2020, Florian Weimer <fweimer@redhat.com> wrote:
> * Michael Orlitzky:
>
>> On 6/5/20 6:57 AM, Florian Weimer wrote:
>>> I would like to define macros containing the standard paths, like this:
>>>
>>> #define BINDIR "@bindir@"
>>>
>>> It does not work due to this code in lib/autoconf/general.m4 (which
>>> appears to be predate DESTDIR support):
>>>
>>> ...
>>>
>>> Is there are generally approved way to work around this?  The manual
>>> tells us to use -D preprocessor arguments, but I'd prefer the
>>> explicitness of defining the macros via a header file.
>>
>> The autoconf manual's "Installation Directory Variables" section says
>> the following...
>>
>>   Similarly, you should not rely on AC_CONFIG_FILES to replace datadir
>>   and friends in your shell scripts and other files; instead, let make
>>   manage their replacement. For instance Autoconf ships templates of its
>>   shell scripts ending with `.in', and uses a makefile snippet similar
>>   to the following to build scripts like autoheader and autom4te:
>>
>>      edit = sed \
>>              -e 's|@datadir[@]|$(pkgdatadir)|g' \
>>              -e 's|@prefix[@]|$(prefix)|g'
>>
>>      autoheader autom4te: Makefile
>>              rm -f $@ $@.tmp
>>              $(edit) '$(srcdir)/$@.in' >$@.tmp
>>              chmod +x $@.tmp
>>              chmod a-w $@.tmp
>>              mv $@.tmp $@
>>
>>      autoheader: $(srcdir)/autoheader.in
>>      autom4te: $(srcdir)/autom4te.in
>>
>> Not very aesthetically pleasing, but it gets the job done.
>
> It would like to get config.status expansion going, among other things.
> It's nice to consolidate these things in a single place, and avoid
> scattering such constructs and several places.
>
> What do you think about this?

Autoconf is to be used as part of build systems that comply with the GNU
coding standards and these standards say that the user can set prefix etc.
on either the make command line or the configure command line.

In other words, the following should produce a working installation
(assuming a clean build):

  ./configure
  make prefix=/some/where install

Substituting installation directories into C source files at configure
time is probably not going to work in this case.  This is why the manual
recommends using make rules to do it.

Cheers,
  Nick