You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/05/18 11:33:00 UTC
[PATCH] First pass at moving util_uri to apr-util...
As discussed before - this is a big patch. This compiles in my tree,
but that doesn't mean I've haven't missed something. I'd guess that
mod_dav might be broken with this - I tried to catch everything, but I
don't compile mod_dav (Greg?) or, for that matter, most of the modules.
The core compiles (don't know if it runs correctly...).
I'd expect this to take a few iterations to get right. Any help testing
this (with all modules) is *GREATLY* appreciated. I'm tired. It's
2:30AM here and by the time I wake up and read email again, it's
possible someone else can eyeball this or even (gasp!) test it out and
confirm that it still builds (or doesn't).
Basic changes in apr_uri.c:
1) Rename from apr_parse_uri_components to apr_uri_parse_components
and others along this vein to make all of the functions of the
form apr_uri_*. I dropped the second uri in the parse components
because it seemed too redundant.
2) uri_components -> apr_uri_components
3) Removed the ap_default_port_for_request function. No one seems to
use it anyway.
4) APU_DECLARE added
Other notes to test this patch:
- You need to delete the util_uri.h file - exports picks up on this.
- I've attached each file that needs to be added to apr-util:
- apr_uri.h in apr-util/include
- apr_uri.c in apr-util/uri
- gen_uri_delims.c in apr-util/uri
- I'd like to remove the apr_uri.h from httpd.h, but that might
increase the complexity of this patch even further. Once this patch
is accepted (in some form), then I can focus on removing apr_uri.h
from httpd.h entirely. I need baby steps (heh) right now.
- I imagine that this might break a bunch of stuff in Win32 or other OS
builds with foreign dependency files. Any help here is appreciated.
This is a start... -- justin
Re: [PATCH] First pass at moving util_uri to apr-util...
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sun, May 20, 2001 at 06:50:32PM -0700, Greg Stein wrote:
> When moving functions from one place to another (or whole files!), we can't
> make any changes during the move. It is practically impossible to see and
> review the changes made in transit.
>
> The more ideal way to do this would be to simply "cvs add" util_uri.c as
> uri/apr_uti.c. *Then* to apply patches to make all the changes that you
> suggest. Similar for util_uri.h -> apr_uri.h.
>
> I believe the first step would be to add those two files to APRUTIL, then
> change apr_uri.h to include a #ifdef NOT_READY_YET so the exports processing
> doesn't "see" the changes.
>
> That would make the files available for applying patches.
>
> We should be able to move the gen_uri_delims over directly.
>
> How does that sound?
Good. Now, if someone with commit access wants to do that, please do
so. =)
I don't have commit access - which is why I kind of need someone with
commit access to make this migration smoother (apr_uri isn't the
only one that needs to be switched over - but it is probably the most
involved). I believe Ryan and Doug volunteered (?) to help out with
this. Maybe tomorrow they will be around and can provide some
assistance on that end. If anyone else thinks this is a worthy cause
(and understands these patches), please feel free to step in!
There isn't too much more that I can do on my end except make the
patches as clean as possible. Hopefully, I've done that. If not,
let me know and I'll work on the patches some more...
Thanks. -- justin
Re: [PATCH] First pass at moving util_uri to apr-util...
Posted by rb...@covalent.net.
On Sun, 20 May 2001, Greg Stein wrote:
> When moving functions from one place to another (or whole files!), we can't
> make any changes during the move. It is practically impossible to see and
> review the changes made in transit.
>
> The more ideal way to do this would be to simply "cvs add" util_uri.c as
> uri/apr_uti.c. *Then* to apply patches to make all the changes that you
> suggest. Similar for util_uri.h -> apr_uri.h.
>
> I believe the first step would be to add those two files to APRUTIL, then
> change apr_uri.h to include a #ifdef NOT_READY_YET so the exports processing
> doesn't "see" the changes.
>
> That would make the files available for applying patches.
>
> We should be able to move the gen_uri_delims over directly.
>
> How does that sound?
++1
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] First pass at moving util_uri to apr-util...
Posted by rb...@covalent.net.
On Sun, 20 May 2001, Greg Stein wrote:
> When moving functions from one place to another (or whole files!), we can't
> make any changes during the move. It is practically impossible to see and
> review the changes made in transit.
>
> The more ideal way to do this would be to simply "cvs add" util_uri.c as
> uri/apr_uti.c. *Then* to apply patches to make all the changes that you
> suggest. Similar for util_uri.h -> apr_uri.h.
>
> I believe the first step would be to add those two files to APRUTIL, then
> change apr_uri.h to include a #ifdef NOT_READY_YET so the exports processing
> doesn't "see" the changes.
>
> That would make the files available for applying patches.
>
> We should be able to move the gen_uri_delims over directly.
>
> How does that sound?
++1
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] First pass at moving util_uri to apr-util...
Posted by Greg Stein <gs...@lyra.org>.
When moving functions from one place to another (or whole files!), we can't
make any changes during the move. It is practically impossible to see and
review the changes made in transit.
The more ideal way to do this would be to simply "cvs add" util_uri.c as
uri/apr_uti.c. *Then* to apply patches to make all the changes that you
suggest. Similar for util_uri.h -> apr_uri.h.
I believe the first step would be to add those two files to APRUTIL, then
change apr_uri.h to include a #ifdef NOT_READY_YET so the exports processing
doesn't "see" the changes.
That would make the files available for applying patches.
We should be able to move the gen_uri_delims over directly.
How does that sound?
Cheers,
-g
On Fri, May 18, 2001 at 02:33:00AM -0700, Justin Erenkrantz wrote:
> As discussed before - this is a big patch. This compiles in my tree,
> but that doesn't mean I've haven't missed something. I'd guess that
> mod_dav might be broken with this - I tried to catch everything, but I
> don't compile mod_dav (Greg?) or, for that matter, most of the modules.
> The core compiles (don't know if it runs correctly...).
>
> I'd expect this to take a few iterations to get right. Any help testing
> this (with all modules) is *GREATLY* appreciated. I'm tired. It's
> 2:30AM here and by the time I wake up and read email again, it's
> possible someone else can eyeball this or even (gasp!) test it out and
> confirm that it still builds (or doesn't).
>
> Basic changes in apr_uri.c:
> 1) Rename from apr_parse_uri_components to apr_uri_parse_components
> and others along this vein to make all of the functions of the
> form apr_uri_*. I dropped the second uri in the parse components
> because it seemed too redundant.
> 2) uri_components -> apr_uri_components
> 3) Removed the ap_default_port_for_request function. No one seems to
> use it anyway.
> 4) APU_DECLARE added
>
> Other notes to test this patch:
> - You need to delete the util_uri.h file - exports picks up on this.
> - I've attached each file that needs to be added to apr-util:
> - apr_uri.h in apr-util/include
> - apr_uri.c in apr-util/uri
> - gen_uri_delims.c in apr-util/uri
> - I'd like to remove the apr_uri.h from httpd.h, but that might
> increase the complexity of this patch even further. Once this patch
> is accepted (in some form), then I can focus on removing apr_uri.h
> from httpd.h entirely. I need baby steps (heh) right now.
> - I imagine that this might break a bunch of stuff in Win32 or other OS
> builds with foreign dependency files. Any help here is appreciated.
>
> This is a start... -- justin
>...
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] First pass at moving util_uri to apr-util...
Posted by Greg Stein <gs...@lyra.org>.
When moving functions from one place to another (or whole files!), we can't
make any changes during the move. It is practically impossible to see and
review the changes made in transit.
The more ideal way to do this would be to simply "cvs add" util_uri.c as
uri/apr_uti.c. *Then* to apply patches to make all the changes that you
suggest. Similar for util_uri.h -> apr_uri.h.
I believe the first step would be to add those two files to APRUTIL, then
change apr_uri.h to include a #ifdef NOT_READY_YET so the exports processing
doesn't "see" the changes.
That would make the files available for applying patches.
We should be able to move the gen_uri_delims over directly.
How does that sound?
Cheers,
-g
On Fri, May 18, 2001 at 02:33:00AM -0700, Justin Erenkrantz wrote:
> As discussed before - this is a big patch. This compiles in my tree,
> but that doesn't mean I've haven't missed something. I'd guess that
> mod_dav might be broken with this - I tried to catch everything, but I
> don't compile mod_dav (Greg?) or, for that matter, most of the modules.
> The core compiles (don't know if it runs correctly...).
>
> I'd expect this to take a few iterations to get right. Any help testing
> this (with all modules) is *GREATLY* appreciated. I'm tired. It's
> 2:30AM here and by the time I wake up and read email again, it's
> possible someone else can eyeball this or even (gasp!) test it out and
> confirm that it still builds (or doesn't).
>
> Basic changes in apr_uri.c:
> 1) Rename from apr_parse_uri_components to apr_uri_parse_components
> and others along this vein to make all of the functions of the
> form apr_uri_*. I dropped the second uri in the parse components
> because it seemed too redundant.
> 2) uri_components -> apr_uri_components
> 3) Removed the ap_default_port_for_request function. No one seems to
> use it anyway.
> 4) APU_DECLARE added
>
> Other notes to test this patch:
> - You need to delete the util_uri.h file - exports picks up on this.
> - I've attached each file that needs to be added to apr-util:
> - apr_uri.h in apr-util/include
> - apr_uri.c in apr-util/uri
> - gen_uri_delims.c in apr-util/uri
> - I'd like to remove the apr_uri.h from httpd.h, but that might
> increase the complexity of this patch even further. Once this patch
> is accepted (in some form), then I can focus on removing apr_uri.h
> from httpd.h entirely. I need baby steps (heh) right now.
> - I imagine that this might break a bunch of stuff in Win32 or other OS
> builds with foreign dependency files. Any help here is appreciated.
>
> This is a start... -- justin
>...
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] First pass at moving util_uri to apr-util...
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
I'm about to work on this. Give me a yell if someone else is already
doing the moves of util_uri to apr-util. The plan is as Greg described.
....Roy
Re: avoiding "find" (was: Re: [PATCH] First pass at moving util_uri to
apr-util...)
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Greg Stein wrote:
>
> On Mon, May 21, 2001 at 06:45:05PM -0700, Roy T. Fielding wrote:
> > On Sun, May 20, 2001 at 06:52:18PM -0700, Greg Stein wrote:
> > > Since gen_uri_delims.lo is not destined for a library (.la), then it
> > > can/should simply use the .o suffix. That will also prevent the object from
> > > appearing within libaprutil.la.
> >
> > I committed it with the .o suffix, but that auto-slurping of object files
> > into the library is bogus. Among other things, it assumes that a developer
> > isn't doing any of their own work within the library.
> >
> > I would like to replace the find with an actual list of library objects.
> > There aren't that many, and it isn't a hardship to require that people add
> > names to Makefile.in when a new component is added to the library.
>
> Sure, whatever. I used the find to avoid having to list every darn file.
> That gets really difficult in APR itself (APRUTIL shouldn't be a problem)
> because the .o file used varies. Is it dso/aix/dso.lo or dso/unix/dso.lo ?
>
> APR used to record which directories were being built, copy all the .o files
> from those directories into an "objs" directory, then archive everything in
> that directory. That isn't much better than a find :-) (and arguably worse
> because of the copy; timestamp issues meant that APR would *always* rebuild
> the library)
>
> One idea might be to simply toss the whole recursive make thang. That would
> put the list of target objects into a single Makefile. APR's ./configure
> script would adjust the set of target objects as necessary. (although that
> gets a bit tricky because then you end up encoding the set of objects
> (destined for Makefile) within configure.in)
What about the idea:
Each Makefile has a list of objects it want to put in the library (TARGETS).
Would it be possible to archive these in an archive file (lib.a) and build our
library using this archive?
An archive file has a timestamp for each file so we could prevent the rebuild of
the library.
>
> Ah well. Go for it for APRUTIL. I think APR will be more difficult because
> of its variability.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
avoiding "find" (was: Re: [PATCH] First pass at moving util_uri to apr-util...)
Posted by Greg Stein <gs...@lyra.org>.
On Mon, May 21, 2001 at 06:45:05PM -0700, Roy T. Fielding wrote:
> On Sun, May 20, 2001 at 06:52:18PM -0700, Greg Stein wrote:
> > Since gen_uri_delims.lo is not destined for a library (.la), then it
> > can/should simply use the .o suffix. That will also prevent the object from
> > appearing within libaprutil.la.
>
> I committed it with the .o suffix, but that auto-slurping of object files
> into the library is bogus. Among other things, it assumes that a developer
> isn't doing any of their own work within the library.
>
> I would like to replace the find with an actual list of library objects.
> There aren't that many, and it isn't a hardship to require that people add
> names to Makefile.in when a new component is added to the library.
Sure, whatever. I used the find to avoid having to list every darn file.
That gets really difficult in APR itself (APRUTIL shouldn't be a problem)
because the .o file used varies. Is it dso/aix/dso.lo or dso/unix/dso.lo ?
APR used to record which directories were being built, copy all the .o files
from those directories into an "objs" directory, then archive everything in
that directory. That isn't much better than a find :-) (and arguably worse
because of the copy; timestamp issues meant that APR would *always* rebuild
the library)
One idea might be to simply toss the whole recursive make thang. That would
put the list of target objects into a single Makefile. APR's ./configure
script would adjust the set of target objects as necessary. (although that
gets a bit tricky because then you end up encoding the set of objects
(destined for Makefile) within configure.in)
Ah well. Go for it for APRUTIL. I think APR will be more difficult because
of its variability.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] First pass at moving util_uri to apr-util...
Posted by rb...@covalent.net.
On Mon, 21 May 2001, Roy T. Fielding wrote:
> On Sun, May 20, 2001 at 06:52:18PM -0700, Greg Stein wrote:
> > Since gen_uri_delims.lo is not destined for a library (.la), then it
> > can/should simply use the .o suffix. That will also prevent the object from
> > appearing within libaprutil.la.
>
> I committed it with the .o suffix, but that auto-slurping of object files
> into the library is bogus. Among other things, it assumes that a developer
> isn't doing any of their own work within the library.
>
> I would like to replace the find with an actual list of library objects.
> There aren't that many, and it isn't a hardship to require that people add
> names to Makefile.in when a new component is added to the library.
Please take a look at how APR used to work before the find was introduced.
I am pretty sure it did exactly what you are looking for.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] First pass at moving util_uri to apr-util...
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Sun, May 20, 2001 at 06:52:18PM -0700, Greg Stein wrote:
> Since gen_uri_delims.lo is not destined for a library (.la), then it
> can/should simply use the .o suffix. That will also prevent the object from
> appearing within libaprutil.la.
I committed it with the .o suffix, but that auto-slurping of object files
into the library is bogus. Among other things, it assumes that a developer
isn't doing any of their own work within the library.
I would like to replace the find with an actual list of library objects.
There aren't that many, and it isn't a hardship to require that people add
names to Makefile.in when a new component is added to the library.
....Roy
Re: [PATCH] First pass at moving util_uri to apr-util...
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
I'm about to work on this. Give me a yell if someone else is already
doing the moves of util_uri to apr-util. The plan is as Greg described.
....Roy
Re: [PATCH] First pass at moving util_uri to apr-util...
Posted by Greg Stein <gs...@lyra.org>.
On Fri, May 18, 2001 at 02:33:00AM -0700, Justin Erenkrantz wrote:
>...
> --- srclib/apr-util/uri/Makefile.in 2001/01/07 01:35:51 1.3
> +++ srclib/apr-util/uri/Makefile.in 2001/05/18 09:18:41
> @@ -1,2 +1,12 @@
> +TARGETS = uri_delims.h apr_uri.lo
> +CLEAN_TARGETS = gen_uri_delims uri_delims.h
> +
> # bring in rules.mk for standard functionality
> @INCLUDE_RULES@
> +
> +gen_uri_delims_OBJECTS = gen_uri_delims.lo
> +gen_uri_delims: $(gen_uri_delims_OBJECTS)
> + $(LINK) $(EXTRA_LDFLAGS) $(gen_uri_delims_OBJECTS) $(EXTRA_LIBS)
> +
> +uri_delims.h: gen_uri_delims
> + ./gen_uri_delims > uri_delims.h
One more comment:
Since gen_uri_delims.lo is not destined for a library (.la), then it
can/should simply use the .o suffix. That will also prevent the object from
appearing within libaprutil.la.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] First pass at moving util_uri to apr-util...
Posted by Greg Stein <gs...@lyra.org>.
On Fri, May 18, 2001 at 02:33:00AM -0700, Justin Erenkrantz wrote:
>...
> --- srclib/apr-util/uri/Makefile.in 2001/01/07 01:35:51 1.3
> +++ srclib/apr-util/uri/Makefile.in 2001/05/18 09:18:41
> @@ -1,2 +1,12 @@
> +TARGETS = uri_delims.h apr_uri.lo
> +CLEAN_TARGETS = gen_uri_delims uri_delims.h
> +
> # bring in rules.mk for standard functionality
> @INCLUDE_RULES@
> +
> +gen_uri_delims_OBJECTS = gen_uri_delims.lo
> +gen_uri_delims: $(gen_uri_delims_OBJECTS)
> + $(LINK) $(EXTRA_LDFLAGS) $(gen_uri_delims_OBJECTS) $(EXTRA_LIBS)
> +
> +uri_delims.h: gen_uri_delims
> + ./gen_uri_delims > uri_delims.h
One more comment:
Since gen_uri_delims.lo is not destined for a library (.la), then it
can/should simply use the .o suffix. That will also prevent the object from
appearing within libaprutil.la.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/