Jan Mikkelsen wrote:

>
> I've spent a little bit of time looking through the source code. Here are
> my first impressions:
>

Excellent. I'm glad someone is looking at it ;-)

> - The build system is really bad. Was there an improved system which was
> not released, or is this it?
>

If it builds at all on your machine, I bet it's improved. I know that
Ravi did a LOT of work on the build system after I left, and if someone
threw that out, they should be shot.
My poor 56k self hasn't downloaded it yet, but when I can get a couple
hours of free phone time I will. So keep in mind that I'm going from
memory, not looking at the current release.

> - The #ifdef approach to multiplatform code needs to be altered
> considerably. Splitting things into method specific files, with ifdefs by
> feature, rather than by platform is probably going to help. Things like
> really need to be fixed:
>
> #ifndef RANDOM_PLATFORM_1
> #ifndef RANDOM_PLATFORM_2
> #ifndef RANDOM_PLATFORM_3
> do something;
> #endif
> #endif
> #endif
>

YES! The #ifdefs are not well organized or documented. Some of them
are not well named (ie references to VAX* are sometimes only refering
to VAX endianness, rather than VAX processors) If you think
about the problem for a while, you will realize that any solution will
be quite complex. You need to have CPU architechture, OS, OS sub
versions,
whether the OS is unix like or something alien like NetWare, VMS, or
windows.
If unix like, is it more SYSV or BSD ish ?
Note that there are many permutations, and you would like to not
duplicate effort. That is, those things that are common to X86, you want
to define only once. So if you are compiling for linux on X86, you want

UNIX things
LINUX things
Big Endian things
32 BIT
X86 things
and so on

> - There seems to be (unless I've missed something) a bootstrapping problem:
> Just about everything (including gpre) seems to require files generated by
> codes.e which needs gpre to compile.
>

Like many systems, (compilers, operating systems, runtime libraries) IB
requires itself to build. Thus, you need to bootstrap with an existing
binary. For new ports, you need to do some gpre stuff (and a few
other things) on an existing IB platform. This will not change,
and there is not a good reason to change it.

> - sprintf() seems to be used unsafely (ie: with buffers potentially too
> small) in at least one place. I haven't gone looking for this kind of
> thing, so I assume it happens regularly.
>

I'm not surprised. An audit for misuse of string functions should be
a high priority. In the meantime, >I< would not expose port 3050 to
the internet.

> What's next:
>
> Unless someone has already done it, I'm going to throw away the current
> build system and create Makefiles for our in-house build system. Beyond
> that, I think there will be cruft removal and cleanup before any more
> functionality is added.

Don't bite of more than you care to chew. While many things that the old
build system did seem dumb at first glance, most had a reason at one
time.

Before I left IB, I had nearly completed a new system (which was
desigined
for use with Rationals ClearCase, but was generally much more modular
and clearly defined) I don't know if this still exists, and I have
no rights too it. If whoever owns this code could be convinced
to make it available, it would provide an alternate starting point.

Another (perhaps more reasonable) approache would be to try to convert
it to the GNU configure style. This would be a LOT of work.

>
> Jan Mikkelsen
>

Regards

--
Reed Mideke rfm(at)cruzers.com
If that doesn't work: rfm(at)portalofevil.com