On Tue, Jan 29, 2002 at 10:22:11AM -0800, Greg Stein wrote:
> No. We should go back to APR's PrintPath, which is what we had before. Kevin
> ripped it out and put in the call to 'which'. And then that broke and we
> "fixed" it once or twice to today's form. And then it broke again.
I've been thinking a little about that recently. First a little context since
most of this happened on IRC. I was working on making it possible to use an
installed version of APR and Neon. My plan was to make a local copy of the
files we needed from APR to get our build system to work. Greg didn't like
that idea because he thought it would introduce version skew between the APR
version and our local copy. His idea was to have developer's (read those
running autogen.sh) require apr and neon in their tree, and have autogen.sh
copy those required files at its execution time. This would fix the version
skew problem. (This is also the reason the INSTALL doc says that autogen.sh
has the requirements, it used to, but we removed them when we went to allowing
At the time, I didn't like that approach, since my primary reason for wanting
separate installs was that I didn't like having to wait for neon and apr's
configure to run when testing configuration changes.
As part of another configure.in change though, I discovered the
--disable-subdir-config option to our configure, which allows us to have
in-tree versions of apr and neon, but not configure them. So now I'm +0.5 on
moving to Greg's original suggestion of requiring those running autogen.sh to
have neon and apr in the tree and copying required files at autogen.sh time.
(.5 because the system works as is, and I haven't noticed any version skew,
but it would still probably be the cleaner approach).
Wow, that took longer than expected.
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
Received on Sat Oct 21 14:37:01 2006
- application/pgp-signature attachment: stored