CODEWITHSUNDEEP
configureautoconf
KJ7LNW
KJ7LNW

Reputation: 1921

Can you modify ACLOCAL_PATH from configure.ac?

A user of xnec2c was trying to build on OSX and had autoconf issues because PKG_CHECK_MODULES could not be found since MacPorts puts it in a funny spot.

The user made autoconf work like so:

ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh 
ACLOCAL_PATH=/opt/local/share/aclocal ./configure

I would like to make it build on OSX without special user path hacks for ACLOCAL_PATH. Can that be done?

I started writing a possible fix below and realized it could an xyproblem so posed the question just above. However, if this starts any gears turning, then I would be open to a bit of special-casing for OSX:

For example, would it be possible (if not advisable) to detect:

  1. Is PKG_CHECK_MODULES missing?
  2. If so:

Upvotes: 0

Views: 478

Answers (1)

ndim
ndim

Reputation: 37837

While aclocal has a few ways of appending to its search path (see https://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html), you cannot modify that macro search path using code in configure.ac:

When the shell code in configure is run, it is too late, as the available macros have already been expanded. When autoconf (is it autoconf or something else? anyway, m4 called from autoreconf) generates configure from configure.ac by having m4 expand the macros it is also too late: aclocal has already collected the m4 macros it could find.

So what you would need is a step before the autoreconf run - which is beyond what I would consider a buildsystem needs to do.

What you can do: Put static strings into the top level Makefile.am file like e.g.

ACLOCAL_AMFLAGS = -I auto-m4 -I project-m4 -I /opt/local/share/aclocal

(this example uses auto-m4/ with AC_CONFIG_MACRO_DIR([auto-m4]) for the *.m4 files automatically put there by autoreconf/autopoint/libtoolize and project-m4/ for the project specific *.m4 files).

Of course, you should already have

m4_pattern_forbid([PKG_CHECK_MODULES])dnl

before invoking PKG_CHECK_MODULES for the first time so that the problem of the missing *.m4 file will be detected at the earliest possible time, i.e. when autoconf is about to generate a configure file with PKG_CHECK_MODULES unexpanded.

You could use some m4 code to print a lengthy error message if PKG_CHECK_MODULES is not defined. Something along the lines of (untested)

m4_ifndef([PKG_CHECK_MODULES], [dnl
m4_fatal([Could not find the PKG_CHECK_MODULES macro. Check that the pkg.m4 file is available and aclocal finds it (e.g. set ACLOCAL_PATH=/opt/local/share/aclocal).
])dnl
PKG_CHECK_MODULES([FOO], [foo])

Personally, I would go with m4_pattern_forbid and make sure OSX builds with homebrew work OOTB, and then document idiosyncrasies for building on rare and buggy systems like OSX with macports or SunOS without GNU tools in the INSTALL file.

Isn't it a bug in macports/OSX that aclocal there cannot find its *.m4 files? Shouldn't there be a dirlist file pointing to /opt/local/share/aclocal? Or perhaps they macports users should have an aclocal in their PATH which actually finds the macports macro files?

In any case, I would not consider it my build systems's job to fix a buggy system. You need to draw the line somewhere.

Upvotes: 1

Related Questions