Re: RE: Compiling

At 18:56 27/03/01 +0200, Peter Eisentraut wrote:
>Mike Cannon-Brookes writes:
>
> > 1) ant files are quickly becoming a standard for compiling almost all open
> > source java projects
>
>The nice thing about standards is that there are so many to choose from.
>At PostgreSQL, we use the GNU-style build system, which is already the
>"standard" for compiling almost all open source projects.
>
>One important aspect of this being a "system" is that it works uniformly.
>That means you can go to any subdirectory and run 'make; make install',
>etc., no matter if Ant, MakeMaker, or broken-Python-build-environment is
>running behind the scenes.

I agree completely.

> > 2) ant files are BUILT for java projects
> > 3) currently we seem to have a build process that is 99% Ant and 1% make
> > (for 4 substitutions). It seems unnecessarily complex to add make when we
> > can remove it completely and not lose any functionality.
> >
> > On a related note, why does the JDBC driver need to track versions with the
> > DB code? This seems pretty silly because it arbitrarily changes version
> > without regard to what's changed in the JDBC driver. Why not split it
> off to
> > have it's own versioning scheme? (This would get rid of any dependency on
> > make as a nice consequence)
>
>For informational purposes, I suppose. We've had this discussion about
>splitting of the JDBC driver before, but the latest trend is to integrate
>everything as much as possible.

For support purposes. 99% of the emails I get people forget to say which
versions of the backend & jdbc driver they are using. It would be a
nightmare to try to keep track of each one if the schemes are different.

Also, it should be easy (but isn't for some reason) that the 7.1 driver is
for the 7.1 backend. If we had say 1.2 driver for 7.1 backend then that
distinction is not as clear.

>Incidentally, I suggested that we default the version number to 0.0 if
>you're using Ant directly, but the end result of that might just be that
>we're going to have a bunch of 0.0 drivers being used out there, thus
>spreading an inconsistent software.

Not a good idea for the same reason as above.

Perhaps using build.xml.in is the way around this. for most of the other
directories you still have to run configure before you can run make...

PeterM