>
>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?
>

I believe that code soon is more desirable than code
later. The amount of cleanup that should be
done (IMHO) is that a user should be able to
upack a compressed archive, follow some fairly
simple instructions, and have a working product
result on the current main platforms (NT, Solaris,
HP, and Linux). The goal should be that you can unpack
and do ./configure ; make ; make install
on any supported platform, but I don't think that this
should be a prerequisite of releasing the source.

>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.

Have already ported this stuff to clearcase, which did
not do magic translations, I can say with confidence that
this is not a big issue.
All current platforms are get the $ translated to an _
before you see the source. Marion also translates
#include "source/{compontent}/foo.h" to
#include "../{component}/foo.h" on windows,
but the second version can also work on unix. The super
server build might need some additional slinks.
There is also the issue of MS-DOS descended operating
system (or rather the tools on them) wanting a ^M
at the end of line. Most open source project I know
of (perl and VIM, for example) have two source distributions,
which vary only by the ^M. There plenty tools that
can be used to do that.

>
>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?
>

I don't see any reason to wait for this. Most open source
projects work with either GCC or the native commercial
compiler on most platforms, and on some platforms
require one or the other. Porting IB to the CYGWIN
environment on windows would be a fair amount of work
and maybe not desirable. Porting it to MINGW32 would
probably be easier, but not trivial. I think that both
of the above compilers are still beta, and I know from
expirience that CYGWIN32 has some rough edges.
Porting IB on NT to Borland C would also take some work,
but should not be impossible. I believe that Mark Duquette
was the last person to look into this.
It seems to me that porting to other compilers is
something that the community at large can do, as individuals
see the need for IB to be buildable on a particular
compiler. A word of caution to those who do:
IB has a history of finding compiler bugs, espeically
breaking compilers optimizers. The good news is that if
you find bugs in GCC, you actually have a chance of
getting them fixed ;-).
IMHO, requiring GCC on all platforms is not a good idea.
The vendor compilers often produce better code, and
in the case of some unix's, are included with the OS.
Supporting more than one compiler per OS is not that hard,
especially if it's the person who want the particular
that maintains the required bits of makefile.

>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?
>

IMHO, their ugly but not particularly harmful. If someone
wants to go on an ANSI crusade, that's fine, but I see
no reason why this should delay the source release. I think
inside IB we had already made a descision to not include
the standared ANSI ifdef wrapper around new functions.

>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?

Again, I think this is something that can be removed as
we go along. The code is all ifdefed, so shouldn't
do any harm. (aside from increasing source download
time very slightly, and making the code a litte harder to
follow.) The community should evalute which
platforms we think are truely dead. There are a lot of
people who continue to use 'obsolete' platforms, and
if they wanted to put the effort into maintaining IB
on one of them, they should be able to. There still are
a few people out there using, say nextstep, and although
IB hasn't been built on nextstep since 3.3, the NeXT
ifdefs are probably a better starting place than nothing
at all.

>
>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?
>

I believe that would be excellent. But if not all the
documentation was completed before the source release,
I think that could be OK as well. If there was a basic
document describing what each of the components was for
(I mean the marion 'components'), the more detailed
documentation could be produced while the comunity was
learning to get it built and so on.

I know that there are some architechtural documents around
that were in hardcopy only, and getting these digitized could be
a good start.

>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.
>

Absolutly.

>Appreciate your thoughts,
>
>Ann

_________________________________________________________
Get your own FREE portalofevil.com Email account at...
http://www.portalofevil.com

PortalofEvil.com - Websites by the insane for the insane.
_________________________________________________________