diff options
author | Geoffrey M Oxberry <goxberry@gmail.com> | 2019-08-08 15:11:11 -0700 |
---|---|---|
committer | Peter Scheibel <scheibel1@llnl.gov> | 2019-08-27 18:03:56 -0700 |
commit | 56fd9bc7b68e7ad224d1b0006bcbe8a3705be082 (patch) | |
tree | 1741cafe3c118feb89295ac597c005a35cfd083b /.coveragerc | |
parent | 953f2a3f5da250928b31f35105df8954d668d179 (diff) | |
download | spack-56fd9bc7b68e7ad224d1b0006bcbe8a3705be082.tar.gz spack-56fd9bc7b68e7ad224d1b0006bcbe8a3705be082.tar.bz2 spack-56fd9bc7b68e7ad224d1b0006bcbe8a3705be082.tar.xz spack-56fd9bc7b68e7ad224d1b0006bcbe8a3705be082.zip |
AutotoolsPackage: remove redundant libtoolize call
This commit removes redundant calls to `libtoolize` and `aclocal`.
Some configurations, such as a Spack user using macOS with a
Homebrew-installed `libtool` added to their `packages.yaml`, have
`autoreconf` and GNU libtoolize installed as `glibtoolize`, but not
`libtoolize`. While Spack installations of `libtool` built from source
would install `glibtoolize` and symlink `libtoolize` to `glibtoolize`,
an external installation of GNU libtoolize as `glibtoolize` will not
have such a symlink, and thus the call `m.libtoolize()` will throw an
error because `libtoolize` does not exist at the path referenced by
`m.libtoolize()` (i.e.,
`self.spec['libtool'].prefix.bin.join('libtoolize')).
However, on these same systems, `autoreconf` runs correctly, and calls
`glibtoolize` instead of `libtoolize`, when appropriate. Thus,
removing the call to `libtoolize` should resolve the error mentioned
above.
The redundant call to `aclocal` is also removed in this commit because
the maintainers of GNU Automake state that "`aclocal` is expected to
disappear" and suggest that downstream users never call `aclocal`
directly -- rather, they suggest calling `autoreconf` instead.
Diffstat (limited to '.coveragerc')
0 files changed, 0 insertions, 0 deletions