|
From: Robert K. <rl...@al...> - 2022-07-07 02:09:25
|
On 7/4/22 19:23, Michael Sweet via Gimp-print-devel wrote:
> FWIW, CUPS has always manually expanded things because autoconf doesn't (and this is actually documented by the current version of the autoconf docos...)
>
> The "explanation" is that they expect software to do the expansion and support variables like this. 🙄
Interesting. That behavior seems...counterintuitive to me.
>> On Jul 4, 2022, at 6:42 PM, Robert Krawitz <rl...@al...> wrote:
>>
>> On 7/1/22 23:30, Matsumura, George wrote:
>>> Greetings,
>>>
>>> My build of Gutenprint, built through Void Linux's standardized build
>>> process, was unable to find the module directories due to PKGMODULEDIR
>>> being defined in config.h as:
>>> #define PKGMODULEDIR "${exec_prefix}/lib64/gutenprint/5.3/modules"
>>>
>>> Since the C processor cannot expand exec_prefix, it remains in the path
>>> at runtime and cannot be resolved.
>>>
>>> Attached is the config.summary from the build. In particular, the
>>> following flag passed to configure seemed to be responsible:
>>> --libdir=\${exec_prefix}/lib64
>>
>> That definitely isn't valid; configure doesn't perform any expansion of its own, but rather takes
>> what was provided on its command line.
>>
>> Why is it using
>>
>> --libdir=\${exec_prefix}/lib64
>>
>> rather than expanding it out?
>>
>>> There seems to be a specific case in configure.ac for when libdir is
>>> defined as \${exec_prefix}/lib, but this would not cover my case.
>>>
>>> This seems to be similar to the problem described here:
>>> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Defining-Directories.html
>>>
>>> Is there a recommended way to patch configure.ac so that such an option
>>> works correctly? The above reference suggests either moving definitions
>>> to compile-time options in Makefile.am, which, looking at the repository
>>> history, seems to have been done in gutenprint in the past, or using an
>>> additional macro to resolve the pathname.
>>>
>>> Thank you for reading this and in advance for any reply.
|