RE: [vrjuggler-devel] Package management for VR Juggler

[Marc B. <mar...@po...>]

My background is fairly Windows oriented... much more than UNIX oriented.
This probably explains why I dislike so much the whole concept of
environment variables. To me, we should be able to live without them
completely. Just to make it fair (and perhaps reassure some of you), I also
think that the windows registry concept was an evil invention. If it is at
all possible, I would definitely vote to simplify the mechanisms in place to
remove most, if not all, these environment variables. At most, you need to
set environment paths in either UNIX or Windows worlds so that DLL /
run-time libraries can be found as we launch a VRJ app. As for compiling the
code, there should be more contained ways to let the compiler know where
everything is. Maybe a simple "myVRJsetup.conf" file placed directly in the
root of a VRJ folder installation / version would suffice? Think of it as a
juggler config file for the compiler instead of to tell the configuration of
the VR system. The first MSWindows releases, up to 3.0 I think, were not
using registry files. Each program was installed in a dedicated folder and
an .INI file was placed there with it to tell the app whatever it needed to
know to run. It was so easy to manage installed applications as you could
simply move the entire folder and even back it up and restore with a single
file copy. That's the kind of thing I would think would be great here too. 

I was thinking that a small multi-platform GUI application could be bundled
with every VRJ package that would display all the installed VRJ version it
finds on the system and let the user pick one and click "select". The
application in question would handle all the required work to reconfigure
things behind so that the next time you compile or run a VRJ app, it uses
the selected version. Using such a GUI configuration tool would allow to
either setup environment variables for UNIX environment or registry keys for
the Windows platform without the user having to maintain or even care about
that information. This GUI could also be used to modify makefiles on-the-fly
so that the correct paths are in there to build against the chosen version.

An other alternative would be that run-time version information is encoded
in the VRJ project executable itself so that it finds the right libraries
version itself at start-up. DLL and other run-time resources would be
internally tagged as well so that versioning validation could be done at
run-time by the loading application. I am not convinced myself this is the
best approach... but just thinking out loud here.

I know these are very general / in surface suggestions, but my hope is to
inspire new alternate thinking about this that may lead to less conventional
solutions. The goal should be to simplify the developer task and get this
aspect out of its way as much as possible... make it as automatic as
possible.

In any event, I welcome this effort to support multi-versioning in VRJ.

Best regards,

=====================================
Marc Bernatchez
Candidat au Ph.D.
Ecole Polytechnique de Montreal
Montreal, QC, CANADA
=====================================
Virtual Reality web site, VResources:
http://vresources.org
=====================================