svn and autoconf

[tsteven4 <ts...@gmail.com>]

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

Re: [Gpsbabel-code] svn and autoconf

[Robert Lipe <ro...@gpsbabel.org>]

On Sat, Nov 19, 2011 at 9:32 AM, tsteven4 <ts...@gmail.com> wrote:

The build fails because autoconf is not installed:
>
[ ... ]

This seems like a general issue with subversion any time a target and a
> dependency of that target are both in the repository.
>

This isn't new to SVN.  We had this problem with CVS, too.  As your
research shows, it's not a solved problem.   The practical choices a


> 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.
>

If you're going to live in the SVN tree, it's less painful to just install
autoconf and let it do its thing.  (And byte your lip an annoyance when you
generate a patch and see that you have a slightly different autoconf than I
do and that it'll generate a zillion lines of spew in the patches if you
don't revert it...)

I did just tweak Makefile.in to ensure that configure is always newer in
the tarball so that more casual developers are less likely to be forced to
endure that.  We were already doing that for another of our checked-in,
generated files.

As I mentioned in a related post early today, I don't have deep love of
autoconf.  The only thing I've found worse so far is everything else. :-/

RJL

Re: svn and autoconf

[Daniel Shahaf <d....@daniel.shahaf.name>]

Andreas Krey wrote on Sat, Nov 19, 2011 at 17:27:16 +0100:
> When producing a release .tar file that shall not use autoconf,
> run autoconf, remove the autoconf rule from the makefile, and
> tar the result (with or without configure.in).

Example: tools/dist/release.py in Subversion's trunk.

Re: svn and autoconf

[Andreas Krey <a....@gmx.de>]

On Sat, 19 Nov 2011 08:32:47 +0000, tsteven4 wrote:
...
> >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.

Correct.

...
> This seems like a general issue with subversion any time a target and a 
> dependency of that target are both in the repository.

This is not subversion-specific (except that a similar quirk lurks
in the subversion sources). Putting a target under version control
is the exact opposite of 'source code control'; there will always be
issues with make (or other) dependencies, independent of what time
stamps a checkout produces..

> 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.

Don't put 'configure' under version control. Expect people who use
a checkout to have 'autoconf' installed (yuck).

When producing a release .tar file that shall not use autoconf,
run autoconf, remove the autoconf rule from the makefile, and
tar the result (with or without configure.in).

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: svn and autoconf

[Johan Corveleyn <jc...@gmail.com>]

On Sat, Nov 19, 2011 at 4:32 PM, tsteven4 <ts...@gmail.com> wrote:

[...]

> 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.

I think that '--config-option config:miscellany:use-commit-times=yes'
ought to do it (for svn 1.6+).

But apart from that, I can't help with your more general question.

-- 
Johan