2

First, a little bit of background as to why I'm asking this question: Our product's daily build script (as run under Debian Linux by Jenkins), does roughly this:

  1. Creates and enters a build environment using debootstrap and chroot
  2. Checks out our codebase (including some 3rd party libraries) from SVN
  3. Runs configure and make as necessary to build all of the code
  4. Packages up the results into an install file that can be uploaded to our headless server boxes using our install tool.

This mostly works fine, but every so often (maybe one daily build out of 10), the part of the script that builds one of our third-party libraries will error out with an error like this one:

CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash 
/root/software/3rdparty/libogg/missing autoconf
/root/software/3rdparty/libogg/missing: line 81: autoconf: command not found
WARNING: 'autoconf' is missing on your system.
     You should only need it if you modified 'configure.ac',
     or m4 files included by it.
     The 'autoconf' program is part of the GNU Autoconf package:
     <http://www.gnu.org/software/autoconf/>
     It also requires GNU m4 and Perl in order to run:
     <http://www.gnu.org/software/m4/>
     <http://www.perl.org/>
make: *** [configure] Error 127

As far as I can tell, this happens occasionally because the timestamps of the files in the third-party library are different (e.g. off by a second or two from each other just due to the timing of when they were checked out from the SVN server during that particular build). That causes the configure script to think that it needs to auto-regenerate a file, so then it tries to call 'automake' to do so, and errors out because automake is not installed.

Of course the obvious thing to do here would be to install automake in the build environment, but the build environment is not one that I can easily modify (due to institutional reasons), so I'd like to avoid having to do that if possible. What I'd like to do instead is figure out how to get the configure scripts (which I can modify) to ignore the timestamps and just always do the basic build that they do when the timestamps are equal.

I tried to finesse the problem by manually running 'touch' on some files to force their timestamps to be the same, and that seemed to make the problem occur less often, but it still happens:

./configure --prefix="$PREFIX" --disable-shared --enable-static && \
touch config* aclocal* Makefile* && \
make clean && make install ) || Failure "libogg"

Can anyone familiar with how automake works supply some advice on how I might make the "configure" calls in our daily build work more reliably, without modifying the build environment?

Jeremy Friesner
  • 70,199
  • 15
  • 131
  • 234

1 Answers1

2

You could try forcing SVN to use commit times on checkout on your Jenkins server. These commit times can also be set in SVN if they don't work out for some reason. You could use touch -d or touch -r instead of just touch to avoid race conditions there.

Community
  • 1
  • 1
ldav1s
  • 15,885
  • 2
  • 53
  • 56
  • 1
    Looks like "touch -r" did the trick, thanks! In particular, I replaced the plain touch command (above) with: touch temp_dummy_file.txt ; touch -rtemp_dummy_file.txt config* aclocal* Makefile* – Jeremy Friesner Apr 20 '16 at 04:30