> > 1) we locate all the objects to add to the library using "find". it is > > easier to find them under "src/" rather than enumerating each source > > subdir. We can't use "." because that would pick up "test/". > > > > 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. > > Compelling, but can we agree to agree between apr and apr-util? > > I'm +.5 for applying this same structure to apr (by the benefits > you cite above.) > > I'm -1 for leaving things as they are, and would live with apr-util following > the structure of apr (and that is a veto, my head was spinning the other day). > > Anyone else care to vote for the src/package/ or simply package/ structure?
+1 package -0.5 src/package I disagree with the first argument above, because in reality we are going to want a structure similar to APR, where each package can be enabled and disabled on the configure line. Once we add that, (to both apr and apr-utils) the find has to go away regardless. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
