Re: adding a command line option for ACLOCAL_PATH-type search paths
On 19/01/2022, Mike Frysinger wrote: > the ACLOCAL_PATH functionality is useful (adding search dirs after -I), > but a bit unwieldy as an env var. any reason we can't add a command line > option for this ? call it --aclocal-path ? or --extra-system-acdir ? > or some other other boring name ? > > for context, when cross-compiling, autotools (i.e. automake) tend to be > installed in the system (i.e. /usr/), while all the libraries & macros > being built against are found in a separate sysroot (e.g. ~/sysroot/). > we want to insert that ~/sysroot/usr/share/aclocal path after the set > of -I flags from the package, but before /usr/share/aclocal. > -mike FWIW another option besides the env var is to create a third directory, and put a file called "dirlist" in it with two lines: /path/to/sysroot/usr/share/aclocal /usr/share/aclocal Then you can use the --system-acdir=/path/to/that/directory option for aclocal to have it search both places. Cheers, Nick
Re: adding a command line option for ACLOCAL_PATH-type search paths
On 19 Jan 2022 16:05, Karl Berry wrote: > Hi Mike, > > the ACLOCAL_PATH functionality is useful (adding search dirs after -I), > but a bit unwieldy as an env var. any reason we can't add a command line > option for this ? > > Seems like a fine idea to me. > > call it --aclocal-path ? or --extra-system-acdir ? > > Reading the doc, my hunch is to call it --aclocal-path and make the > semantics of its argument be exactly the same as $ACLOCAL_PATH. Wdyt? i was leaning towards it behaving like -I -- it takes a single path, not a colon-delimited list of paths. not sure if that's what you meant by "be exactly the same as $ACLOCAL_PATH". otherwise, yeah, it'd be the same. > But if both are set, should the --aclocal-path argument replace > $ACLOCAL_PATH, or augment it (earlier of course)? I'm not sure. i don't have an opinion. if we have another scenario that does this, i'd be fine to use that so we're consistent. Peter's point about autoconf & $WARNING handling seems like a good enough reason to do it that way. > By the way, would it be feasible to have --help show the actual values > for --automake-acdir and --system-acdir? It is far from obvious. sounds like a good idea. i'll poke a little. -mike signature.asc Description: PGP signature
Re: adding a command line option for ACLOCAL_PATH-type search paths
Hi Karl, On 20/1/22 09:05, Karl Berry wrote: But if both are set, should the --aclocal-path argument replace $ACLOCAL_PATH, or augment it (earlier of course)? I'm not sure. FWIW, in autoconf the commandline -W takes precedence over environment variable WARNINGS https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#autoconf-Invocation Cheers, Peter
Re: adding a command line option for ACLOCAL_PATH-type search paths
Hi Mike, the ACLOCAL_PATH functionality is useful (adding search dirs after -I), but a bit unwieldy as an env var. any reason we can't add a command line option for this ? Seems like a fine idea to me. call it --aclocal-path ? or --extra-system-acdir ? Reading the doc, my hunch is to call it --aclocal-path and make the semantics of its argument be exactly the same as $ACLOCAL_PATH. Wdyt? But if both are set, should the --aclocal-path argument replace $ACLOCAL_PATH, or augment it (earlier of course)? I'm not sure. By the way, would it be feasible to have --help show the actual values for --automake-acdir and --system-acdir? It is far from obvious. --thanks, karl.
