Re: fix: autoreconf fails due to .m4 files added but not installed
On 28 May 2022 12:14, Jim Meyering wrote: > A few days ago I was preparing to release grep and wanted to make sure > it'd work with the latest automake and autoconf, so I built and installed > each from master. That exposed these errors when bootstrapping grep. I > think it was a prerequisite to have run grep's "make maintainer-clean": > > configure.ac:41: warning: _AM_PROG_RM_F is m4_require'd but not\ > m4_defun'd > configure.ac:41: warning: _AM_PROG_XARGS_N is m4_require'd but not\ > m4_defun'd > configure:5058: error: possibly undefined macro: _AM_PROG_RM_F > configure:5059: error: possibly undefined macro: _AM_PROG_XARGS_N > > I've just pushed the attached fix. > Introduced in v1.16.5-46-g38da1d906 and v1.16.5-45-g3099097d7 > so this doesn't need a NEWS update. > > Mike, can you add an automake test that would have caught this? does `make distcheck` not catch this ? would be nice if we could catch with a git checkout directly, but seems difficult to pull off. would it be reasonable to assume that every m4/*.m4 file is supposed to be installed ? that wouldn't be too hard to run tests against, but it would make things a little more tricky for devs working out of the git tree with uncommitted local changes. the problem with running $ACLOCAL is that it's configured to search the local ../m4/ tree for all macros that exist ... is there some m4 invocation we could run that would scan all the installed m4 files ? we can pass down the known list of m4 files to be installed, but how to actually scan/validate them i'm not sure. -mike signature.asc Description: PGP signature
Re: propably automake bug
i think you might be describing this bug report: https://debbugs.gnu.org/60508 -mike signature.asc Description: PGP signature
Re: [question] how to install a directory to pythondir?
On 06 Apr 2023 02:34, Wu Zhenyu wrote: > https://www.gnu.org/software/automake/manual/html_node/Python.html > describe how to package python by automake. I have > > $ tree src/foobar > src/foobar > ├── __init__.py > ├── __main__.py > └── utils >├── a.py >├── b.py >└── c.py > > And my Makefile.am contains > > python_PYTHON = src/foobar i think there might be a philosophical mismatch here. Automake doesn't take arbitrary dirs as inputs, much like it doesn't accept wildcards. it wants every file that it's responsible for to be enumerated. this avoids things like `cp src/foobar/__init__.py src/foobar/todo-backup.py` and then having todo-backup.py automatically get sucked up into release tarballs. what about src/foobar/.test.py ? should we include that too ? what about src/foobar/__init__.py~ ? should we include that too ? the practical result is that the build code gets a bit verbose ... > If I > > python_PYTHON = src/foobar/__init__.py src/foobar/__main__.py > src/foobar/utils/a.py src/foobar/utils/b.py src/foobar/utils/c.py > > I got > > $ ls /tmp/abc/lib/python3.10/site-packages > __init__.py __main__.py a.py b.py c.py > > I expected > > $ ls /tmp/abc/lib/python3.10/site-packages > foobar > $ ls /tmp/abc/lib/python3.10/site-packages/foobar > __init__.py __main__.py utils/ > $ ls /tmp/abc/lib/python3.10/site-packages/foobar/utils > a.py b.py c.py > > So, how to install a directory to pythondir? i would guess something like (untested): python_foobardir = $(pythondir)/foobar python_foobar_PYTHON = src/foobar/__init__.py src/foobar/__main__.py python_foobar_utilsdir = $(python_foobardir)/utils python_foobar_utils_PYTHON = src/foobar/utils/a.py src/foobar/utils/b.py src/foobar/utils/c.py prob want to write a script to automatically generate this boilerplate for your project so you don't have to manually keep it up-to-date ... -mike signature.asc Description: PGP signature
