Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Mourad, On 16 May 2017 at 08:51, Mourad Boufarguine wrote: > Builds and osgviewer runs fine with VS 2015 Win64. Thanks for the testing. > I got these debug output to the console : > > _forceVertexArrayObject = 0 > _forceVertexBufferObject = 0 >

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Robert, Builds and osgviewer runs fine with VS 2015 Win64. I got these debug output to the console : _forceVertexArrayObject = 0 _forceVertexBufferObject = 0 _forceVertexArrayObject = 0 _forceVertexBufferObject = 0 _forceVertexArrayObject = 0 _forceVertexBufferObject = 0

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Mourad, On 15 May 2017 at 14:52, Mourad Boufarguine wrote: > You're right we need both : > > COLLADA_BOOST_BUILDNAME : to follow boost naming convention with 3 digits > for MSVC toolset version > COLLADA_BUILDNAME : to follow collada naming convention with 1/2

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

You're right we need both : COLLADA_BOOST_BUILDNAME : to follow boost naming convention with 3 digits for MSVC toolset version COLLADA_BUILDNAME : to follow collada naming convention with 1/2 digits for MSVC toolset version On Mon, May 15, 2017 at 3:32 PM, Robert Osfield

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Mourad, On 15 May 2017 at 14:16, Mourad Boufarguine wrote: > You are missing the ending 0s. I was just following Torben's usage, if we add back the 0's then the search names would change. I presume this is why Torben introduced using two variables

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

You are missing the ending 0s. By the way the MSVCXX vars are discouraged (there is no var defined starting from Visual 2017), MSVC_VERSION is the recommended way now : https://cmake.org/cmake/help/v3.8/variable/MSVC14.html?highlight=msvc14 IF(APPLE) SET(COLLADA_BUILDNAME "mac") ELSEIF(MINGW)

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

On 15 May 2017 at 13:08, Robert Osfield wrote: > Looks like we'll need to rewrite this problem block for the case when > CMAKE_VS_PLATFORM_TOOLSET is not set. > > Don't yet know what this might be though... Would the following approach work better? -- Modified

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Robert, I think it is more correct to use the same logic (testing against the compiler version CMAKE_CXX_COMPILER_VERSION ) as in the mainstream FindBoost.cmake : https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L432-L453 Cheers, Mourad On Mon, May 15, 2017 at 2:08 PM,

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Mourad, On 15 May 2017 at 12:58, Mourad Boufarguine wrote: > CMAKE_VS_PLATFORM_TOOLSET is not set unless the user explicitely specifies a > toolset when invoking cmake : > > cmake -G "Visual Studio XX" -T v1YY srcDir > > If the user does not specify a toolset,

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Robert (and Mourad), I tried -T v140 but I still didn't seem to get that variable set, with or without the -G option. And note that I use MinGW makefiles even when building with MSVC so deducing partially from -G won't work right in that case anyway. From this page

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Robert, CMAKE_VS_PLATFORM_TOOLSET is not set unless the user explicitely specifies a toolset when invoking cmake : cmake -G "Visual Studio XX" -T v1YY srcDir If the user does not specify a toolset, the default toolset of the chosen Visual Studio version will be used, but the

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Stuart, On 15 May 2017 at 12:07, Stuart Mentzer wrote: > https://cmake.org/cmake/help/v3.0/variable/CMAKE_VS_PLATFORM_TOOLSET.html > > Which mentons that it's set for VC10 and above. Torben uses the > CMAKE_VS_PLATFORM_TOOLSET for vc8 and vc9 above, so I'm not what

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Robert, On 5/15/2017 5:13 AM, Robert Osfield wrote: Hi Stuart, On 12 May 2017 at 14:32, Stuart Mentzer wrote: I always build from scratch in an empty build directory. Thanks for the clarification. Adding " around the 3rd and 4th args in the REPLACE lines did

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Stuart, On 12 May 2017 at 14:32, Stuart Mentzer wrote: > I always build from scratch in an empty build directory. Thanks for the clarification. > Adding " around the 3rd and 4th args in the REPLACE lines did indeed > eliminate the error. Torben should check that

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Robert, A very minor one, but I've noticed that in osg::Text::computePositionsImplementation(), any bounding box margins set are never taken into account when calculating the position of the text, as the positions are calculated from the bounding box before the margins are applied. Code:

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

I always build from scratch in an empty build directory. What platform and build tools are you using? The use of REPLACE was introduced in a submission from Torben related to VS2017 binary support:

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

I always build from scratch in an empty build directory. What platform and build tools are you using? The use of REPLACE was introduced in a submission from Torben related to VS2017 binary support:

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

> I always build from scratch in an empty build directory. What platform and build tools are you using? The use of REPLACE was introduced in a submission from Torben related to VS2017 binary support:

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

On 5/12/2017 4:50 AM, Robert Osfield wrote: Hi Stuart, On 12 May 2017 at 09:18, Stuart Mentzer wrote: I don't think it is a change in CMake: it looks like REPLACE has had the same syntax since at least 3.0: string(REPLACE [...]) The version of

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Stuart, On 12 May 2017 at 09:18, Stuart Mentzer wrote: > I don't think it is a change in CMake: it looks like REPLACE has had the > same syntax since at least 3.0: > > string(REPLACE > > [...]) > > The version of FindCOLLADA.cmake in 3.4.0 didn't

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

I don't think it is a change in CMake: it looks like REPLACE has had the same syntax since at least 3.0: string(REPLACE [...]) The version of FindCOLLADA.cmake in 3.4.0 didn't have the REPLACE lines, so I guess that is where the problem lies. The (first) offending line

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

HI Stuart, On 12 May 2017 at 02:04, Stuart Mentzer wrote: > Current master build fails on Windows with: > CMake Error at CMakeModules/FindCOLLADA.cmake:37 (string): > string sub-command REPLACE requires at least four arguments. > Call Stack (most recent call first): >

Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi Robert, Current master build fails on Windows with: CMake Error at CMakeModules/FindCOLLADA.cmake:37 (string): string sub-command REPLACE requires at least four arguments. Call Stack (most recent call first): CMakeLists.txt:743 (FIND_PACKAGE) Details: Windows 10, CMake 3.8.1, Visual C++

[osg-users] Call for testing, preparing for 3.5.6 dev release again :-)

Hi All, Today I merged two branches into master that contain some significant changes to KdTree, LineSegment and PolytopIntersector and AutoTransform respectively. I would like testing of these as well all the rest of the changes from the community that I've merged this week. If things look