You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nicolás Lichtmaier <ni...@panoptico.reloco.com.ar> on 2005/05/01 16:12:58 UTC
[PATCH] Automatic rebuilding of build files
I have been using this for a long time. Perhaps you could consider
commiting this into Subversion itself...
Re: [PATCH] Automatic rebuilding of build files
Posted by Nicolás Lichtmaier <ni...@panoptico.reloco.com.ar>.
>>I have been using this for a long time. Perhaps you could consider
>>commiting this into Subversion itself...
>>
>>
>
>In the past, we've decided against having rules like this. Automatic
>reconfiguration can be annoying when it's unwanted (for instance, the
>environment may be different than it was during initial configuration,
>such that you get different results).
>
>That was back in 2001 or so. We have different developers now, so
>perhaps the current consensus would be different, but I'm personally
>still opposed to having such rules.
>
>
If your environment is so different (e.g. you removed APR headers) then
you'll have problems anyway. If you are talking about a simple
environment variable change, then that variable should just be marked in
configure.in with AC_ARG_VAR. This explicitly documents that the
variable affects Subversion (in configure's hel) and it will make
configure to store its value in config.status.
Why don't you try yourself my patch for a while? =)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Automatic rebuilding of build files
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Sunday, May 1, 2005 2:01 PM -0400 Greg Hudson <gh...@MIT.EDU> wrote:
> That was back in 2001 or so. We have different developers now, so
> perhaps the current consensus would be different, but I'm personally
> still opposed to having such rules.
Hah! I'm still against automatic regeneration of build files. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Automatic rebuilding of build files
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2005-05-01 at 12:12, Nicolás Lichtmaier wrote:
> I have been using this for a long time. Perhaps you could consider
> commiting this into Subversion itself...
In the past, we've decided against having rules like this. Automatic
reconfiguration can be annoying when it's unwanted (for instance, the
environment may be different than it was during initial configuration,
such that you get different results).
That was back in 2001 or so. We have different developers now, so
perhaps the current consensus would be different, but I'm personally
still opposed to having such rules.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Automatic rebuilding of build files
Posted by Nicolás Lichtmaier <ni...@panoptico.reloco.com.ar>.
>>>I share much of the above opinion, but am not against auto rebuilds
>>>provided we make sure they can only occur in working copies, never in
>>>tarballs, *and* they do not rebuild too much too often.
>>>
>>>
>>Your first concern can be addressed by using this rules only when
>>--enable-debug is used.
>>
>>
>You mean --enable-maintainer-mdoe?
>
>
Ops, yes. That what I meant.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Automatic rebuilding of build files
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Tue, 3 May 2005, Nicolás Lichtmaier wrote:
>
> >> 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.
> >
> >
> > I share much of the above opinion, but am not against auto rebuilds
> > provided we make sure they can only occur in working copies, never in
> > tarballs, *and* they do not rebuild too much too often.
>
>
> Your first concern can be addressed by using this rules only when
> --enable-debug is used.
You mean --enable-maintainer-mdoe?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Automatic rebuilding of build files
Posted by Nicolás Lichtmaier <ni...@panoptico.reloco.com.ar>.
>> 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.
>
>
> I share much of the above opinion, but am not against auto rebuilds
> provided we make sure they can only occur in working copies, never in
> tarballs, *and* they do not rebuild too much too often.
Your first concern can be addressed by using this rules only when
--enable-debug is used.
The second concern... well.. try this patch in your personal WC for a
while and see if it's helpful or not =).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Automatic rebuilding of build files
Posted by Max Bowsher <ma...@ukf.net>.
Wez Furlong wrote:
> 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.)
No, just autoconf and libtool.
> 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.
I share much of the above opinion, but am not against auto rebuilds provided
we make sure they can only occur in working copies, never in tarballs, *and*
they do not rebuild too much too often.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Automatic rebuilding of build files
Posted by Wez Furlong <ki...@gmail.com>.
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 <ma...@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
Re: [PATCH] Automatic rebuilding of build files
Posted by Max Bowsher <ma...@ukf.net>.
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