IMHO, it is of primary importance that the code builds easily on all
platforms. I think most of the people who will be compiling Interbase will
be wanting to use it, rather than wanting to develop it.

I would hope that maybe 20% of the people who download Interbase want to
code, but I suspect the figure will be more like 10%. That means that 90% of
people want to just go ./configure;make and have Interbase compile for their
platform.

Bearing that in mind, I would think the best use of NewCo's resources would
be to make sure the engine is one codebase. Otherwise, I suspect the
instructions for some platforms will get so complicated that people won't
bother - especially in a year or so when more platforms have been added by
other parties. (eg: "To compile for YourNix, checkout the main Interbase
branch. Then change to the "something" directory, and checkout the YourNix
stuff. Now, if you are using v34.4, go to
http://patchfilehere.com/~what/a/long/pathname/ and get the
"InterbaseYourNix34.2.tar.gz" file. Don't get "InterbaseYourNix34.4.tar.gz"
unless you are using libxx1.2, because bugs exist. Now patch your main
Interbase distribution with this file, and edit the makefile." I know some
of you have experienced this kind of thing before)

I don't think they should bother removing old platform code - or maybe they
should put that in a "Old Release" tree or something. You can be sure
someone will want it sometime in the future.

I would have thought that removing the non-ANSI prototypes would be as
simple as running it through a C Pre-Processor, or maybe a little Perl
script - it isn't?

Don't move exclusivly to GCC - if it will compile with GCC on all platforms
that is great, but I believe that on Windows VC++ is still a better (ie,
generates faster code in most circumstances) compiler. I know Mozilla still
uses VC++ on Windows - but I must say Windows make files for GCC would be
nice.

Documentation - personally, I'd go with the 30 page overview, and maybe a
bit of extra documentation for key modules. Is the code reasonably readable
and self documenting? That kind of thing makes a big difference.

Regards
Nick Lothian

>
>Date: Thu, 27 Jan 2000 15:16:59 -0500
>From: Ann Harrison <harrison@...>
>
>Subject: Delivering sources
>
>
>As the opening of the source gets closer, I find myself
>wondering more and more about the details.
>
>Specifically, where to make the tradeoff
>between clean code and code now?
>
>At the moment, there's a single source for InterBase
>with magic in the source control tool to deal with
>differences between the various environments. The
>most significant of those is the use of $ in names.
>
>Should NewCo make a pass through the code once to
>so that the engine is actually, rather than almost,
>one code base? Should they go a step further and
>use GCC for all platforms?
>
>At one point, some of the compilers used to build
>InterBase did not accept ANSI prototypes. As a
>result, every routine has conditionalized prototypes.
>They're really ugly and completely useless. Should
>NewCo remove them before releasing the code?
>
>At various times, InterBase has been ported to
>platforms that are no longer strategic - like
>HP MPE/XL. Should NewCo remove the conditional
>code for those platforms? Just the really ugly
>ones?
>
>High level internals documentation is almost
>non-existent. Complete documentation would
>be (much) larger than the code, so that's not
>likely to appear. Should NewCo take the time
>to write module by module documentation? A
>~30 page overview?
>
>As you think about these questions, please remember
>that you (the knowledgeable InterBase developer) are
>not the only user of the source. It's important
>that the code that's released be buildable by humans
>on all the platforms it runs on.
>
>Appreciate your thoughts,
>
>Ann