apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: src/ directory (was: Re: apr-util comments)x
Date Thu, 07 Dec 2000 00:05:12 GMT

> 1) Even if you build the whole thing, only the pieces used will be pulled
>    into the application linking against APRUTIL. It is exactly this behavior
>    that we're trying to avoid with the whole "exports.c" hack (we're trying
>    to force a reference to everything in APR to ensure that it all gets
>    linked).
>    Therefore, I'm not sure of the utility of complicating apr-util with a
>    mechanism to build just a subset.

Because of the time to build on some platforms.  Having used computers
that can take over three hours to build Apache, being able to build only
those sections that we require is a HUGE advantage.  :-)  I realize most
computers don't have those issues these days, but some do and I have one
at home that is old and slow, but it does the job so I don't want to
upgrade it.

> 2) Let's say that people here vote/agree to provide a mechanism to build a
>    subset. Then everything is still quite simple: build a subset, and the
>    find only finds the .lo files that were built. Nothing needs to change on
>    the find. We only change the SUBDIRS line in src/Makefile.in

Ahhhh, I see how you do that now.  Personally, I like the way that APR
does this, where we just traverse those subdirs that built and copy the
.o's into a common location to link.  But, I can see advantages to both

>    I'm not entirely happy with that, however, because we might then miss
>    those other subdirectories on "make" targets such as "clean". Last night,
>    I axed the "test" target from SUBDIRS in httpd-2.0, but this morning
>    realized that was wrong: now we don't clean out the test directory. I'm
>    going to put that back and adjust the default targets in the test
>    directory. I think a similar problem might exist in APRUTIL because
>    "test" isn't in the top-level SUBDIRS line.

This is a major problem.  We can't build in a directory if we can't clean

> > > 2) to keep the top-level cleaner. we have eight groups of functionality in
> > >    apr-util/src/. tossing those up a level would make that a bit more
> > >    confusing. Currently, the top-level has: build/, docs/, include/, src/,
> > >    and test/. Each is obvious in purpose.
> > 
> > Isn't this clean enough just because each of the directories has a very
> > specific purpose?
> Unfortunately, no. OtherBill just added a "misc" directory. If that were at
> the top level, nothing about it would indicate that it contains source code
> for the library. I worry similarly about the others. They are certainly
> clearer (e.g. it would be hard to imagine "buckets" as being part of the
> documentation :-), but it is *very* obvious that src/ contains the source
> for the library.

Well, I have a general problem with a misc directory.  And I added the
misc directory to APR, and I regret it now.  If we can't quantify what is
in a directory, then we shouldn't have that directory IMHO.  If we remove
the misc directory, and it is obvious what is in each directory, then we
might be okay removing the src directory.

> APR is quite similar, though, so I would agree that making them similar
> would be a Good Thing(tm). I believe the src/ structure is a bit clearer and
> would apply to APR, too.

I kind of like not having the src directory in apr.  It makes it very fast
to see what is there, and APR has the extra platform directories
already.  I actually invested a bit of time in coming up with the APR
directory structure, and would be a bit hesitant to see it change now.

> All good questions! And it helps by prodding me to explain the thought
> process, as I was the one to initial propose/outline the structure in my
> email last week.
> I'll include this information in a "project structure" document today. That
> will cover info for developers: config/build, layout, etc.

Would you mind waiting to pull together that document until this
discussion is finished?  I figure this is going to gell, and we should get
everything out before we try to document everything.  :-)


Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message