#3140 Fails to build on current Debian GNU/Linux

[Philipp Klaus Krause]

Already for a few months, I have been unable to build sdcc using plain ./configure && make.
As a workaround, I use ./configure --disable-pic14-port --disable-pic16-port && make
When not disabling hte pic ports, I get:

make[5]: Entering directory '/home/philipp/sdcc-trunk/sdcc/device/lib/pic14'
 cd . && /bin/bash /home/philipp/sdcc-trunk/sdcc/device/lib/pic14/missing automake-1.16 --foreign --ignore-deps
configure.ac:22: error: version mismatch.  This is Automake 1.16.2,
configure.ac:22: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:22: comes from Automake 1.16.1.  You should recreate
configure.ac:22: aclocal.m4 with aclocal and run automake again.
WARNING: 'automake-1.16' is probably too old.
         You should only need it if you modified 'Makefile.am' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'automake' program is part of the GNU Automake package:
         <https://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <https://www.gnu.org/software/autoconf>
         <https://www.gnu.org/software/m4/>
         <https://www.perl.org/>
make[5]: *** [Makefile:382: Makefile.in] Error 1
make[5]: Leaving directory '/home/philipp/sdcc-trunk/sdcc/device/lib/pic14'
make[4]: *** [Makefile:611: clean_intermediate-pic14] Error 2
make[4]: Leaving directory '/home/philipp/sdcc-trunk/sdcc/device/lib'
make[3]: *** [Makefile:485: objects-pic14] Error 2
make[3]: Leaving directory '/home/philipp/sdcc-trunk/sdcc/device/lib'
make[2]: *** [Makefile:478: model-pic14] Error 2
make[2]: Leaving directory '/home/philipp/sdcc-trunk/sdcc/device/lib'
make[1]: *** [Makefile:268: all] Error 2
make[1]: Leaving directory '/home/philipp/sdcc-trunk/sdcc/device/lib'
make: *** [Makefile:179: sdcc-device-lib] Error 2

[Benedikt Freisen]

This looks suspiciously similar to a problem that I've been having for years.
(Whenever I try to compile a new checkout, that is.)

I believe that its root cause it that a few files that should be generated by the build environment somehow slipped into the repository.
I'm not quite sure how I got rid of the error messages. Either I deleted the offending files or I manually edited the version number.

[Philipp Klaus Krause]

Fixed in [r11996].

[Benedikt Freisen]

Unfortunately, the underlying problem is still there.
The only difference is that my automake 1.16.3 installation now complains about files generated by automake 1.16.2.
While manually re-running aclocal and automake in the pic14 directory fixes the build once again, the files it changes should probably be removed from the source tree and generated by the build system.

The files are:

sdcc/device/lib/pic14/Makefile.in
sdcc/device/lib/pic14/aclocal.m4
sdcc/device/lib/pic14/configure
sdcc/device/lib/pic14/libc/Makefile.in
sdcc/device/lib/pic14/libm/Makefile.in
sdcc/device/lib/pic14/libsdcc/enhanced-no-xinst/Makefile.in
sdcc/device/lib/pic14/libsdcc/enhanced/Makefile.in
sdcc/device/lib/pic14/libsdcc/regular/Makefile.in

[Sebastian Riedel]

pic14 is what makes it not build, but I get similar warnings for pic16, as well as pic14 and pic16 in non-free/lib/, so if files get removed, it should be removed there too?

[Philipp Klaus Krause]

True. Debian testing now has Automake 1.16.3, so the build fails for me again, too.
Alternatively, automake should not attempt to rebuild any files during normal build. configure should be there in the tarballs, and be used as-is.

[Felix]

The following svn behavior seems relevant. In a fresh copy timestamps are very close, but not equal. Here are some relevant bits.

$ test device/lib/pic14/aclocal.m4 -nt device/lib/pic14/Makefile.in ; echo $?
0 # bad, triggers the rule aclocal.m4- > Makefile.in
$ touch test device/lib/pic14/*
$ test device/lib/pic14/aclocal.m4 -nt device/lib/pic14/Makefile.in ; echo $?
1 # good! (x)

now, the feature is...

$ svn update device
At revision 12114.
$ test device/lib/pic14/aclocal.m4 -nt device/lib/pic14/Makefile.in ; echo $?
1 # still good?
$ rm -rf device
$ svn update device
[..]
At revision 12114.
$ test device/lib/pic14/aclocal.m4 -nt device/lib/pic14/Makefile.in ; echo $?
0 # hah, wrong.

The final "0" is spurious. Actually it is properly random, unlike (x) which is deterministic.

Just in case: svn might operate in alphabetical order, capitals first (or rely on the os..). Then, renaming/changing Makefile to makefile may "fix" this in some situations. Or, similarly, renaming aclocal.am to Aclocal.am, if that is possible.

NB: I am not suggesting not to remove generated files in the long run.
NB2: git does not seem to show this problem. Either it is deterministic (c.f. touch) or it is too fast to notice a race.

[Benedikt Freisen]

As of [r12973] this is documented in the manual, albeit in an "it's not a bug it's a feature" way.
The problem itself is still there.
The PIC libraries could really use new Makefiles. (after 4.2.0)

[Felix]

I looked at renaming aclocal.am to Aclocal.am. I am unsure about the side effects.

Minimal steps to take are

• edit Makefile.am. Add
  ACLOCAL_M4 = $(top_srcdir)/Aclocal.m4
ACLOCAL_AMFLAGS = --output ${ACLOCAL_M4}
• (svn) move aclocal.m4 to Aclocal.m4
• (refresh with aclocal --output Aclocal.m4, automake)

Hence, I suggest to instead rename Makefile.am to makefile.am. This only requires adjustment in configure.ac (AC_CONFIG_FILES), the regeneration of the files, and submitting the changes to svn.

I would like to test this in a non-production environment. But I am not an svn expert, and svn does not make this easy. (And I would rather use my time to work on a transition to git...)

Another direction: svn seems to have "hooks". Maybe a checkout hook can be used to touch the files in the correct order after checkout. An svn expert is needed, and the testing issue remains. Someone will have to maintain the hook.

[Philipp Klaus Krause]

I don't think svn hooks are the solution. The timestamps of files in an obtained source tree might differ for any reason. Be it the svn checkout, unpacking of a tarball, or a cp -r.
IMO, "make all" at the top-level should not try to rebuild Makefile.in from Makefile.am. And whatever target we introduce to rebuild Makefile.in from Makefile.am should do so in a way that works (but this is less of a problem, as this target would typically only be used by SDCC developers).

[Philipp Klaus Krause]

Apparently, such issues don't just affect svn, but also other revision control systems; they are common enough to have made it (with a list of possible solutions, one of which I'll implement) into the automake documentation: https://www.gnu.org/software/automake/manual/html_node/CVS.html

[Philipp Klaus Krause]

This should be fixed in [r14090] by implementing maintainer mode in the pic library build system.