On Wed, Dec 06, 2000 at 04:05:12PM -0800, [EMAIL PROTECTED] wrote: > > 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.
How much complexity are we willing to trade off for the minority position? I'd rather not see additional logic (and the resulting complexity) added for the few percent that do not want to wait for a few extra directories to build. Doing a partial build opens us up to problems with shared libraries. "Was the shared library I'm linking against built with everything I need?" wouldn't even be asked if the lib simplied contained all the features, all the time. Varying feature sets for a *library* is actually a bit dangerous. Can I bring up the variable APIs for Unicode FS thing again? :-) >... > > 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 > it. I wouldn't call it major, but I did it a problem :-) I'll have it fixed up... don't worry about it. > > > > 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. I agree that "misc" is poor, but that was merely an example of the problem. Solving "misc" isn't a complete solution. What about the next directory? Will it be properly named? Does "xml" hold some XML-based data, or is it source code? Let's say we move tables out of APR, is "tables" a directory of source, or is it some database tables? Keep the top-level at five dirs is a lot nicer than an explosion of them :-) I never realized that APR had 15 source directories until I went and counted them today. I consider that a bit extreme. I'd worry that APRUTIL will grow that way, too, and would be unhappy to see the clutter. > > 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. The lack of src/ may be been the right start, but as more subdirs have been added, it is getting a bit confusing. I totally agree with your decision to put the platform dirs under the feature dirs, but somebody looking at that top-level would be better served with a src/ directory (IMO). > > 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. :-) There is more to it than directory layout. And whatever I check in can always be changed. I can certainly wait for a bit, but there have been other Q&A that I'd like to capture while it is still in my head. Cheers, -g -- Greg Stein, http://www.lyra.org/
