Trimming the Fat, Part Deux ...

Okay ... since this is pretty much going to be 'one camp for, one camp
against' without anything to really back up either camps perspectives /
arguments, I did some research on CVS in order to find a nice, effective
middle ground ... and it actually works quite sweet ...

Basically, CVS let's you "merge" modules into one mega-module, which is
what I've just done ...

I pulled out two sub-directories from the pgsql CVS repository ...
contrib/earthdistance and src/interfaces/libpqxx ... if you do:

cvs checkout -P libpqxx

you'll see *just* the libpqxx code ... same with doing a checkout of
'earthdistance' ...

If you checkout pgsql, it will get the source tree *minus* libpqxx and
earthdistance ...

And, finally, if you want it all:

cvs checkout -P pgsql-all

Now, for those that are going to yell out about already checked out code
... don't, I've already tested that too ...

From within your checked out code, remove the above two directories, then
from the top level (ie. if you have your src in src/pgsql, go to the src
directory, *not* the root of the source tree itself) and type:

cvs checkout -P contrib interfaces

and you will be 'in sync' ...

Next thing I'm going to do is modify the scripts that build the .tar.gz
packages so that they now build a libpqxx.tar.gz and earthdistance.tar.gz
distribution, so that they can be downloaded seperately, as well as
pulling out the README files so that ppl know what they are useful for in
the first place ...

For those that like to work on the 'mega source tree', nothing has changed
... you check out pgsql-all, and commits will commit to the right places
in the repository ...

If ppl want to download everything, including the kitchen sink, then they
will have that option ... but if ppl want to just download what they need,
that option is now open to them as well ...

Now comes the 'tricky part, which I'm hoping someone like Peter might know
how to do ... I know there is a way of writing configure to 'run
configure' in sub projects .. for instance, with libpqxx ... at the top
level of pgsql, one could type:

./configure --enable-libpqxx

and it would run the appropriate configure in the libpqxx subdirectory and
add libpqxx to the 'targets' in src/interfaces/Makefile ...

If we can get *that* done, removing something like libpq++ would be a
simple matter of removing the option from configure.in at the top level,
and removing its inclusion in the pgsql-all meta on the CVS repository ...

nice and clean ...

I've only done libpqxx and earthdistance right now ... none of the history
is lost, but I want to get the packaging issue worked out using those two
first, before I dive into the others ... also, want to make sure that I
haven't overlooked anything in my testing ...

*Eventually*, a simple checkout of 'pgsql' should result in a "server
only" distribution that we can pull bits and pieces into transparently ...

the really cool thing is that using PHP, I could probably come up with a
nice simple interface that ppl could create a custom download bundle:

"I want the base server + jdbc + the earth distance module"

and it would package that up and present it to them to download ... then
everyone can package whatever they want and download it ...