Re: [openvrml-develop] Compiling 0.12 on Windows

[Braden McDaniel<bnm...@ea...>]

On Tue, 25 Jun 2002 17:14:24 +0200 Janusz Szpilewski <ja...@on...>
wrote:

> Compiler error:
> 
> vrml97node.cpp:105: common_type called with
> uncommon member types (compiler error)
> 
> can be fixed by moving 'NodeFieldPtrImpl'
> constructor definition (line 102) within the
> 'NodeFieldPtrImpl' class body.

Cool... thanks. I'll get this in for 0.12.3.

> Probably it is enough if the system has a lot
> of RAM (like 256MB or more), but in the case of
> more modest configurations splitting
> vrml97node.cpp into smaller files may be
> necessary.

Well, there is a reason not to do that. Eventually the code in vrml97node.cpp
will be moved out of the core and into a dlopened module. Everything that's in
the OpenVRML::Vrml97Node namespace now will be moved to an unnamed namespace;
and the module will expose only a few functions used for registration.

> There is another issue in script.cpp - it looks
> that gcc 2.95.3 has problems
> with handling 'const char' arrays (line 712:
> ScriptNode::createScript). Removing 'const' or
> replacing arrays with 'const char*' fixes the
> problem.

Alright... I'll fix that, too.

> Once I built OpenVRML 0.11.2 with Borland C++
> 5.5.1 by hacking the VC6 makefile (and some
> sources as well). I think that keeping OpenVRML
> portable among the major platforms and
> compilers is not so hard and is an important
> advantage so maybe we could make some efforts
> to keep it going...

It's not hard *if* you have people using those platforms/compilers who are
willing to test the development sources. We have been lacking in that regard.
I'm happy to accommodate the shortcomings of compilers (as long as the library
interface I'm trying to design remains intact), but I can't test everything.
The code in OpenVRML is changing quite a bit. So if keeping OpenVRML working
on a particular platform is important to you (and I mean the "general 'you'"
here, not just you specifically), check out the CVS sources from time to time
and make sure things are staying sane.

A related point: keeping multiple build systems in sync sucks. I would like to
have everything we support serviced from the GNU autotools build, but we
aren't there yet.

Braden