[Source] Xj3D good to go; some build errors on NPS version

[Norbraten, Terry]

On 1/16/10 9:52 AM, "Don Brutzman" <brutzman at nps.edu> wrote:

> cc: source list and interested parties
> 
> Norbraten, Terry (CIV) wrote:
>> I¹ve successfully downloaded the new SVN repository and integrated our
>> stuff, rolled a build and created project and installer zips.
>> 
>> Project at: https://savage.nps.edu/norbraten/xj3d-2.0.zip (full netbeans
>> project minus the svn metadata)
> 
> great.  downloaded, extracted on my new laptop, but doesn't run
> presumably because it is not yet built:
> 
> ==============
> brutzman at WIN-E5MQ4YKHJRE /cygdrive/c/Program Files/xj3d-2.0-nps
> $ ./browser.bat
> Buildfile: \javaapis\Xj3d\build.xml does not exist!
> Build failed
> ==============

browser.bat in the project distribution expects a path to the build.xml as
\javaapis\Xj3d\build.xml.  You have it located at /cygdrive/c/Program
Files/xj3d-2.0-nps.  Probably easiest to modify the batch file than move the
project to \javaapis\Xj3D.  The batch file will call an Ant target of run3D
which will launch the browser (when project is built).  It is also designed
to have .x3d files mapped to this launcher so that double clicking an *.x3d
file will launch Xj3D.

You are correct that the batch launcher will also fail due to the project
not yet being fully built
 
> opening as a Netbeans project resulted in Reference Problems dialog,
> retyped here:
> 
> joal.jar file/folder could not be found
> cadfilter-classes file/folder could not be found
> gluegen-rt.jar file/folder could not be found
> browser-classes file/folder could not be found
> jogl.jar file/folder could not be found
> Xj3D-classes.jar file/folder could not be found
> JDK_1.5 platform could not be found
> 
> can references for the .jars and folder be added to our distribution?
> they appear to be present in the runtime_binaries subdirectory

Yes, the *.jar are now located in /lib to ease having to include these
distributions parallel to the Xj3D project build.  I've corrected the
build.properties file which will cure the jar reference problems.
runtime_binaries was included as a convenience to reference all required
platform natives as if the project was an installed version.

The reference problems to the varsious /classes folders will self correct
once Xj3D is built on your system.  We reference these class locations, vice
the distribution jar, in order to perform debugging the project.  To this
effect, we compile the project with all appropriate debug flags which tends
to inflate the bytecode size, but we're living with it.  We can optimize at
compile time if we need to however.

> 
> after creating a JDK_1.5 platform that mapped to 1.6, it cleans OK.
> however the build quickly stops with the following error:
> 
> ==============
> compile.grammars:
> C:\Program Files\xj3d-2.0-nps\build.xml:261: JavaCC home must be a valid
> directory.
> ==============
> 
> no doubt the prerequisite setup details are covered somewhere else,
> but i found very little to go on at
> http://xj3d.org/snapshots.html

For our project building, there are two files in the docs directory of the
project:
NPS-build-procedures-for-Xj3D.txt
Xj3D-Codebase-Changes-NPS.txt

The former details setup procedures.  Yumetech does not post our building
procedures.  The later details all we've done with our local version so that
there is some record for later reference.

The only build dependency that remains is that javacc is required parallel
to Xj3D project on your machine.  For you Don, you'll need to install, or
copy over javacc to \Program Files.

Yumetech requires backwards compatibility with the previous JDK, so, at
present we must maintain JDK 1.5 on our systems so that we can prove
compatibility before we commit anything to the repository.  Right now, we
have commit privileges for any of the dis packages (OpenDIS).  Anything else
needs to be looked over by Yumetech's unit tester, however, we make life
easier if we can build with JDK 1.5 using their make system.  If that
passes, they're likely to consider our codebase changes elsewhere.

For our purposes, we can point to JDK 1.6 and build, so, yes, mapping to JDK
1.6 via netbeans is okay.

> 
> once build completes, i hope to run debug mode to troubleshoot the
> following Xj3D error which is fatal in X3D-Edit/AUVW but forgiving
> in Yumetech's Xj3D standalone:
> 
> ==============
> Xj3D Version: 2_M1_DEV_2009-05-18
> System.out: Video card incapable of supporting OpenGL imaging subset.
> Blending disabled.
> 
> using new Toshiba Satellite PC with ATI Mobility Radeon HD 4600 Series
> ==============

I now recall the origin of this error.  Justin fixed this in aviatrix3D for
their latest installer version.  However, in the SVN trunk, a newer version
of avatrix3D was committed sometime ago that re-exposed the GL subset issue
for some video cards.   It's annoying, but harmless.  I had a similar
problem with an older Dell Inspiron that had an ATI Mobility Radeon card.
Can't remember exactly where, but the OpenGL site had a utility that you
could download to test and report all GL functionality available on your
system. 

If we retro the aviatrix3D in the SVN version to the version that works for
you, I'm not sure what will break.... Needs to be tested.

>> Installers:
>> https://savage.nps.edu/norbraten/xj3d-2.0-windows.jar (should work on
>> linux too, but untested)
>> https://savage.nps.edu/norbraten/xj3d-2.0-macosx.jar
>> [...]
> 
> am thinking it would be better to rename each of these as
> xj3d-2.0-nps-*.* to avoid downstream confusion

Can do.  Will modify build.properties to reflect.

> 
> Wondering if you have a running list of our modified files?  Perhaps
> an attempted (but not completed) svn commit can provide that. If so,
> it would be good to post to source list occasionally so that there
> is some visibility regarding our mods.

Yes, in docs/Xj3D-Codebase-Changes-NPS.txt

> 
> Thanks for your efforts.
> 
> all the best, Don