You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by gs...@locus.apache.org on 2000/12/08 13:40:21 UTC
cvs commit: httpd-2.0/build build2.mk
gstein 00/12/08 04:40:21
Modified: build build2.mk
Log:
configure's --with-* type switches are the standard way to specify foreign
directories to a package. APRUTIL works this way, and does not need APR's
location at buildconf.sh time.
Revision Changes Path
1.24 +1 -1 httpd-2.0/build/build2.mk
Index: build2.mk
===================================================================
RCS file: /home/cvs/httpd-2.0/build/build2.mk,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -u -r1.23 -r1.24
--- build2.mk 2000/12/07 11:37:07 1.23
+++ build2.mk 2000/12/08 12:40:20 1.24
@@ -117,7 +117,7 @@
$(aprutil_configure): srclib/apr-util/configure.in
@echo rebuilding $@
- (cd srclib/apr-util && ./buildconf.sh ../apr)
+ (cd srclib/apr-util && ./buildconf.sh)
$(apr_configure): srclib/apr/aclocal.m4 srclib/apr/configure.in srclib/apr/apr_common.m4 srclib/apr/hints.m4
@echo rebuilding $@
Re: exports files (was: Re: cvs commit: httpd-2.0/build build2.mk)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 08, 2000 at 02:27:18PM -0800, rbb@covalent.net wrote:
>...
> > 3) auto step: recreate exports whenever a header changes
>...
> As long as it is that fast, let's just do #3. So waht if we rebuild too
> much. Please add a message stating what we are doing, so that if that
> time grows, we can change it.
Cool. I'll update the thing. It will just print the command line, rather
than the @... stuff in the Makefile (which hides it).
Note that I'll make APRUTIL also do it automatically (which it doesn't right
now).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: exports files (was: Re: cvs commit: httpd-2.0/build build2.mk)
Posted by rb...@covalent.net.
> I can certainly fix APR to move it from buildconf time to a build step.
>
> The auto rebuild is a slight different story. I'm fine with doing it, but
> you had noted that in most cases, a change in the headers does not change
> the exports. IOW, we might rebuild it a bit too often.
>
> Hmm. Here are the three variants that I see right now:
>
> 1) manual step: create exports when buildconf is run. [APR today]
> 2) manual step: create exports during build (a developer can remove
> whatever.exports to force a rebuild) [APRUTIL today]
> 3) auto step: recreate exports whenever a header changes
>
>
> I was going to say that (2) would be my favored approach, but I just timed
> the export creation for APR:
>
> [gstein@kurgan apr]$ time helpers/make_export.pl -o apr.exports include/*.h
> 0.91user 0.16system 0:01.29elapsed 82%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (340major+81minor)pagefaults 0swaps
>
> It is much faster than most compiles :-)
>
> So... what do you think about the three options?
As long as it is that fast, let's just do #3. So waht if we rebuild too
much. Please add a message stating what we are doing, so that if that
time grows, we can change it.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
exports files (was: Re: cvs commit: httpd-2.0/build build2.mk)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 08, 2000 at 09:28:01AM -0500, rbb@apache.org wrote:
> > Log:
> > configure's --with-* type switches are the standard way to specify foreign
> > directories to a package. APRUTIL works this way, and does not need APR's
> > location at buildconf.sh time.
>
> Are you planning to fix the rest of the problems with building the exports
> lists at compile time? Namely that APR is still generating at buildconf
> time, and we don't currently re-generate the .exports file correctly in
> either APR or APR-util, so even after your changes, if I add a function to
> a header file, it won't get picked up now, and I'll still have to do
> something manually.
I can certainly fix APR to move it from buildconf time to a build step.
The auto rebuild is a slight different story. I'm fine with doing it, but
you had noted that in most cases, a change in the headers does not change
the exports. IOW, we might rebuild it a bit too often.
Hmm. Here are the three variants that I see right now:
1) manual step: create exports when buildconf is run. [APR today]
2) manual step: create exports during build (a developer can remove
whatever.exports to force a rebuild) [APRUTIL today]
3) auto step: recreate exports whenever a header changes
I was going to say that (2) would be my favored approach, but I just timed
the export creation for APR:
[gstein@kurgan apr]$ time helpers/make_export.pl -o apr.exports include/*.h
0.91user 0.16system 0:01.29elapsed 82%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (340major+81minor)pagefaults 0swaps
It is much faster than most compiles :-)
So... what do you think about the three options?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/build build2.mk
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 08, 2000 at 09:28:01AM -0500, rbb@apache.org wrote:
>
> > Log:
> > configure's --with-* type switches are the standard way to specify foreign
> > directories to a package. APRUTIL works this way, and does not need APR's
> > location at buildconf.sh time.
>
> Are you planning to fix the rest of the problems with building the exports
> lists at compile time? Namely that APR is still generating at buildconf
> time, and we don't currently re-generate the .exports file correctly in
> either APR or APR-util, so even after your changes, if I add a function to
> a header file, it won't get picked up now, and I'll still have to do
> something manually.
Yes, I plan to do that (and a bunch of other stuff) by tomorrow night
(because I think it is needed/necessary for the alpha build). I dropped a
bunch of stuff into apr-util/STATUS, but I don't think that I added a
apr/STATUS entry for the above.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/build build2.mk
Posted by rb...@apache.org.
> Log:
> configure's --with-* type switches are the standard way to specify foreign
> directories to a package. APRUTIL works this way, and does not need APR's
> location at buildconf.sh time.
Are you planning to fix the rest of the problems with building the exports
lists at compile time? Namely that APR is still generating at buildconf
time, and we don't currently re-generate the .exports file correctly in
either APR or APR-util, so even after your changes, if I add a function to
a header file, it won't get picked up now, and I'll still have to do
something manually.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/build build2.mk
Posted by rb...@apache.org.
> Log:
> configure's --with-* type switches are the standard way to specify foreign
> directories to a package. APRUTIL works this way, and does not need APR's
> location at buildconf.sh time.
Are you planning to fix the rest of the problems with building the exports
lists at compile time? Namely that APR is still generating at buildconf
time, and we don't currently re-generate the .exports file correctly in
either APR or APR-util, so even after your changes, if I add a function to
a header file, it won't get picked up now, and I'll still have to do
something manually.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------