Robert
Thanks - I have no problem with keeping the dlls local to the app. I can
see that osgPlugins could be a more awkward problem as interim updated
releases may be necessary for specific plugins, and you would not want
to update the whole library.
Out of curiosity, would it be breaking the osg licence if one chose to
build the dlls with names using specific version numbers?
Cheers
Alan
Robert Osfield wrote:
Hi Alan,
In the past the way to manage the different version was to keep the
libs all local to your application.
For 2.0 we can potentially use CMake's support for versioning
filenames, something that kinda complicates this is the GNU convention
of using ABI numbers rather than version numbers. I am also thinking
above naming the installed osgPlugins lib directory by the version
number too.
Robert.
On 5/18/07, Alan Harris <[EMAIL PROTECTED]> wrote:
Robert
Something I have been wondering about is the differentiation between osg
versions. Perhaps this has already been covered, but I notice from the
mail that some users have problems with the (wrongly) mixed use of
versions - but that is during development.
As osg is becoming more widely used for applications, it is more than
likely that an end user of more than one application will have different
osg versions for each of the applications.
I know some dlls attach the version number to the dll. e.g mfc71. This
avoids the worst of the possible problems and they can usually be
updated if the API is not affected.
What is the situation with osg? Do we have to ensure that the
appropriate osg dlls are in the same folder as the application because
that is usually the first place that is examined for the dll.
Perhaps dll problems are just a function of Windows - I do not have
experience of other systems.
Regards
Alan Harris
Robert Osfield wrote:
> Hi All,
>
> I have exchanged emails with Paul Martz about getting 2.0 out in time
> for his publishing on the Quick Start Guide, should be out in the
> first week of June with a final draft before this.
>
> So this gives 2-3 weeks to get 2.0 out the door. Yikes you might
> think, and rightly so ;-)
>
> First up I have to say that I'd like now we have weekly dev releases
> going out, without too much overhead at my end (takes about a hour of
> my time), doing minor point releases for stable versions should not be
> so daunting as it was. I we can make minor point releases more often,
> then having one that is not quite perfect is much less of a worry -
> since another one will come out shortly after to fix any problems that
> arise.
>
> The real difference between a dev release and stable release is a bit
> more testing in the run up, the production of binaries, and the
> updating of docs on the website. I can't do most of this myself,
> I'll need members of the community to pitch in with testing, producing
> the binaries and help get the web pages updated. Also the more
> streamlined we can make all of this, the quicker and more often we can
> get releases out. At least that the theory..
>
> Due to this quick time frame I simply won't be able to complete all of
> functionality that I wanted for 2.0, such as osgViewer, osgShadow and
> osgTerrain work, this is shame, but I'd now rather have a 2.0 out in
> time for the book to go, and to keep the book straight forward in
> terms of referencing 2.0 binaries and source cde - otherwise you'll
> end up with a book talking about something that hasn't come out yet,
> and binaries that don't exist, or it ends up bogged down talking about
> dev releases.
>
> Overall my impression is that the 1.9.x dev series have been pretty
> stable, a few hiccups here and there on build and execution, but my
> guess we are well in the same ballpark as the quality of 1.2, and in
> many areas I know it far exceeds that of 1.2 since we've made so many
> bugs fixes over the past 8 months.
>
> For the loose ends we currently have, I'd say lets log them, try and
> fix them for 2.0, but if we can't just push ahead get 2.0 - just make
> sure there is no show stoppers on the main platforms. Any remaining
> loose end we can scoop up after 2.0 with 2.0.1, 2.0.2 etc releases.
>
> I look forward to feedback and your assistance. In particular we need
> volunteers to build binaries on the 3 main platforms - Windows, Linux
> and OSX.
>
> Thanks in advance,
> Robert.
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
