avoiding "find" (was: Re: [PATCH] First pass at moving util_uri to apr-util...)

[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: avoiding "find" (was: Re: [PATCH] First pass at moving util_uri to apr-util...)

[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/