In the beta test spirit I tried something I don't usually do, to build
gpsbabel under cygwin.
17 7:50 svn co http://gpsbabel.googlecode.com/svn/trunk/gpsbabel
gpsbabel-svn
18 7:52 cd gpsbabel-svn/
19 7:52 ./configure
20 7:54 make
The build fails because autoconf is not installed:
~/work/gpsbabel-svn% make
autoconf
make: autoconf: Command not found
make: *** [configure] Error 127
Checking the Makefile we see the default target all depends on
gpsbabel$(EXEEXT), which in turn depends on configure, which in turn
depends on configure.in.
all: gpsbabel$(EXEEXT)
gpsbabel$(EXEEXT): configure Makefile $(OBJS)
$(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) -lm -lexpat -lsetupapi -lhid
$(OUTPUT_SWITCH)$@
...
configure: configure.in
autoconf
Make has a hard time deciding if it needs to build configure. It ends
up depending on the order the files were pulled during the "svn co"
command. My experience on other projects is that you can not count on
the timestamp order to be consistent. It seems that after a checkout
make sometimes thinks a target is out of date and other times it doesn't.
~/work/gpsbabel-svn% ls -l --full-time configure*
-rwxrwxrwx 1 strabert None 166729 2011-11-19 07:52:27.252371700 -0700 configure*
-rwxrwxrwx 1 strabert None 11597 2011-11-19 07:52:27.630419700 -0700
configure.in*
From the svn book:
use-commit-times
Normally your working copy files have timestamps that reflect the last time
they were touched by any process, whether your own editor or some svn
subcommand. This is generally convenient for people developing software,
because build systems often look at timestamps as a way of deciding which files
need to be recompiled.
In other situations, however, it's sometimes nice for the working copy
files to have timestamps that reflect the last time they were changed in the
repository. The svn export command always places these “last-commit timestamps”
on trees that it produces. By setting this config variable to yes, the svn
checkout, svn update, svn switch, and svn revert commands will also set
last-commit timestamps on files that they touch.
It seems like neither choice is optimal or sufficient. For example, if
I revert or update a source file after a build I need make to know the
corresponding target is out of date. To get make to know it doesn't
need to build configure after a checkout one might try the
use-commit-times option. However, even checkout with this option may
not accomplish what we want if the target and it's dependency are
committed in the same changeset. In this case their times in the
checkedout wc will match exactly irrespective of the timestamps these
files had in the wc that was committed. Furthermore, this is an option
set in the svn config file, not on the command line, so it isn't
convenient to use it for one command and not another.
This seems like a general issue with subversion any time a target and a
dependency of that target are both in the repository.
Does any body know of a good way to resolve this? Clearly I can touch
configure before I make, but I am looking for a more general and
automated solution.
Thanks,
Steve
