2) A simple find does work because of the presence of MM in there. A better
organization would be apr/src/ and apr/mm/. That would allow a simple
find for the src objects, and it would clarify that MM is a subpackage
rather than part of the source lump.
MM does not belong in the
One of my latest problems dealing with APR's multiple directories was find
the objects to link. There were two problems with this, one caused by lack
of src/, and one partly:
1) If src/ existed in APR, then finding the objects would be a simple find
call. As it is, I must iterate over all the
I think it is goofy to place a src directory in a source tree -- everything
in the distribution is source. If there are too many subdirectories, then
either abstract them into relevant categories or split them into different
library modules.
It isn't a source tree. There is a lot more
on a
bunch of the items for the release, but we should do something to get a
write-up of the src-vs-not alternatives and get some more input.
I think it is goofy to place a src directory in a source tree -- everything
in the distribution is source. If there are too many subdirectories
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
. 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
How much complexity are we willing to trade off for the minority position?
I consider this an important issue, so I am willing to trade a bit of
complexity for this feature. I don't want to add a lot of complexity, but
a bit.
Plus, as apr-util grows, Apache will not want some of the functions
On Wed, Dec 06, 2000 at 09:19:07PM -0600, William A. Rowe, Jr. wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2000 9:01 PM
Just a footnote... what is in misc/ could just as easily live in a
helpers or
build directory, it's nothing but an
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 07, 2000 2:01 AM
I'm actually contemplating building both the .lib and .dll as two full
compiles.
The benefit, when called for, is that users of the .lib won't have dangling
exported symbols. I refused so far because
On Thu, Dec 07, 2000 at 07:26:05AM -0600, William A. Rowe, Jr. wrote:
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 07, 2000 2:01 AM
I'm actually contemplating building both the .lib and .dll as two full
compiles.
The benefit, when called for, is that users
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 07, 2000 7:38 AM
On Thu, Dec 07, 2000 at 07:26:05AM -0600, William A. Rowe, Jr. wrote:
the only way the MSVC 5.0 .dsp files may depend on one another are
on the same - Win32 Debug tag ... only when you get into 6.0
11 matches
Mail list logo
