Trouble with aclocal paths during build

Core Development Core Plans
1

While working on creating a plan for netdata, I kept running into this error early in its build process:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /hab/pkgs/core/autoconf/2.69/20170513214252/bin/autoconf --force
configure.ac:188: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:200: error: possibly undefined macro: AC_CHECK_LIB
configure.ac:312: error: possibly undefined macro: AC_CHECK_HEADER
autoreconf: /hab/pkgs/core/autoconf/2.69/20170513214252/bin/autoconf failed with exit status: 1

I found a few hacks in core-plans that dealt with aclocal and finding stuff:

  • varnish
    • Copies .../share/aclocal/pkg.m4 into "$(pkg_path_for core/automake)/share/aclocal/"
    • Worked, but violates package immutability
  • systemd
    • Exports ACLOCAL_FLAGS="-I .../share/aclocal"
    • Didn’t help me
  • snappy
    • Sets ACLOCAL_PATH=".../share/aclocal" when running autoreconf
    • Works and seems clean!

It seems like setting ACLOCAL_PATH while running autogen.sh was all that was needed:

ACLOCAL_PATH="$(pkg_path_for core/pkg-config)/share/aclocal" ./autogen.sh

Is there a better way to fixing all these? Can packages with share/aclocal just export ACLOCAL_PATH themselves now with that new feature for exporting build-time env variables? At the least, I think the TODO in varnish’s plan can be cleaned up with this.

Here’s my ultimate (working) pull request for netdata: https://github.com/habitat-sh/core-plans/pull/1549

2

@christophermaier did you do some work to allow packages to export environment variables that would get picked up by other dependent programs?

3

Should every package that provides a share/aclocal append it to ACLOCAL_PATH in build environments?

It looks like maybe something like this in each package could do it:

do_setup_environment() {
  push_buildtime_env ACLOCAL_PATH "${pkg_prefix}/share/aclocal"
}

I haven’t messed with push_buildtime_env yet though and am not sure about its lifecycle/implications. Or might this be better handled automatically as part of the built-in build environment generation?

4

I think in the short-term the comment above should address the issue. Longer term we could consider adding ACLOCAL_PATH similar to pkg-config