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