Just a general comment on the whole idea: automake regenerating
*everything* in response to a minor change in some part of a project
has convinced me that any kind of automatic build regeneration is a
bad idea. (This is something I've observed with other GNU-style
packages; I don't know if svn even uses automake.)
Those kind of changes don't happen often enough to warrant making it
automatic; a single autogen.sh script that takes care of everything is
sufficient.
Auto-generating the build can have serious consequences if something
triggers the rebuild dependency and where the required auto* tools are
either not present on the machine, or have incompatible versions that
won't work with your project; an otherwise fine tarball suddenly is
broken and unable to build on your production box.
Just my 2 cents,
--Wez
On 5/3/05, Max Bowsher <maxb@ukf.net> wrote:
> Nicolás Lichtmaier wrote:
> >> Automatic recreation of build files.
> >>
> >> * Makefile.in, configure.in:
> >> I've added some rules to provoke the automatic remaking when
> >> the requisite files change. In this way people can just type
> >> 'svn up && make'.
>
> I can *partially* see the point of this, but I'm not fully convinced.
>
> I can see how it might be slightly helpful for these files to be rebuilt
> when "svn up" brings down changes, *but* these files don't change very
> often, and a simple "./autogen.sh" suffices to update everything.
>
> Also, you are *never* going to be able to make it fully automatic, because
> at very least people need to run ./gen-make.py when a new .c file is added.
>
> I'm going to make some specific observations on the patch below, but that
> doesn't mean I would necessarily commit it if those comments were acted
> upon.
>
> >> Index: Makefile.in
> >> ===================================================================
> >> --- Makefile.in (revisión: 14535)
> >> +++ Makefile.in (copia de trabajo)
> >> @@ -575,6 +575,28 @@
> >> $(INSTALL_DATA) $$file $(DESTDIR)$(infodir)/$$inst; \
> >> done
> >>
> >> +$(srcdir)/configure: $(srcdir)/configure.in
> >> + cd $(srcdir) && autoconf
>
> No accounting for changes to build/ac-macros/*.m4
>
> ./autogen.sh allow alternate autoconf programs to be specified through
> envvars.
>
> >> +# autoheader might not change svn_private_config.h.in, so touch a stamp
> >> file. +$(srcdir)/subversion/svn_private_config.h.in: $(srcdir)/stamp-h.in
> >> +$(srcdir)/stamp-h.in: configure.in
> >> + cd $(srcdir) && autoheader
> >> + echo timestamp > $(srcdir)/stamp-h.in
>
> Stamp file should be a sibling to the file it relates to.
>
> >> +subversion/svn_private_config.h: stamp-h
> >> +stamp-h: subversion/svn_private_config.h.in config.status
> >> + ./config.status
> >> +
> >> +Makefile: Makefile.in config.status
> >> + ./config.status
>
> Would it not be better to save time and regenerate only the files that
> actually need it?
> ie. ./config.status specific-file-name
>
> >> +config.status: $(srcdir)/configure $(srcdir)/stamp-h.in
> >> + ./config.status --recheck
> >> +
> >> +build-outputs.mk: build.conf
> >> + ./gen-make.py build.conf
>
> srcdir. And don't specify build.conf on the command line, since that is not
> the typical invocation.
>
> And lastly, is it really safe to rely on timestamps to prevent these rules
> firing in release tarball versions?
>
> Max.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 3 16:29:17 2005