m4: RPM build fails to process `m4_esyscmd` macro

[dmik]

I found that version m4-1.4.16-4.oc00 seems to expand the m4_esyscmd macro to nothing instead of executing its arguments as the shell command and taking its output. This breaks many scripts that use this macro for maintaining the version number (i.e. autoconf, automaker, m4 itself) like this:

AC_INIT([GNU M4], m4_esyscmd([build-aux/git-version-gen .tarball-version]),
  [bug-m4@gnu.org])

This in turn makes autoconf to fail in AC_INIT when generating configure.

[dmik]

it's easy to reproduce the problem in any of the mentioned programs just by running autoconf in the source tree. For example, for autoconf we get:

[12 Jun 2014 14:48:30, sh -c ". configure-env.sh ; autoconf"]

configure.ac:29: error: AC_INIT should be called with package and version arguments
aclocal.m4:172: AM_INIT_AUTOMAKE is expanded from...
configure.ac:29: the top level
autom4te: C:/USR/BIN/m4.exe failed with exit status: 1

It seems that the problem is fixed by just rebuilding the m4 SRPM locally. At least the m4_esyscmd macro starts working. The only problem is that it puts an extra CR after the command output and this breaks the generated configure. I need to look at it.

Another problem is that the generated configure has CRLF line endings (while the original configure usually uses LF). This may create some problems when diffing/patching/merging. But it's a responsibility of SH.EXE I think because configure is taken from the standard output of the shell.

[dmik]

Okay, I got the CR thingy. git-version-gen does echo BLABLA | tr -d $nl to strip out newlines from the echo output. Given that $nl is defined like this

nl='
'

and that the file uses LF, only LF gets stripped. This all is really weird-weird-weird.

[dmik]

This is even more weird given that tr supports \n and \r pseudo-characters so that the should be as simple as echo BLABLA | tr -d \n\r to make sure all kinds of EOLs are stripped down. But this has nothing to do with m4, it's a problem of git-version-gen that needs to be fixed.

[dmik]

The problem mentioned in comment:2 and comment:3 has been solved in r748. This looks like a common problem for all GNU projects using the gnulib toolset for build machinery (including autoconf, automake and m4 itself). So the proper fix for the future is to fix gnulib which provides git-version-gen. This is postponed at least until we switch our repos to preconfigured-less style (i.e. when configure, Makefile.in and other generated files, including git-version-gen are not stored in the repository). It makes no sense to version generated files when you have all the tools needed to generate them. Although we got a lot of the tools recently, we still don't have some (makeinfo and html2man are among them) so we can't do that now.

[dmik]

Until then, a fix similar to r748, needs to each project which is updated through upstream tarballs.

[dmik]

The initial problem seems to have completely gone away after updating the sources to version 1.4.17 in r840. This update also makes it possible to build directly from SVN (after manually doing autoreconf --verbose --install to bring the OS/2 bits into configure). I will also create a new RPM out of 1.4.17.