Hello Serge,
> First thanks for your work !
It's my pleasure. Being one of the active Win32 people on this list
and having written some of the docs on getting OSG compiled and
installed, I felt I had to chip in to fix this so it works correctly
(according to the OS specs).
> And everything
On 8/21/07, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote:
>
> Hello Robert, Roger, Serge,
>
> > Just post the changes when you are happy.
>
> Here's a version that seems to work as intended. I would appreciate it
> if some Win32 people could test this out (Roger and Serge in
> particular, please).
Hello Robert, Roger, Serge,
Just post the changes when you are happy.
Here's a version that seems to work as intended. I would appreciate it
if some Win32 people could test this out (Roger and Serge in
particular, please).
Please test this by replacing the file in src/osgDB, recompiling
Hello Robert,
> I don't know of a way. One could come up with a mechanism, but there
> might be another platform specific means.
I was hoping there was something in ArgumentParser or in some other
basic OSG class that could help. I'll see what I can come up with.
> One could possible just get
On 8/21/07, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote:
> This is not the same as ".", because the app could have been started
> with a relative path, for example if the current dir is C:\myproject
> and I type "bin\myexecutable.exe". What I need is "C:\myproject\bin".
>
> I would be able to get
Hello Robert,
>> Could a windows developer have a go at tweaking the
>> osg::appendPlatformSpecificLibraryFilePaths(..) Win32 implemention in
>> src/osgDB/FileUtils.cpp to honour this convention.
>
> I'll take a stab at this. I'll also set myself up to test the "local
> DLLs" usage pattern. Should
Hello Robert,
> Added "" would just be so one can find a local osgPlugins-version
> directory, it doesn't defeat the purpose as the osgPlugins-version is
> prepended by default.
But isn't the local osgPlugins-version dir found already? I got that
impression from Serge's comments, but haven't tr
Hello Robert, Roger,
> Could a windows developer have a go at tweaking the
> osg::appendPlatformSpecificLibraryFilePaths(..) Win32 implemention in
> src/osgDB/FileUtils.cpp to honour this convention.
I'll take a stab at this. I'll also set myself up to test the "local
DLLs" usage pattern. Shoul
HI J-S,
On 8/21/07, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote:
> It isn't dangerous per se, but it defeats the purpose of having an
> osgPlugins-version directory. We'll be back to the old days when it
> was too easy to have plugin version mismatches. I would vote not to
> add "" or "." to the
Hello,
> 1. Serges problem with the trailing semicolon on the the path. Its
> absence or presence should not affect the behaviour, it is optional
> on a windows path.
I agree, this should be fixed. When the PATH is parsed, a trailing
semicolon without anything after it should not add "" t
Hello Serge and Robert,
>> OK, we're homing in on a possible solution now. Should we add "" or
>> "." to the list of paths to check? Should this be something down by
>> the app or part of sgDB::appendPlatformSpecificLibraryFilePaths()?
>>
>> This are question I put to Windows developers. What w
Hi Roger et. al,
On 8/21/07, Roger James <[EMAIL PROTECTED]> wrote:
> There is a formal definition, newer versions of windows can specify an
> alternate search strategy.
>
> http://msdn2.microsoft.com/en-us/library/ms682586.aspx
Thanks for the link Roger, this looks pretty straight forward.
Cou
On 8/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> It seems a long time since I inadvertantly triggered this debate. Sorry I
> have not been able to contribute much as I had my laptop stolen in Barcelona
> airport last week. (So if anyone gets offered as cheap Dell M60 beware, the
> lcd
On Tue Aug 21 1:19 , 'Serge Lages' <[EMAIL PROTECTED]> sent:
>On 8/20/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
>
>OK, we're homing in on a possible solution now.  Should we add "" or
>"." to the list of paths to check?  Should this be something down by
>the app or part of sgDB::appen
On 8/20/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
>
>
> OK, we're homing in on a possible solution now. Should we add "" or
> "." to the list of paths to check? Should this be something down by
> the app or part of sgDB::appendPlatformSpecificLibraryFilePaths()?
>
> This are question I put to
Hi Serge,
On 8/20/07, Serge Lages <[EMAIL PROTECTED]> wrote:
> Here is my path, simplified for the tests :
> Path=C:\WINDOWS\system32;C:\WINDOWS
>
> Note that if I change my path to :
> Path=C:\WINDOWS\system32;C:\WINDOWS;
> (there is a ";" at the end)
> It works without having to create an osgPlu
On 8/20/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
>
> HI Serge,
>
> What is your PATH currently set to?
>
>
Here is my path, simplified for the tests :
Path=C:\WINDOWS\system32;C:\WINDOWS
Note that if I change my path to :
Path=C:\WINDOWS\system32;C:\WINDOWS;
(there is a ";" at the end)
It wor
HI Serge,
What is your PATH currently set to?
Robert.
On 8/20/07, Serge Lages <[EMAIL PROTECTED]> wrote:
> On 8/20/07, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote:
> > Hello Serge,
> >
> > > After an INSTALL build, all my dlls are put into the same target
> directory,
> > > there is no more an
Hello Serge,
> I have reverted the Robert's modification and tried a INSTALL build (after
> deleting CMakeCache files), and there is no osgPlugins-version directory. I
> need Robert's modified file to get it, and I use the SVN version. My CMake
> version is 2.4.
That's weird, as I also use the SV
On 8/20/07, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote:
>
> Hello Serge,
>
> > After an INSTALL build, all my dlls are put into the same target
> directory,
> > there is no more an osgPlugins-version directory (it is the CMAKE
> default
> > behaviour under Windows).
>
> No, the default behaviour
Hello Serge,
> But I
> still find this behaviour strange, why looking directly for the plugin name
> into the systems locations but not into the local directory ?
It should never look for just the plugin name. It should always
(whether it's with a directory in the PATH or in the current
direc
Hello Serge,
> After an INSTALL build, all my dlls are put into the same target directory,
> there is no more an osgPlugins-version directory (it is the CMAKE default
> behaviour under Windows).
No, the default behaviour on Windows is the same as on other platforms
- to make a bin\osgPlugins-Ve
On 8/20/07, Serge Lages <[EMAIL PROTECTED]> wrote:
> Sorry for my poor english. :/
Your English good, its just a topic that requires one to be really
exact to be able to understand it. English and computers don't really
mix :-)
> Let's take an example, I have a PATH variable like that :
> C:/Win
On 8/20/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
>
> On 8/20/07, Serge Lages <[EMAIL PROTECTED]> wrote:
> > It's building...
> >
> > But there is still something I don't understand, for the locations
> included
> > into the PATH, it looks for osgPlugins-version/ and then only the simple
> > fi
On 8/20/07, Serge Lages <[EMAIL PROTECTED]> wrote:
>
> It's building...
>
> But there is still something I don't understand, for the locations
> included into the PATH, it looks for osgPlugins-version/ and then only the
> simple file name (that is why adding "./" to the PATH works), why it doesn't
On 8/20/07, Serge Lages <[EMAIL PROTECTED]> wrote:
> It's building...
>
> But there is still something I don't understand, for the locations included
> into the PATH, it looks for osgPlugins-version/ and then only the simple
> file name (that is why adding "./" to the PATH works), why it doesn't ma
On 8/20/07, SCETBUN benjamin <[EMAIL PROTECTED]> wrote:
> HI Robert,
> But if i want to deploy my application without any installation of osg? Do
> you got any solution?
Deploying you own app is up to you how you do it. All I can say is
that in your bin directory you should have a osgPlugin-vers
It's building...
But there is still something I don't understand, for the locations included
into the PATH, it looks for osgPlugins-version/ and then only the simple
file name (that is why adding "./" to the PATH works), why it doesn't make
the same thing into the local directory (first osgPlugins
HI Robert,
But if i want to deploy my application without any installation of osg? Do
you got any solution?
2007/8/20, Robert Osfield <[EMAIL PROTECTED]>:
>
> Hi Serge,
>
> What is intended to happen is that the plugins should all reside in a
> osgPlugins-version directory, both in install and whe
On 8/20/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
> I have made this mods to the attached OsgMacroUtils.cmake.
Oopss now attached ;-)
OsgMacroUtils.cmake
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://
I have just done some investigation into the install location, its set
by OpenSceneGraph/CMakeModules/OsgMacroUtils.cmake:
IF(WIN32)
INSTALL(TARGETS ${TARGET_TARGETNAME} RUNTIME DESTINATION bin
ARCHIVE DESTINATION lib LIBRARY DESTINATION bin )
ELSE(WIN32)
INSTALL(TARGETS ${
Hi Serge,
What is intended to happen is that the plugins should all reside in a
osgPlugins-version directory, both in install and when you use it
locally in your app. The osgPlugins-version directory is there to
help prevent mixing of different versions of the OSG. osgDB now
enforces the prefixi
Hi Robert,
Since the last changes on osgDB/FileUtils.cpp and osgDB/Registry.cpp I have
a strange behaviour with the plugins loading (I work under Windows XP and
Visual Studio 2005).
After an INSTALL build, all my dlls are put into the same target directory,
there is no more an osgPlugins-version
33 matches
Mail list logo
