Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[Stuart Mentzer]

Hi Robert,

OSG 3.6.5-rc2 built fine on Windows with VC2019 (so VC2017 is probably OK) 
and appears to be running properly in our application. If there are more 
RCs I can try to test those and I should be able to get 3.6.5 binaries 
posted soon after it is released.

Other than the usual mods I make to build with VC using GNU make the FBX 
plugin support has some issues that I worked around, wrt CMake usage and 
support for the newer VC and FBX versions. I can share my fixed versions if 
you would like and you tell me the best way to do that now.

Cheers,
Stuart

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/19f2d491-8ffc-45fc-b7fe-5126c48ea797%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [ANN] OSG 3.6.4 Windows VC++ Binaries Posted

[Stuart Mentzer]

Hello dear OSG-community,

The OSG 3.6.4 Windows binaries at https://objexx.com/OpenSceneGraph.html were 
refreshed with the latest 3rd party packages and the just-released Qt 5.13.2.

This refresh adds support for both the old osgQt (that is now in their Qt4 
branch) and the new osgQOpenGL approach (from the current osgQt git master 
branch). This should let projects transition to osQOpenGL when they are ready 
(and can get it to work in their applications, which we haven't managed yet!).

Best regards,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76865#76865





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [ANN] OSG 3.6.4 Windows VC++ Binaries Posted

[Stuart Mentzer]

Hello OSG-community,

OSG 3.6.4 Windows 64-bit binaries built with Visual C++ 2017 are now available 
from this page on my company's site: https://objexx.com/OpenSceneGraph.html

Release and debug builds are provided.

Plugins for curl, FBX, freetype, GDAL, giflib, glut, jpeg, lpng, minizip, tiff, 
and zlib are included. The FBX plugin is a new addition based on a recent 
request.

osgQt is included but from the April 2018 Qt4-tagged revision: we haven't 
figured out how to migrate to the new osgQOpenGL system yet!

Other builds and additional plugins may be possible by arrangement.

[Robert, feel free to a another link to the Stable release 3.6.4 entry as you 
did for 3.6.3.]

Best regards,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76645#76645





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osg::Cylinder height change not shown in OSG 3.6.3

[Stuart Mentzer]

Hi,

I have an osg::Cylinder in an osg::ShapeDrawable and I change its height in an 
UpdateCallback like this:

Code:
cylinder->setHeight( h );
drawable->dirtyDisplayList();
drawable->dirtyBound();




This works in OSG 3.4.1 but with OSG 3.6.3 (at least on my Windows builds) the 
height change doesn't show up. Checking the value with getHeight shows that the 
cylinder height is updated so maybe the issue is that dirtyDisplayList is no 
longer sufficient to trigger the display update.

I can try to put together a small self-contained example if this doesn't give 
anyone a clue what is going on.

Any help will be much appreciated. And if this has exposed an OSG bug it would 
be good to fix for 3.6.4.

Thanks!

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75246#75246





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [ANN] OSG 3.6.3 Windows VC++ Binaries Posted

[Stuart Mentzer]

Hi Robert,


robertosfield wrote:
> 
> That's a great contribution.  Are you OK will me adding a link to the 
> Downloads page pointing at these binaries?
> 


Yes, that would make it easier for people to find them.

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75155#75155





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [ANN] OSG 3.6.3 Windows VC++ Binaries Posted

[Stuart Mentzer]

Hello dear OSG-community,

OSG 3.6.3 Windows binaries built with Visual C++ 2017 are now available from 
this page on my company's site: 
http://objexx.com/OpenSceneGraph.html

Release and debug builds are provided.

osgQt built from the git master head is included.

The  curl, freetype, GDAL, giflib, glut, jpeg, lpng, minizip, tiff, and 
zlib plugins are included and the versions are shown on the page.

The GDAL plugin is new in the OSG 3.6.3 builds.

A ReadMe.txt file in the root directory of the expanded package has 
some details. 

These are 64-bit builds with the default GL2 OpenGL level.

Other builds and additional plugins may be provided upon request.



Best regards, 
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75150#75150





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgQt + OSG 3.6.2 Status

[Stuart Mentzer]

Circling back to my original issue, I got my OSG Qt viewer widget running with 
OSG 3.6.2 and osgQt by moving all the GL-related boilerplate after the main 
window show() call happens. I'm not sure what changed in Qt or osgQt to require 
this but this could be useful for other osgQt users.

Wojtek: thanks. I was already doing
camera->setDrawBuffer(GL_BACK)
but that does seem to be another thing that we didn't used to need. Maybe the 
osgQt docs should collect these migration tips.

A minor annoyance remains that I didn't have before: the OSG viewer is in a tab 
widget and I have to setCurrentWidget to a different tab and then back on to 
the OSG widget tab to get the OSG model to appear. No explicit repaint, 
updateGL, etc. calls worked.

On a related note, I got a tip to use

Code:
QApplication::setAttribute(Qt::AA_DontCheckOpenGLContextThreadAffinity, true);


to allow use of multithreading in Qt 5. It does allow things to run but I'm not 
sure if this is safe. Thoughts?

As far as the lively Qt discussion, I think you are all correct. Qt is probably 
the best cross-platform GUI framework we have AND it is deeply flawed. QML is 
nifty for mobile/etc GUIs but it is causing the C++ side to be neglected. Qt3D 
is getting pretty good but may not be up to serious visualization applications 
out of the box yet. E.g., I'll have to write a manipulator to get close to 
OSG's great trackball. Our application is well-layered so that we can easily 
keep experimenting in a Qt3D branch while using OSG for production builds. I 
hope that osgQt will keep up with Qt and that solutions for the integration and 
multithreading can be found. Maybe we can get more involvement from the Qt devs 
-- they are certainly aware and supportive of the OSG integration.

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74418#74418





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgQt + OSG 3.6.2 Status

[Stuart Mentzer]

Hi Andrew,

I had no luck despite trying many variations. I had to put this work aside for 
a while with the plan to circle back and check for osgQt updates now and then. 
But if someone adds some ideas here I'll try them.


To be honest I'm experimenting with Qt3D (feels a little dirty ;-). I know I 
won't get OSG performance out of it but the reduced Qt integration, Qt5, 
multithreading, and packaging hassles might make this a viable alternative 
soon. Qt3D has its own headaches, of course, and is still fairly immature. 
Maybe I can join a support group for OSG users with a wandering eye.


Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74396#74396





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgQt + OSG 3.6.2 Status

[Stuart Mentzer]

Thanks for the outline. I will work through this and experiment with my code. 
If I learn anything interesting/useful I'll post it.

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74360#74360





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgQt + OSG 3.6.2 Status

[Stuart Mentzer]

Hi Robert,

Yes, I'm aware of the examples and osgQtWidgets runs fine with my builds. But 
none of them match how we have used osgQt in the past with a single-view class 
derived from osgQt::GLWidget and osgViewer and a GraphicsWindowQt. And there 
are no examples for the new osgQOpenGL approach.

My viewer code works fine in OSG 3.4.1 on Windows and Linux but doesn't work 
with 3.6.2 and the current osgQt master, and I'm not sure where the problem 
lies.

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74358#74358





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgQt + OSG 3.6.2 Status

[Stuart Mentzer]

Thanks for the info @davisjamesf. I wish I knew what secret sauce was needed to 
get this running. I'll keep trying and maybe I'll have luck with some future 
osgQt release.

If you or anyone have some example code for a single view class derived from 
osgQt::GLWidget and osgViewer (or a better design) that can display a scene 
using current osgQt + OSG 3.6.2 that should get me started.

Thanks,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74354#74354





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgQt + OSG 3.6.2 Status

[Stuart Mentzer]

Hi,

I'm looking for info on the status of osgQt for OSG 3.6.2.

I tried using the osgQt git master code with my OSG 3.6.2 + Qt 5.11.1 Windows 
build but I get a black OSG widget with our application, which works fine with 
OSG 3.4.1. I tried a number of variations with no luck. I also tried the new 
osgQOpenGL code but without examples I couldn't get it working correctly.

If either of these osgQt approaches are working with OSG 3.6.2 for anyone else 
it would be helpful to get any usage tips.

Once we have a compatible osgQt we plan to post the OSG 3.6.2 + osgQt Windows 
binaries to our company site like we do for 3.4.0 and 3.4.1.

Thanks,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74345#74345





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Where can i find the windows binaries

[Stuart Mentzer]

Hi Peter,

My company, Objexx (http://objexx.com), is providing Windows binaries at this 
page: http://objexx.com/OpenSceneGraph.html.

We have 3.4.0 and 3.4.1 and we'll be doing 3.6.1 with Qt 5.11 soon. If you have 
special requirements or you need 3.6.1 ASAP let me know.

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73905#73905





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [EXTERNAL] Re: Is there a binary distribution available for version 3.4.0?

[Stuart Mentzer]

Hi Brian,

No, we aren't using VS 2013 any more. If you are in a pickle for VS 2013 builds 
contact me and we'll look at the options for getting that done.

Regards,
Stuart
--
Stuart Mentzer
Objexx Engineering
/Office/  +1 781 455 1150 x11
/Mobile/ +1 781 708 3872

On 10/5/2017 1:59 PM, Brian Davis wrote:


Thanks for the response, Stuart.  Much appreciated.

Do you have a Visual Studio 2013 version?  It looks like no, based on your web 
site, but I wanted to ask.

Cheers,
Brian

*From:*osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] *On Behalf 
Of *Stuart Mentzer
*Sent:* Thursday, October 05, 2017 2:26 AM
*To:* osg-users@lists.openscenegraph.org
*Subject:* [EXTERNAL] Re: [osg-users] Is there a binary distribution available 
for version 3.4.0?

*External Sender: Use caution with links/attachments.**

*

Hi Brian,

I'm not sure what your definition of publicly maintained is but my company is providing Windows builds of OSG 
3.4.0 at http://objexx.com/OpenSceneGraph.html 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__objexx.com_OpenSceneGraph.html=DwMDaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=5bxVULx1mckzDfACIFrAQIBf0kuZWt0S6r7kBSswDmQ=LhI3dmNBsTDv9bkGafOzomUka-OKRj3XlwK8-R1kvIc=dvVyThGuzcsE-4xj1nxcPYAyEfWm1MyfhgHGuojwh5w=>.
 We set up an automated build system because we need these binaries ourselves and we found no other source 
for recent releases.

We are willing to entertain requests for additional 3rd party libraries and for 
builds of development releases. We will be posting 3.4.1 binaries within the 
next couple of weeks (waiting for Qt 5.9.2 or 5.10) and we could also post 
3.4.0 builds with up-to-date 3rd party library versions.

If you have any questions about our builds just let me know.

Regards,
Stuart

--
Stuart Mentzer
Objexx Engineering

On 10/5/2017 3:01 AM, Brian Davis wrote:

Are there any publicly maintained binary distributions of version 3.4.0 
available for Windows?

For purposes of IP compliance scans of our software, use of a publicly 
maintained binary distribution works better than building it ourselves.  We 
currently have binaries that we have built, but are interested in using a 
public binary distribution if available.

Thanks,

Brian


--

This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient. Any review, 
use, distribution, or disclosure by others is strictly prohibited. If you are 
not the intended recipient (or authorized to receive information for the 
intended recipient), please contact the sender by reply e-mail and delete all 
copies of this message.



___

osg-users mailing list

osg-users@lists.openscenegraph.org 
<mailto:osg-users@lists.openscenegraph.org>

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openscenegraph.org_listinfo.cgi_osg-2Dusers-2Dopenscenegraph.org=DwMDaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=5bxVULx1mckzDfACIFrAQIBf0kuZWt0S6r7kBSswDmQ=LhI3dmNBsTDv9bkGafOzomUka-OKRj3XlwK8-R1kvIc=J3kb84kmZN6_y9WNFSFwGpYfyMqEV9nnn0zSNiDckQI=>



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Is there a binary distribution available for version 3.4.0?

[Stuart Mentzer]

Hi Brian,

I'm not sure what your definition of publicly maintained is but my company is 
providing Windows builds of OSG 3.4.0 at http://objexx.com/OpenSceneGraph.html. 
We set up an automated build system because we need these binaries ourselves 
and we found no other source for recent releases.

We are willing to entertain requests for additional 3rd party libraries and for 
builds of development releases. We will be posting 3.4.1 binaries within the 
next couple of weeks (waiting for Qt 5.9.2 or 5.10) and we could also post 
3.4.0 builds with up-to-date 3rd party library versions.

If you have any questions about our builds just let me know.

Regards,
Stuart
--
Stuart Mentzer
Objexx Engineering
//

On 10/5/2017 3:01 AM, Brian Davis wrote:

Are there any publicly maintained binary distributions of version 3.4.0 
available for Windows?

For purposes of IP compliance scans of our software, use of a publicly 
maintained binary distribution works better than building it ourselves.  We 
currently have binaries that we have built, but are interested in using a 
public binary distribution if available.

Thanks,
Brian
--
This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient. Any review, 
use, distribution, or disclosure by others is strictly prohibited. If you are 
not the intended recipient (or authorized to receive information for the 
intended recipient), please contact the sender by reply e-mail and delete all 
copies of this message.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Stuart Mentzer]

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 
(https://cmake.org/cmake/help/latest/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.html)
 it looks like Windows 10 may do things a little differently (I'm on Win10).

I guess the discussion from 
http://forum.openscenegraph.org/viewtopic.php?t=16592 may not be fully resolved 
yet.

Cheers,
Stuart
--
Stuart Mentzer
Objexx Engineering
/Office/  +1 781 455 1150 x11
/Mobile/ +1 781 708 3872

On 5/15/2017 7:58 AM, Mourad Boufarguine wrote:

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 CMAKE_VS_PLATFORM_TOOLSET variable 
will not be set, and this is what is causing the problem here.

Cheers,
Mourad



On Mon, May 15, 2017 at 1:23 PM, Robert Osfield <robert.osfi...@gmail.com 
<mailto:robert.osfi...@gmail.com>> wrote:

Hi Stuart,

On 15 May 2017 at 12:07, Stuart Mentzer <stuart_ment...@objexx.com 
<mailto:stuart_ment...@objexx.com>> wrote:
> https://cmake.org/cmake/help/v3.0/variable/CMAKE_VS_PLATFORM_TOOLSET.html 
<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 would
> happen here.
>
> What VC number is reported on your system?
>
> Visual C++ 2015 corresponds to MSVC14.

Looking at the CMake docs it would seem CMAKE_VS_PLATFORM_TOOLSET
should be defined, but given your error it would seem on your system
it's not.

Could you check whether CMAKE_VS_PLATFORM_TOOLSET is defined and what
it's value is?


> [Separate issue: curl 7.54.0 (latest) has a build error under VC++ 2015 
but
> the prev version builds OK]
>
> Is this a build error in curl, or the OSG plugin building against curl
> 7.54.0?
>
> It is in the curl build itself. Here is the bug report I filed:
> https://github.com/curl/curl/issues/1482 
<https://github.com/curl/curl/issues/1482>

OK, this isn't an OSG issue then so I can safely leave this to someone
else to resolve:-)

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org 
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
<http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org>




___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Stuart Mentzer]

Hi Robert,

On 5/15/2017 5:13 AM, Robert Osfield wrote:

Hi Stuart,

On 12 May 2017 at 14:32, Stuart Mentzer <stuart_ment...@objexx.com> 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 this is still OK when the
Collada plugin is in use.

I'm currently looking at the changes and the error report, trying to
make sense of what is the root of the issue and how to resolve it.
Unfortunately I haven't heard from Torben yet so don't yet know what
his thoughts are.  Form what I understand Torben introduced the
COLLADA_BOOST_BUILDNAME to cope with variations under Windows related
to the platform tools set, hence the introduction of the
CMAKE_VS_PLATFORM_TOOLSET in the lines like:


ELSEIF(MSVC14)
 SET(COLLADA_BUILDNAME "vc14")
 string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME
${CMAKE_VS_PLATFORM_TOOLSET})
ELSEIF(MSVC12)
 SET(COLLADA_BUILDNAME "vc12")
 string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME
${CMAKE_VS_PLATFORM_TOOLSET})
ELSEIF(MSVC11)
 SET(COLLADA_BUILDNAME "vc11")
 string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME
${CMAKE_VS_PLATFORM_TOOLSET})
ELSEIF(MSVC10)
 SET(COLLADA_BUILDNAME "vc10")
 string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME
${CMAKE_VS_PLATFORM_TOOLSET})
ELSEIF(MSVC90)
 SET(COLLADA_BUILDNAME "vc9")
 string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME
${CMAKE_VS_PLATFORM_TOOLSET})
ELSEIF(MSVC80)
 SET(COLLADA_BUILDNAME "vc8")
 string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME
${CMAKE_VS_PLATFORM_TOOLSET})
ELSE(APPLE)

CMaker docs for the CMAKE_VS_PLATFORM_TOOLSET} are:

 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 would
happen here.

What VC number is reported on your system?

Visual C++ 2015 corresponds to MSVC14.

[Separate issue: curl 7.54.0 (latest) has a build error under VC++ 2015 but
the prev version builds OK]

Is this a build error in curl, or the OSG plugin building against curl 7.54.0?

It is in the curl build itself. Here is the bug report I filed: 
https://github.com/curl/curl/issues/1482

Thanks,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Cheers,
Stuart
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Stuart Mentzer]

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:

 
https://github.com/openscenegraph/OpenSceneGraph/commit/67ef816da00441121f7b2cb606ee19bbb1f15e80

We could revert this but it'd break support for VS2017 binaries...  I
don't have any suggestions yet on what an appropriate fix might be.
I'm not a Windows dev so will need to defer resolution to those with
WIndows expertise.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Hi Robert,

Adding " around the 3rd and 4th args in the REPLACE lines did indeed eliminate 
the error. Torben should check that this is still OK when the Collada plugin is in 
use.

[Separate issue: curl 7.54.0 (latest) has a build error under VC++ 2015 but the 
prev version builds OK]

Cheers,
Stuart
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Stuart Mentzer]

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:

 
https://github.com/openscenegraph/OpenSceneGraph/commit/67ef816da00441121f7b2cb606ee19bbb1f15e80

We could revert this but it'd break support for VS2017 binaries...  I
don't have any suggestions yet on what an appropriate fix might be.
I'm not a Windows dev so will need to defer resolution to those with
WIndows expertise.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Windows 10 (64-bit), CMake 3.8.1, Visual C++ 2015.

My guess is that it just needs a fixup to deal with the case of NOT building 
the Collada plugin, when those strings are probably empty. I'll kick off a 
build with the quote-wrapping fix and let you know later but it is probably 
best to ask Torben to take a look.

Cheers,
Stuart
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Stuart Mentzer]

On 5/12/2017 4:50 AM, Robert Osfield wrote:

Hi Stuart,

On 12 May 2017 at 09:18, Stuart Mentzer <stuart_ment...@objexx.com> 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 have the REPLACE lines, so
I guess that is where the problem lies. The (first) offending line is:
string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME
${CMAKE_VS_PLATFORM_TOOLSET})
Since I am not building with the Collada plugin I assume one or both of the
last 2 arguments are blank, thus too few args. Probably wrapping them in "
would fix it but I haven't had a chance to try that yet. Maybe best to kick
this to the contributor of the revised FindCOLLADA.cmake.


Do you clean your CMakeCache.txt and run CMake from scratch when you
did your testing?  I am wondering if an new CMake variable is intended
to be set elsewhere in the OSG that isn't being set it your case.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Hi Robert,

I always build from scratch in an empty build directory.

Cheers,
Stuart

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Stuart Mentzer]

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 is:
string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME ${CMAKE_VS_PLATFORM_TOOLSET})
Since I am not building with the Collada plugin I assume one or both of the last 2 
arguments are blank, thus too few args. Probably wrapping them in " would fix 
it but I haven't had a chance to try that yet. Maybe best to kick this to the 
contributor of the revised FindCOLLADA.cmake.

Cheers,
Stuart

On 5/12/2017 3:56 AM, Robert Osfield wrote:

HI Stuart,

On 12 May 2017 at 02:04, Stuart Mentzer <osgfo...@tevs.eu> 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):
   CMakeLists.txt:743 (FIND_PACKAGE)

Details: Windows 10, CMake 3.8.1, Visual C++ 2015

Is this error due to recent changes in the OSG or an issue introduced
by CMake 3.8.1?

Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Stuart Mentzer]

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++ 2015

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70901#70901





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenSceneGraph master in prep for 3.5.6 dev release

[Stuart Mentzer]

Hi Robert,


robertosfield wrote:
> Hi Stuart,
> 
> On 28 March 2017 at 19:46, Stuart Mentzer <> wrote:
> 
> > osgWrappers/serializers/osgVolume/MultipassTechnique.cpp was added since my 
> > prior (successful) build with VC++ 2015 (at rev 6308b4). VC++ needs the 
> > definition of osg::Texture2D (and other types used in members) to 
> > instantiate MultipassTechnique.
> > 
> 
> That is a really useful clue.  My best guess is that we need to add an
> #include  to the MultipassTechnique header.
> 
> I have checked this change into OSG master.  Could you test it and let
> me know if it resolves the build errors?
> 
> Thanks,
> Robert.


The VC++ 2015 build now completes without error and seems fine with my 
application.

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70602#70602





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenSceneGraph master in prep for 3.5.6 dev release

[Stuart Mentzer]

robertosfield wrote:
> Hi Stuart,
> 
> I don't recall resent changes to the files mentioned in your compiler
> output, this makes a bit more difficult to point point what might have
> caused this problem.
> 
> When was the last time you build OSG master?  Was it with the same
> OS/Compiler set?  Did you come across problems then?
> 
> Robert.


Hi Robert,

osgWrappers/serializers/osgVolume/MultipassTechnique.cpp was added since my 
prior (successful) build with VC++ 2015 (at rev 6308b4). VC++ needs the 
definition of osg::Texture2D (and other types used in members) to instantiate 
MultipassTechnique.

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70591#70591





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenSceneGraph master in prep for 3.5.6 dev release

[Stuart Mentzer]

Hi Robert,

Getting an error with a VC++ 2015 64-bit build on Windows 10:

cd /d 
C:\Projects\OSG\OpenSceneGraph.VC.r\OSG\src\osgWrappers\serializers\osgVolume 
&& C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe/TP -D_CRT_SECURE_NO_DEPRECATE 
-D_SCL_SECURE_NO_WARNINGS -Dosgdb_serializers_osgvolume_EXPORTS 
-IC:\Projects\OSG\OpenSceneGraph\include 
-IC:\Projects\OSG\OpenSceneGraph.VC.r\OSG\include  /DWIN32 /D_WINDOWS /W3 /GR 
/EHsc /W4 /wd4589 /wd4706 /wd4127 /wd4100 /Zp16 /nologo /EHsc /DNOMINMAX 
/DNDEBUG /O2 /GS- /MD   
/FoCMakeFiles\osgdb_serializers_osgvolume.dir\MultipassTechnique.cpp.obj 
/FdCMakeFiles\osgdb_serializers_osgvolume.dir/ /FS -c 
C:\Projects\OSG\OpenSceneGraph\src\osgWrappers\serializers\osgVolume\MultipassTechnique.cpp

C:\Projects\OSG\OpenSceneGraph\include\osg/ref_ptr(41): error C2027: use of 
undefined type 'osg::Texture2D'
C:\Projects\OSG\OpenSceneGraph\include\osg/FrameBufferObject(264): note: see 
declaration of 'osg::Texture2D'
C:\Projects\OSG\OpenSceneGraph\include\osg/ref_ptr(41): note: while compiling 
class template member function 'osg::ref_ptr::~ref_ptr(void)'
C:\Projects\OSG\OpenSceneGraph\include\osgVolume/MultipassTechnique(116): note: 
see reference to function template instantiation 
'osg::ref_ptr::~ref_ptr(void)' being compiled
C:\Projects\OSG\OpenSceneGraph\include\osgVolume/MultipassTechnique(70): note: 
see reference to class template instantiation 'osg::ref_ptr' 
being compiled
C:\Projects\OSG\OpenSceneGraph\include\osg/ref_ptr(41): error C2227: left of 
'->unref' must point to class/struct/union/generic type
src\osgWrappers\serializers\osgVolume\CMakeFiles\osgdb_serializers_osgvolume.dir\build.make:352:
 recipe for target 
'src/osgWrappers/serializers/osgVolume/CMakeFiles/osgdb_serializers_osgvolume.dir/MultipassTechnique.cpp.obj'
 failed
make[2]: *** 
[src/osgWrappers/serializers/osgVolume/CMakeFiles/osgdb_serializers_osgvolume.dir/MultipassTechnique.cpp.obj]
 Error 2

I didn't have a chance to look into the code to debug it but looks like maybe a 
missing include.

Cheers,
Stuart[/code]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70576#70576





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenSceneGraph master in prep for 3.5.6 dev release

[Stuart Mentzer]

Hi Robert,


robertosfield wrote:
> HI Stuart,
> 
> On 27 March 2017 at 13:44, Stuart Mentzer <> wrote:
> 
> > With this fix OSG + osgQt master branches build and work fine for my 
> > application on Windows 10 with Visual C++ 2015 and Qt 5.8.0.
> > 
> 
> I haven't done any testing under Windows so can't comment on whether
> OSG master will building under Qt5.8.0+VS20015, I do these calls for
> testing to get feedback from the community on things like this - there
> is one of me and many different platforms so I have to rely on the
> community to cover the wide range of build combinations.
> 
> If there are reports of issues then I can help work to resolve them.


Just to clarify, since maybe you misread my comment as a question, I did the Qt 
5.8.0+VS2015 build with today's masters and I am reporting that all seems well.


robertosfield wrote:
> 
> 
> > I also built OSG with Visual C++ 2017 for kicks and it seemed to build 
> > cleanly but I didn't test it with my application because I need osgQt and 
> > that won't build with VC++ 2017 until Qt 5.9.0 comes out.
> > 
> 
> Was it a recent OSG master that you tested?


I did this VC++ 2017 build with master as of 2 days ago.

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70566#70566





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenSceneGraph master in prep for 3.5.6 dev release

[Stuart Mentzer]

Hi Robert,

With this fix OSG + osgQt master branches build and work fine for my 
application on Windows 10 with Visual C++ 2015 and Qt 5.8.0.

I also built OSG with Visual C++ 2017 for kicks and it seemed to build cleanly 
but I didn't test it with my application because I need osgQt and that won't 
build with VC++ 2017 until Qt 5.9.0 comes out.

I did no code migrations for 3.5.6 but if there are any notes on suggested 
migration that it would be great to get a link. I believe new approaches to Qt5 
integration are being worked on but I didn't look into that either.

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70557#70557





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Linux packaging: Qt 4 vs 5

[Stuart Mentzer]

The Fedora OSG packager added this comment to the Bugzilla entry:


> Having experimented a bit with Qt4/Qt5 builts, I found this won't be easily 
> achievable.
> 
> - OSG-3.4.0's qt-libs/plugins/binaries use non-qt-versioned file 
> names/SONAMEs. I.e. qt4 and qt5-compiled binaries will conflict at 
> runtime/installation time.
> 
> - Qt5-built OSG is slightly incompatible with Qt4-build versions of OSG-3.4.0.
> (Building against QT5 causes OSG to drop the osgdb_qfont.so plugin)
> 
> - OSG-3.4.0 monolytical [monolithic?] build system treats QT4 and QT5 as 
> mutually exclusive alternatives.
> 
> All in all, I don't see an easy way to implement parallel installation of 
> qt4-/qt5-build variants.


If these issues can't be finessed, separating just osgQt into Qt 4 and 5 
packages won't suffice: we'll need separate OSG builds, installation paths, and 
library naming. But maybe someone more familiar with Linux builds can see a 
simpler approach. Having both Qt 4 and 5 builds on Linux seems to have value 
but if that's not practical it might be time with OSG 3.6.0 to encourage Linux 
packagers to switch to Qt 5.

Stuart[/quote]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68162#68162





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Linux packaging: Qt 4 vs 5

[Stuart Mentzer]

On Fri, Jul 15, 2016 at 9:15 AM, Alberto Luaces  wrote:

I am able to run our OSG applications with Qt 5 on Windows and I'd
like to try it on Linux to see if we can transition off Qt 4. Would it
make sense to request OpenSceneGraph-qt5 packages be added by the main
distros? (I am assuming those are the only OSG packages with Qt
dependencies.) If so, how best to do that?

Personally I think that it would make sense.  You would usually file a
bug report against the OSG package.  For example, Debian has a
"wish-list" category for that kind of petitions.  You could also address
the maintainer personally.

The Fedora procedure would be to file a bug at https://bugzilla.redhat.com.
You can try to email openscenegraph-ow...@fedoraproject.org afterwards.

Done for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1357109

From https://packages.debian.org/experimental/openscenegraph-3.4 and 
https://www.archlinux.org/packages/community/x86_64/openscenegraph/ it looks 
like 3.4.0 is built against Qt5 in Debian and Arch, excluding building 
applications with Qt4, which isn't desirable either. Having distinct osgQt 4 
and 5 packages as Robert describes seems like the best way to encourage 
packagers to provide them both (even if most of the differences are in the 
examples).

François
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Stuart
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Linux packaging: Qt 4 vs 5

[Stuart Mentzer]

  
  
Hello,
The OpenSceneGraph-qt/-devel (OSG 3.4.0) packages on Fedora 24
  are built against Qt 4. I'm wondering if that is suggested by OSG
  (maybe due to the single thread restriction on Qt 5) or is the
  choice of the Fedora packager. 

I am able to run our OSG applications with Qt 5 on Windows and
  I'd like to try it on Linux to see if we can transition off Qt 4.
  Would it make sense to request OpenSceneGraph-qt5 packages be
  added by the main distros? (I am assuming those are the only OSG
  packages with Qt dependencies.) If so, how best to do that?

Thanks,
  Stuart
  
  

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Virtual base initialization issues

[Stuart Mentzer]

  
  
Hi Robert,
That is surprising and unfortunate -- in this instance VC++ is
  actually correct. If you know which compilers gave contradictory
  warnings I might be able to see if that has now been corrected. In
  any event, it seems better to have correct code give erroneous
  warnings than incorrect code that gives correct warnings.
I think there 2+ classes which aren't properly initializing the
  virtual bases, at least on compilers that handle virtual bases
  correctly. So there may be actual bugs, not just warnings. I am
  willing to pursue this if you would like me to.

Stuart
--
  
Stuart G Mentzer
Objexx Engineering
Office  1.781.455.1150 x11
Mobile 1.781.708.3872

  
On 6/30/2016 4:29 AM, Robert Osfield
  wrote:


  Hi Stuart,

This warning is a bit of pain.  Fix this warning and you generate a
warning with other compilers depending upon which compiler and warning
options enabled.  We had a discussion and attempted to fix some of
these warnings in the last dev release cycle.

Robert.

On 30 June 2016 at 06:08, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

  
Hello,

Visual C++ 2015 finds a problem (in current master) with the initialization
of virtual base classes in the constructors of the hierarchies including
Object, Callback, NodeCallback, GUIEventHandler, EventHandler,
CameraManipulator, StandardManipulator, and AnimationManagerBase.
Constructors are attempting to initialize virtual bases Object and Callback
from classes that are not the most-derived, concrete class so those
initializations are being ignored. It doesn't help (or look right) that
multiple levels in the hierarchy attempt (and fail) to initialize these
virtual bases.

An example of the reported warnings is:
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): warning
C4589: Constructor of abstract class 'osgGA::CameraManipulator' ignores
initializer for virtual base class 'osg::Object'
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): note:
virtual base classes are only initialized by the most-derived type
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25): warning
C4589: Constructor of abstract class 'osgGA::CameraManipulator' ignores
initializer for virtual base class 'osg::Callback'
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25): note:
virtual base classes are only initialized by the most-derived type

In some cases I see the most-derived classes also do the (correct) virtual
base initialization but it looks like at least these 2 are missing it:
BasicAnimationManager::BasicAnimationManager(const AnimationManagerBase& b,
const osg::CopyOp& copyop)
TimelineAnimationManager::TimelineAnimationManager(const
TimelineAnimationManager& nc,const osg::CopyOp& co)

I don't know enough of the internals to say if this could be causing
problems in practice but it would be good to fix this usage. I'm willing to
take a shot at it if that would be helpful.

Stuart


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


  
  ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



  

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Virtual base initialization issues

[Stuart Mentzer]

  
  
Hello,
Visual C++ 2015 finds a problem (in current master) with the
  initialization of virtual base classes in the constructors of the
  hierarchies including Object, Callback, NodeCallback,
  GUIEventHandler, EventHandler, CameraManipulator,
  StandardManipulator, and AnimationManagerBase. Constructors are
  attempting to initialize virtual bases Object and Callback from
  classes that are not the most-derived, concrete class so those
  initializations are being ignored. It doesn't help (or look right)
  that multiple levels in the hierarchy attempt (and fail) to
  initialize these virtual bases.
An example of the reported warnings is:
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24):
  warning C4589: Constructor of abstract class
  'osgGA::CameraManipulator' ignores initializer for virtual base
  class 'osg::Object'
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24):
  note: virtual base classes are only initialized by the
  most-derived type
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25):
  warning C4589: Constructor of abstract class
  'osgGA::CameraManipulator' ignores initializer for virtual base
  class 'osg::Callback'
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25):
  note: virtual base classes are only initialized by the
  most-derived type

In some cases I see the most-derived classes also do the
  (correct) virtual base initialization but it looks like at least
  these 2 are missing it:
  BasicAnimationManager::BasicAnimationManager(const
  AnimationManagerBase& b, const osg::CopyOp& copyop)
  TimelineAnimationManager::TimelineAnimationManager(const
  TimelineAnimationManager& nc,const osg::CopyOp& co)

I don't know enough of the internals to say if this could be
  causing problems in practice but it would be good to fix this
  usage. I'm willing to take a shot at it if that would be helpful.

Stuart
  
  

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

Hi Robert,

Here is what should be the final version of FindFreetype.cmake that is based on 
the now-accepted CMake patches. This supports the new freetype include path 
structure and fixes the failure to find the debug library on Windows due to its 
name having a 'd' suffix.

The only differences are wrt the license requirement when not bundled with 
CMake and the adjustments necessary to include CMake modules.

Once the patches are part of OSG's oldest supported CMake this 
FindFreetype.cmake can be dropped from OSG.

If you'd like me to post this to osg-submission just let me know.

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67722#67722




Attachments: 
http://forum.openscenegraph.org//files/findfreetype_213.7z


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

On 6/9/2016 9:15 AM, Robert Osfield wrote:

Hi Stuart,

On 9 June 2016 at 12:39, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

Robert, it occurs to me that you could just do a find_library for PNG and
then, if found, add the PNG lib to the freetype plugin libraries, even if
freetype didn't actually depend on PNG. Maybe that isn't super rigorous but
linking in a library that isn't needed should be harmless. This simpler task
I can do for the freetype plugin CMakeLists.txt file if you want.

I don't feel this is appropriate.  If someone cherry picked plugins
for release then could end up with problems if they didn't copy across
png as well even though it shouldn't be needed.

With CMake you can run build tests to test if certain capabilities
work or not and then toggle settings accordingly, perhaps this might
be useful on the FreeType front.  If not then have a CMake option for
the FreeType where you can add additional libraries or toggle on the
requirement for linking to PNG.  The later is the route I'd suggest
for now.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Good points, Robert. I'm not the one to do this fancier CMake setup.

Stuart
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

Robert, it occurs to me that you could just do a find_library for PNG and then, 
if found, add the PNG lib to the freetype plugin libraries, even if freetype 
didn't actually depend on PNG. Maybe that isn't super rigorous but linking in a 
library that isn't needed should be harmless. This simpler task I can do for 
the freetype plugin CMakeLists.txt file if you want.

Stuart

On 6/8/2016 1:42 AM, Stuart Mentzer wrote:

Hi Robert,

If we do this in FindFreetype.cmake it will prevent us from using CMake's 
version (once the patch goes in). So that means doing it in the CMakeLists.txt 
for the freetype plugin. Anyway, I don't know enough CMake to find another 
package's dependencies (something with pkg_config maybe?) but I'm sure someone 
here has done this before.

Stuart

On 6/6/2016 3:37 AM, Robert Osfield wrote:

Hi Stuart,

I believe it should be possible to have the FindFreetype.cmake detect
that PNG is used and create an additional libraries var or just add it
into FREETYPE_LIBRARIES var.  Have a look at how the other Free*.cmake
modules handle extra dependencies that need to be linked in.  If this
is done right it should be possible to have the OSG's freetype plugin
to work without any special manual settings to add the PNG dependency.

Robert.

On 5 June 2016 at 22:51, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

Hi Robert,

OK, I am testing a patched FindFreetype.cmake with OSG now. If that works
I'll submit it to CMake and to OSG. If it is better to post it to the
osg-submissions list rather than here I can do that but it is then separate
from the context of this discussion.

It doesn't seem practical for us to fix freetype but I'll file a suggestion
with them to reconsider this build approach. For now, with a wiki note on
refreshing the source, the only freetype improvement we can benefit from is
making osgPlugins/freetype/CMakeLists.txt able to add PNG_LIBRARY (or other
freetype optional libs?) to the target libraries if needed. I don't know
enough CMake yet to do that automatically and adding a variable to pass to
the cmake call seems like cruft. If OSG has no benefit from PNG support in
freetype then a note not to enable it is probably the way to go.

Cheers,
Stuart


On 6/5/2016 7:41 AM, Robert Osfield wrote:

HI Stuart,

It sounds like taking the CMake FindFreetype.cmake modifying to work
and then getting this checked over by the cmake community as being
suitable for them to merge and then sending the final rev along to me
to merge would enable us to roll out the improved support prior to the
next CMake release.  If the CMake release is made before we push out
3.6 then we wouldn't need to add it locally.

With the freetype wiring to PNG+ZLIB, this sounds like the could
improve things with their own source/build system.  I don't know
freetype well enough to know how easy it would be to fix things to
make it easier to switch.  This type of issue is why the OSG has
plugins and NodeKits - the core libraries are kept with minimal
dependencies, this way the dependency chain doesn't pollute anything
more than it needs to.

Robert.



On 5 June 2016 at 02:35, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

Hi Robert,

I have asked the CMake community about updating their FindFreetype.cmake
to
support Windows debug library naming and I will follow up to try and get
that fixed in upcoming releases. I was pointed to how they do it
correctly
for zlib so I could make a variant of their FindFreetype.cmake for OSG to
use until their fix is released. This would retain their support for the
old
and new include structure. If you'd like me to submit that let me know.

Wrt the PNG on/off issue, I now understand the approach they use. The
upshot
is that as long as you refresh the freetype source tree you are building
with from the original code before each build you can switch PNG support
on
or off in the cmake command with -DWITH_PNG=ON or OFF and without
manually
editing ftoption.h. (Same holds for ZLIB support.) The reason is that the
build goes in and modifies ftoption.h in the source tree (as well as
making
a copy in the build tree) and the modification only uncomments those
defines, so you can't build with PNG enabled and then PNG disabled
without
refreshing the source first. This is an unfortunate approach but that is
what we are stuck with. Most builders don't switch the PNG or ZLIB
support
on and off so this probably doesn't often trip people up. The best we can
probably do is add a note on an appropriate wiki page. I added this
refresh
step to my build scripts.

Stuart

On 6/4/2016 3:36 PM, Robert Osfield wrote:

Hi Stuart,

It sounds like the version of Freestyle is broken or it requires a tweak
to
configuration. Have you approached the freetype community about these
issues.

The debug vs release issue is something that would be worth raising with
the
cake community as it sounds like a revision to their Findfreetype.cmake.

Robert

On 3 Jun 2016 11:24 p.m., "Stuar

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

Hi Robert,

If you don't end up making CMake 2.8 the min version then we could just bring 
select_library_configurations (with a different name) into FindFreetype as a 
temporary work-around. It is not much code.

Stuart

On 6/8/2016 11:19 AM, Robert Osfield wrote:

Hi Stuart,

On 8 June 2016 at 16:11, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

Hi Robert,

I find a reference to SelectLibraryConfigurations in CMake 2.8 but not 2.6.
I don't know what the OSG min CMake version is.

In the OpenSceneGraph/CMakeLists.txt we have:

IF(WIN32)
 CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
ELSE(WIN32)
 IF(APPLE)
 CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
 ELSE(APPLE)
 CMAKE_MINIMUM_REQUIRED(VERSION 2.4.4 FATAL_ERROR)
 ENDIF(APPLE)
ENDIF(WIN32)


Which means 2.4.4 is the minimum, but.. this wasn't written when we
first introduced CMake as a build system for the OSG. Whether we can
set 2.8 as a minimum now is something that is different to know
without having the whole community chip in.  I'll start a separate
thread for this calling for feedback.


For freetype's PNG dependency I don't know how to do that automatically. Is
there someone with good CMake chops we could ask for help? I'm kind of
swamped so it could be a while until I can devote some time to figuring this
out.

I'll have to pass on this as I've got a bucket load of other work to
get on with.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

Hi Robert,

I find a reference to SelectLibraryConfigurations in CMake 2.8 but not 2.6. I 
don't know what the OSG min CMake version is.

For freetype's PNG dependency I don't know how to do that automatically. Is 
there someone with good CMake chops we could ask for help? I'm kind of swamped 
so it could be a while until I can devote some time to figuring this out.

Stuart

On 6/8/2016 11:01 AM, Robert Osfield wrote:

Hi Stuart,

On 8 June 2016 at 15:54, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

Hi Robert,

I think the call to select_library_configurations might already be doing
what you are after but I'm no CMake expert. The code is in CMake's
SelectLibraryConfigurations module.

Learn something new every day :-)

Do you have an idea which version of CMake this feature was added? My
concern is that is we make one of out find modules only work with
recent versions of CMake then we'll break the build for those stuck
with older versions of CMake.

What about the PNG dependency, have you resolved a way to detect this
and add it in?

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

Hi Robert,

I think the call to select_library_configurations might already be doing what 
you are after but I'm no CMake expert. The code is in CMake's 
SelectLibraryConfigurations module.

If not, I don't see why CMake wouldn't accept this as part of a (revised) 
patch, with the goal that we can move to the stock FindFreetype module 
eventually.

Stuart

On 6/8/2016 10:36 AM, Robert Osfield wrote:

Hi Stuart,

I have just had a quick look at the FindFreetype.cmake.  Looks
sensible but it looks to miss an opportunity to automatically set up
the debug library.  It's possible in CMake to set the
FREETYPE_LIBRARIES var to contain both the release and debug builds.
It should also be possible to add the PNG library dependency in here
as well if it's required.

The OpenSceneGraph/CMakeModules/Find3rdPartyDependencies.cmake set it up thus:

   SET(${DEPNAME}_LIBRARIES debug ${${DEPNAME}_LIBRARY_DEBUG}
optimized ${${DEPNAME}_LIBRARY} )

Which can be simplified for Freetype:


   SET(FREETYPE_LIBRARIES debug FREETYPE_LIBRARY_DEBUG} optimized
FREETYPE_LIBRARY} )

One would typically set the _DEBUG up to reference the non debug
library when the debug library isn't available.

I could potentially check what you have into the OSG and then modify
it or you could modify make sure it works on your system then submit
for final merge.

Robert.

On 8 June 2016 at 05:56, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

Hi Robert,

Sorry for the delay -- it took a few go-rounds to get this in the shape that
CMake folks wanted it.

This is what I have submitted to CMake with a few necessary tweaks:
. Full copyright text that they require when not shipped with CMake
. include statement tweak to work when not within CMake

If you want this to go the osg-submissions let me know.

This missed the CMake 3.6 freeze so it probably won't be released for a bit
but this version should hold us until then. I'll try to remember to check
for the patch in future CMake releases and let you know when the custom
version is no longer required.

Wrt the freetype build, it seems they have already eliminated the build
modifying headers in the source tree (or the need to copy the changes into
it) and I confirmed that with freetype 2.6.3. So as long as we assume OSG
3rd party lib builders are using fresh lib versions we don't need a wiki
note about that gotcha.

Cheers,
Stuart

On 6/5/2016 7:41 AM, Robert Osfield wrote:

HI Stuart,

It sounds like taking the CMake FindFreetype.cmake modifying to work
and then getting this checked over by the cmake community as being
suitable for them to merge and then sending the final rev along to me
to merge would enable us to roll out the improved support prior to the
next CMake release.  If the CMake release is made before we push out
3.6 then we wouldn't need to add it locally.

With the freetype wiring to PNG+ZLIB, this sounds like the could
improve things with their own source/build system.  I don't know
freetype well enough to know how easy it would be to fix things to
make it easier to switch.  This type of issue is why the OSG has
plugins and NodeKits - the core libraries are kept with minimal
dependencies, this way the dependency chain doesn't pollute anything
more than it needs to.

Robert.



On 5 June 2016 at 02:35, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

Hi Robert,

I have asked the CMake community about updating their FindFreetype.cmake
to
support Windows debug library naming and I will follow up to try and get
that fixed in upcoming releases. I was pointed to how they do it
correctly
for zlib so I could make a variant of their FindFreetype.cmake for OSG to
use until their fix is released. This would retain their support for the
old
and new include structure. If you'd like me to submit that let me know.

Wrt the PNG on/off issue, I now understand the approach they use. The
upshot
is that as long as you refresh the freetype source tree you are building
with from the original code before each build you can switch PNG support
on
or off in the cmake command with -DWITH_PNG=ON or OFF and without
manually
editing ftoption.h. (Same holds for ZLIB support.) The reason is that the
build goes in and modifies ftoption.h in the source tree (as well as
making
a copy in the build tree) and the modification only uncomments those
defines, so you can't build with PNG enabled and then PNG disabled
without
refreshing the source first. This is an unfortunate approach but that is
what we are stuck with. Most builders don't switch the PNG or ZLIB
support
on and off so this probably doesn't often trip people up. The best we can
probably do is add a note on an appropriate wiki page. I added this
refresh
step to my build scripts.

Stuart

On 6/4/2016 3:36 PM, Robert Osfield wrote:

Hi Stuart,

It sounds like the version of Freestyle is broken or it requires a tweak
to
configuration. Have you approached the freetype community about these
issues.

The debug vs release issue is somethin

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

To clarify, the issues arise not in building freetype but in building the 
freetype plugin. The OSG FindFreetype.cmake module has two issues:

1. The debug library is named freetyped.lib (not freetype.lib) and the NAMES 
variable doesn't have freetyped so it isn't found in a debug build. (This is 
also a flaw in CMake's FindFreetype module and I have submitted a patch.)

2. The include directory structure in freetype 2.6.3 is different than what 
FindFreetype.cmake expects.

If you are getting the freetype plugin built with freetype 2.6.3 or in a debug 
build using the stock OSG FindFreetype.cmake then that is a mystery. You could 
work around the first issue by setting the library variable externally I guess.

I have not looked at Björn's scripts -- I developed my own that handle the 
whole build also.

Stuart

On 6/6/2016 4:33 AM, Carl-Gustaf Kung wrote:

I don't know if I missunderstand your original post somehow, but I did build 
freetype twice in last few days with no issues whatsoever. I am on windows 10 
64-bit and I have built it with VS2015 Community Edition, both debug and 
release libs.

If you use cmake file that comes with freetype from git, just comment out check 
for mingw and shared libs:


#if (WIN32 AND NOT MINGW AND BUILD_SHARED_LIBS)
#  message(FATAL_ERROR "Building shared libraries on Windows needs MinGW")
#endif ()

If you use Björn's cmake scripts, you have to do nothing.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67437#67437





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

Hi Robert,

If we do this in FindFreetype.cmake it will prevent us from using CMake's 
version (once the patch goes in). So that means doing it in the CMakeLists.txt 
for the freetype plugin. Anyway, I don't know enough CMake to find another 
package's dependencies (something with pkg_config maybe?) but I'm sure someone 
here has done this before.

Stuart

On 6/6/2016 3:37 AM, Robert Osfield wrote:

Hi Stuart,

I believe it should be possible to have the FindFreetype.cmake detect
that PNG is used and create an additional libraries var or just add it
into FREETYPE_LIBRARIES var.  Have a look at how the other Free*.cmake
modules handle extra dependencies that need to be linked in.  If this
is done right it should be possible to have the OSG's freetype plugin
to work without any special manual settings to add the PNG dependency.

Robert.

On 5 June 2016 at 22:51, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

Hi Robert,

OK, I am testing a patched FindFreetype.cmake with OSG now. If that works
I'll submit it to CMake and to OSG. If it is better to post it to the
osg-submissions list rather than here I can do that but it is then separate
from the context of this discussion.

It doesn't seem practical for us to fix freetype but I'll file a suggestion
with them to reconsider this build approach. For now, with a wiki note on
refreshing the source, the only freetype improvement we can benefit from is
making osgPlugins/freetype/CMakeLists.txt able to add PNG_LIBRARY (or other
freetype optional libs?) to the target libraries if needed. I don't know
enough CMake yet to do that automatically and adding a variable to pass to
the cmake call seems like cruft. If OSG has no benefit from PNG support in
freetype then a note not to enable it is probably the way to go.

Cheers,
Stuart


On 6/5/2016 7:41 AM, Robert Osfield wrote:

HI Stuart,

It sounds like taking the CMake FindFreetype.cmake modifying to work
and then getting this checked over by the cmake community as being
suitable for them to merge and then sending the final rev along to me
to merge would enable us to roll out the improved support prior to the
next CMake release.  If the CMake release is made before we push out
3.6 then we wouldn't need to add it locally.

With the freetype wiring to PNG+ZLIB, this sounds like the could
improve things with their own source/build system.  I don't know
freetype well enough to know how easy it would be to fix things to
make it easier to switch.  This type of issue is why the OSG has
plugins and NodeKits - the core libraries are kept with minimal
dependencies, this way the dependency chain doesn't pollute anything
more than it needs to.

Robert.



On 5 June 2016 at 02:35, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

Hi Robert,

I have asked the CMake community about updating their FindFreetype.cmake
to
support Windows debug library naming and I will follow up to try and get
that fixed in upcoming releases. I was pointed to how they do it
correctly
for zlib so I could make a variant of their FindFreetype.cmake for OSG to
use until their fix is released. This would retain their support for the
old
and new include structure. If you'd like me to submit that let me know.

Wrt the PNG on/off issue, I now understand the approach they use. The
upshot
is that as long as you refresh the freetype source tree you are building
with from the original code before each build you can switch PNG support
on
or off in the cmake command with -DWITH_PNG=ON or OFF and without
manually
editing ftoption.h. (Same holds for ZLIB support.) The reason is that the
build goes in and modifies ftoption.h in the source tree (as well as
making
a copy in the build tree) and the modification only uncomments those
defines, so you can't build with PNG enabled and then PNG disabled
without
refreshing the source first. This is an unfortunate approach but that is
what we are stuck with. Most builders don't switch the PNG or ZLIB
support
on and off so this probably doesn't often trip people up. The best we can
probably do is add a note on an appropriate wiki page. I added this
refresh
step to my build scripts.

Stuart

On 6/4/2016 3:36 PM, Robert Osfield wrote:

Hi Stuart,

It sounds like the version of Freestyle is broken or it requires a tweak
to
configuration. Have you approached the freetype community about these
issues.

The debug vs release issue is something that would be worth raising with
the
cake community as it sounds like a revision to their Findfreetype.cmake.

Robert

On 3 Jun 2016 11:24 p.m., "Stuart Mentzer" <osgfo...@tevs.eu> wrote:

Hi Robert,

Here's what I found doing release and debug builds from yersterday's git
master code with Visual C++ 2015:

freetype even using -DWITH_PNG=OFF will still try to include png.h and
for
some reason requires ftoption.h (both copies) to be modified (or
overridden)
to comment out the line:
#define FT_CONFIG_OPTION_USE_PNG
This is unfortunate and actually makes it easier to bui

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

Hi Robert,

Sorry for the delay -- it took a few go-rounds to get this in the shape that 
CMake folks wanted it.

This is what I have submitted to CMake with a few necessary tweaks:
. Full copyright text that they require when not shipped with CMake
. include statement tweak to work when not within CMake

If you want this to go the osg-submissions let me know.

This missed the CMake 3.6 freeze so it probably won't be released for a bit but 
this version should hold us until then. I'll try to remember to check for the 
patch in future CMake releases and let you know when the custom version is no 
longer required.

Wrt the freetype build, it seems they have already eliminated the build 
modifying headers in the source tree (or the need to copy the changes into it) 
and I confirmed that with freetype 2.6.3. So as long as we assume OSG 3rd party 
lib builders are using fresh lib versions we don't need a wiki note about that 
gotcha.

Cheers,
Stuart

On 6/5/2016 7:41 AM, Robert Osfield wrote:

HI Stuart,

It sounds like taking the CMake FindFreetype.cmake modifying to work
and then getting this checked over by the cmake community as being
suitable for them to merge and then sending the final rev along to me
to merge would enable us to roll out the improved support prior to the
next CMake release.  If the CMake release is made before we push out
3.6 then we wouldn't need to add it locally.

With the freetype wiring to PNG+ZLIB, this sounds like the could
improve things with their own source/build system.  I don't know
freetype well enough to know how easy it would be to fix things to
make it easier to switch.  This type of issue is why the OSG has
plugins and NodeKits - the core libraries are kept with minimal
dependencies, this way the dependency chain doesn't pollute anything
more than it needs to.

Robert.



On 5 June 2016 at 02:35, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

Hi Robert,

I have asked the CMake community about updating their FindFreetype.cmake to
support Windows debug library naming and I will follow up to try and get
that fixed in upcoming releases. I was pointed to how they do it correctly
for zlib so I could make a variant of their FindFreetype.cmake for OSG to
use until their fix is released. This would retain their support for the old
and new include structure. If you'd like me to submit that let me know.

Wrt the PNG on/off issue, I now understand the approach they use. The upshot
is that as long as you refresh the freetype source tree you are building
with from the original code before each build you can switch PNG support on
or off in the cmake command with -DWITH_PNG=ON or OFF and without manually
editing ftoption.h. (Same holds for ZLIB support.) The reason is that the
build goes in and modifies ftoption.h in the source tree (as well as making
a copy in the build tree) and the modification only uncomments those
defines, so you can't build with PNG enabled and then PNG disabled without
refreshing the source first. This is an unfortunate approach but that is
what we are stuck with. Most builders don't switch the PNG or ZLIB support
on and off so this probably doesn't often trip people up. The best we can
probably do is add a note on an appropriate wiki page. I added this refresh
step to my build scripts.

Stuart

On 6/4/2016 3:36 PM, Robert Osfield wrote:

Hi Stuart,

It sounds like the version of Freestyle is broken or it requires a tweak to
configuration. Have you approached the freetype community about these
issues.

The debug vs release issue is something that would be worth raising with the
cake community as it sounds like a revision to their Findfreetype.cmake.

Robert

On 3 Jun 2016 11:24 p.m., "Stuart Mentzer" <osgfo...@tevs.eu> wrote:

Hi Robert,

Here's what I found doing release and debug builds from yersterday's git
master code with Visual C++ 2015:

freetype even using -DWITH_PNG=OFF will still try to include png.h and for
some reason requires ftoption.h (both copies) to be modified (or overridden)
to comment out the line:
#define FT_CONFIG_OPTION_USE_PNG
This is unfortunate and actually makes it easier to build freetype with
PNG support. With the freetype mods OSG builds including the freetype
plugin. Configuring freetype with or without PNG support is up to the
builder but it would be good if the CMakeLists.txt could handle both
situations without needing changes like I made.

The freetype build headers under include\freetype2\freetype even though
freetype doesn't use that freetype2 layer anymore. Not a big deal since OSG
doesn't really need to ship with freetype or other 3rd party lib headers.

The debug build is able to build freetype with the same mods but the OSG
build doesn't find it:
-- Could NOT find Freetype (missing:  FREETYPE_LIBRARY) (found version
"2.6.3")
which I assume is due to not looking for the name freetyped, as I found
with my OSG 3.4.0 build. So the OSG build can complete but it won't build
the freetyp

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

Hi Robert,

OK, I am testing a patched FindFreetype.cmake with OSG now. If that works I'll 
submit it to CMake and to OSG. If it is better to post it to the 
osg-submissions list rather than here I can do that but it is then separate 
from the context of this discussion.

It doesn't seem practical for us to fix freetype but I'll file a suggestion 
with them to reconsider this build approach. For now, with a wiki note on 
refreshing the source, the only freetype improvement we can benefit from is 
making osgPlugins/freetype/CMakeLists.txt able to add PNG_LIBRARY (or other 
freetype optional libs?) to the target libraries if needed. I don't know enough 
CMake yet to do that automatically and adding a variable to pass to the cmake 
call seems like cruft. If OSG has no benefit from PNG support in freetype then 
a note not to enable it is probably the way to go.

Cheers,
Stuart

On 6/5/2016 7:41 AM, Robert Osfield wrote:

HI Stuart,

It sounds like taking the CMake FindFreetype.cmake modifying to work
and then getting this checked over by the cmake community as being
suitable for them to merge and then sending the final rev along to me
to merge would enable us to roll out the improved support prior to the
next CMake release.  If the CMake release is made before we push out
3.6 then we wouldn't need to add it locally.

With the freetype wiring to PNG+ZLIB, this sounds like the could
improve things with their own source/build system.  I don't know
freetype well enough to know how easy it would be to fix things to
make it easier to switch.  This type of issue is why the OSG has
plugins and NodeKits - the core libraries are kept with minimal
dependencies, this way the dependency chain doesn't pollute anything
more than it needs to.

Robert.



On 5 June 2016 at 02:35, Stuart Mentzer <stuart_ment...@objexx.com> wrote:

Hi Robert,

I have asked the CMake community about updating their FindFreetype.cmake to
support Windows debug library naming and I will follow up to try and get
that fixed in upcoming releases. I was pointed to how they do it correctly
for zlib so I could make a variant of their FindFreetype.cmake for OSG to
use until their fix is released. This would retain their support for the old
and new include structure. If you'd like me to submit that let me know.

Wrt the PNG on/off issue, I now understand the approach they use. The upshot
is that as long as you refresh the freetype source tree you are building
with from the original code before each build you can switch PNG support on
or off in the cmake command with -DWITH_PNG=ON or OFF and without manually
editing ftoption.h. (Same holds for ZLIB support.) The reason is that the
build goes in and modifies ftoption.h in the source tree (as well as making
a copy in the build tree) and the modification only uncomments those
defines, so you can't build with PNG enabled and then PNG disabled without
refreshing the source first. This is an unfortunate approach but that is
what we are stuck with. Most builders don't switch the PNG or ZLIB support
on and off so this probably doesn't often trip people up. The best we can
probably do is add a note on an appropriate wiki page. I added this refresh
step to my build scripts.

Stuart

On 6/4/2016 3:36 PM, Robert Osfield wrote:

Hi Stuart,

It sounds like the version of Freestyle is broken or it requires a tweak to
configuration. Have you approached the freetype community about these
issues.

The debug vs release issue is something that would be worth raising with the
cake community as it sounds like a revision to their Findfreetype.cmake.

Robert

On 3 Jun 2016 11:24 p.m., "Stuart Mentzer" <osgfo...@tevs.eu> wrote:

Hi Robert,

Here's what I found doing release and debug builds from yersterday's git
master code with Visual C++ 2015:

freetype even using -DWITH_PNG=OFF will still try to include png.h and for
some reason requires ftoption.h (both copies) to be modified (or overridden)
to comment out the line:
#define FT_CONFIG_OPTION_USE_PNG
This is unfortunate and actually makes it easier to build freetype with
PNG support. With the freetype mods OSG builds including the freetype
plugin. Configuring freetype with or without PNG support is up to the
builder but it would be good if the CMakeLists.txt could handle both
situations without needing changes like I made.

The freetype build headers under include\freetype2\freetype even though
freetype doesn't use that freetype2 layer anymore. Not a big deal since OSG
doesn't really need to ship with freetype or other 3rd party lib headers.

The debug build is able to build freetype with the same mods but the OSG
build doesn't find it:
-- Could NOT find Freetype (missing:  FREETYPE_LIBRARY) (found version
"2.6.3")
which I assume is due to not looking for the name freetyped, as I found
with my OSG 3.4.0 build. So the OSG build can complete but it won't build
the freetype plugin.

The debug build fails at "Installing the project...&q

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

  
  
Hi Robert,
I have asked the CMake community about updating their
  FindFreetype.cmake to support Windows debug library naming and I
  will follow up to try and get that fixed in upcoming releases. I
  was pointed to how they do it correctly for zlib so I could make a
  variant of their FindFreetype.cmake for OSG to use until their fix
  is released. This would retain their support for the old and new
  include structure. If you'd like me to submit that let me know.

Wrt the PNG on/off issue, I now understand the approach they use.
  The upshot is that as long as you refresh the freetype source tree
  you are building with from the original code before each build you
  can switch PNG support on or off in the cmake command with
  -DWITH_PNG=ON or OFF and without manually editing ftoption.h.
  (Same holds for ZLIB support.) The reason is that the build goes
  in and modifies ftoption.h in the source tree (as well as making a
  copy in the build tree) and the modification only uncomments those
  defines, so you can't build with PNG enabled and then PNG disabled
  without refreshing the source first. This is an unfortunate
  approach but that is what we are stuck with. Most builders don't
  switch the PNG or ZLIB support on and off so this probably doesn't
  often trip people up. The best we can probably do is add a note on
  an appropriate wiki page. I added this refresh step to my build
  scripts.

Stuart

On 6/4/2016 3:36 PM, Robert Osfield
  wrote:


  Hi Stuart,
  It sounds like the version of Freestyle is broken or
it requires a tweak to configuration. Have you approached the
freetype community about these issues.
  The debug vs release issue is something that would be
worth raising with the cake community as it sounds like a
revision to their Findfreetype.cmake.
  Robert 
  On 3 Jun 2016 11:24 p.m., "Stuart
    Mentzer" <osgfo...@tevs.eu> wrote:
Hi Robert,
  
  Here's what I found doing release and debug builds from
  yersterday's git master code with Visual C++ 2015:
  
  freetype even using -DWITH_PNG=OFF will still try to include
  png.h and for some reason requires ftoption.h (both copies) to
  be modified (or overridden) to comment out the line:
  #define FT_CONFIG_OPTION_USE_PNG
  This is unfortunate and actually makes it easier to build
  freetype with PNG support. With the freetype mods OSG builds
  including the freetype plugin. Configuring freetype with or
  without PNG support is up to the builder but it would be good
  if the CMakeLists.txt could handle both situations without
  needing changes like I made.
  
  The freetype build headers under include\freetype2\freetype
  even though freetype doesn't use that freetype2 layer anymore.
  Not a big deal since OSG doesn't really need to ship with
  freetype or other 3rd party lib headers.
  
  The debug build is able to build freetype with the same mods
  but the OSG build doesn't find it:
  -- Could NOT find Freetype (missing:  FREETYPE_LIBRARY) (found
  version "2.6.3")
  which I assume is due to not looking for the name freetyped,
  as I found with my OSG 3.4.0 build. So the OSG build can
  complete but it won't build the freetype plugin.
  
  The debug build fails at "Installing the project..." because
  it appears something is wrong with the new pdb installation
  support:
  -- Installing: C:/OSG.VC.xd/bin/osgd.dll
  CMake Error at src/osg/cmake_install.cmake:39 (file):
    file INSTALL cannot find
    "C:/Projects/OSG/VC.xd/OSG/src/osg/PREFIX-NOTFOUNDosgd.pdb".
  Call Stack (most recent call first):
    src/cmake_install.cmake:33 (include)
    cmake_install.cmake:100 (include)
  The osgd.pdb file is present and next to osgd.dll as expected.
  
  I see that others are reporting success with the Visual C++
  2015 build but I don't know how they are addressing the
  freetype PNG issues or if they tried the debug build yet. It
  looks like there are still some issues but maybe they will
  offer some input here. I'm happy to make another pass if that
  helps.
  
  Stuart
  
  --
  Read this topic online here:
  http://forum.openscenegraph.org/viewtopic.php?p=67406#67406
  
  
  
  
  
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
  http://l

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

Hi Robert,

Here's what I found doing release and debug builds from yersterday's git master 
code with Visual C++ 2015:

freetype even using -DWITH_PNG=OFF will still try to include png.h and for some 
reason requires ftoption.h (both copies) to be modified (or overridden) to 
comment out the line:
#define FT_CONFIG_OPTION_USE_PNG
This is unfortunate and actually makes it easier to build freetype with PNG 
support. With the freetype mods OSG builds including the freetype plugin. 
Configuring freetype with or without PNG support is up to the builder but it 
would be good if the CMakeLists.txt could handle both situations without 
needing changes like I made.

The freetype build headers under include\freetype2\freetype even though 
freetype doesn't use that freetype2 layer anymore. Not a big deal since OSG 
doesn't really need to ship with freetype or other 3rd party lib headers.

The debug build is able to build freetype with the same mods but the OSG build 
doesn't find it:
-- Could NOT find Freetype (missing:  FREETYPE_LIBRARY) (found version "2.6.3")
which I assume is due to not looking for the name freetyped, as I found with my 
OSG 3.4.0 build. So the OSG build can complete but it won't build the freetype 
plugin.

The debug build fails at "Installing the project..." because it appears 
something is wrong with the new pdb installation support:
-- Installing: C:/OSG.VC.xd/bin/osgd.dll
CMake Error at src/osg/cmake_install.cmake:39 (file):
  file INSTALL cannot find
  "C:/Projects/OSG/VC.xd/OSG/src/osg/PREFIX-NOTFOUNDosgd.pdb".
Call Stack (most recent call first):
  src/cmake_install.cmake:33 (include)
  cmake_install.cmake:100 (include)
The osgd.pdb file is present and next to osgd.dll as expected.

I see that others are reporting success with the Visual C++ 2015 build but I 
don't know how they are addressing the freetype PNG issues or if they tried the 
debug build yet. It looks like there are still some issues but maybe they will 
offer some input here. I'm happy to make another pass if that helps.

Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67406#67406





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

Hi Robert,

This is a bit of a head-scratcher but even when building freetype ostensibly 
without PNG support  (-DWITH_PNG=OFF) I am still getting those unresolved png 
errors. It seems to trace back to the
#define FT_CONFIG_OPTION_USE_PNG
in ftoption.h that isn't commented out in the configured/build when PNG support 
is disabled. I'm not sure what is different on Linux builds that avoids this. I 
can look into this further but maybe someone here knows what the story is. I'm 
sure we don't want to require freetype code to be hacked to build OSG.

I don't see a variable in CMake's FindFreetype.cmake for additional libraries 
but it is aimed at finding freetype so that isn't surprising. My addition for 
the PNG lib was in:
SET(TARGET_LIBRARIES_VARS FREETYPE_LIBRARY PNG_LIBRARY )
in the freetype CMakeLists.txt so that is probably where we'd need to add 
flexibility for PNG and that doesn't preclude use of CMake's FindFreetype.cmake.

I hit another issue: If I put 3rdparty\include in the VC++ INCLUDE env var and 
it has the unistd.h from giflib that breaks the build. Easy enough to fix by 
leaving that header out but I'm wondering if it is standard practice to put 
3rdparty\include on the include search path. I didn't need it before but when I 
build freetype using -DWITH_PNG=OFF it still wants to include png.h (maybe 
another symptom of the first problem) so I tried to get beyond that by adding 
it to the include search path.

I'll dig further and see what I can find out...

Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67365#67365





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

robertosfield wrote:
> Could you please try a build with the latest that I've checked in and
> see what happens.


Trying with Visual C++ 2015...

I've been enabling PNG support in my freetype lib build (-DWITH_PNG=ON) and 
this causes unresolved png symbols when linking osgdb_freetype.dll since I'm 
enabling PNG support :

Code:
[ 94%] Linking CXX shared module osgdb_freetype.dll
freetype.lib(sfnt.c.obj) : error LNK2019: unresolved external symbol 
png_create_read_struct referenced in function Load_SBit_Png
freetype.lib(sfnt.c.obj) : error LNK2019: unresolved external symbol 
png_set_longjmp_fn referenced in function Load_SBit_Png
...
osgdb_freetype.dll : fatal error LNK1120: 23 unresolved externals



This is why I made that PNG change in my submission code. I don't know if we 
want/need to support PNG in freetype for OSG purposes but for now I'll try 
again with it disabled and let you know what happens.

BTW I also see a lot of base class initialization warnings:


Code:
C:\Projects\OSG\OpenSceneGraph\include\osg/OperationThread(80): warning C4589: 
Constructor of abstract class 'osg::Operation' ignores initializer for virtual 
base class 'osg::Referenced'
C:\Projects\OSG\OpenSceneGraph\include\osg/OperationThread(80): note: virtual 
base classes are only initialized by the most-derived type
C:\Projects\OSG\OpenSceneGraph\include\osg/OperationThread(84): warning C4589: 
Constructor of abstract class 'osg::Operation' ignores initializer for virtual 
base class 'osg::Referenced'
C:\Projects\OSG\OpenSceneGraph\include\osg/OperationThread(84): note: virtual 
base classes are only initialized by the most-derived type



There were other warnings that may be meaningful when I built 3.4.0. If it 
would be helpful to work towards reducing them I'm willing to give it some time.

Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67347#67347





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

  
  
Hi Robert,
While trying to get past build problems I did try using CMake's
  FindFreetype.cmake and it didn't work so I suspect you are correct
  that some other changes will be required. It does look like the
  CMake version is at least attempting to cover the various freetype
  layouts so it could eliminate an OSG maintenance burden. But its
  find_library doesn't have freetyped so I don't know if it solves
  the debug build issue unless we can do it by setting
  FREETYPE_LIBRARY.

Stuart
  
On 6/1/2016 11:05 AM, Robert Osfield
  wrote:


  Hi Stuart,

I have now checked in my changes to build the OSG using CMake's
FindFreetype.cmake rather than the OSG's native one, I deleted the
later as well as change the src/osgPlugins/freetype/CmakeListst.txt.
I have tested this under Kubuntu 16.04 so far.

After checking the changes in I am now starting to think that using
the standard Windows 3rd party depdencies package and the associated
Find3rdPartyDependencies.cmake might not set up the variables in the
same way as CMake's FindFreetype.cmake so could lead to problems.  In
particular I don't think the FREETYPE_LIBRARIES var usage that I've
introduced will work with the Find3rdPartyDependencies.cmake that will
be just setting the FREETYPE_LIBRARY var.

I think Find3rdPartyDependencies.cmake should be creating a
FREETYPE_LIBRARIES var as well, but am not a CMake guru so will need
to look up the rules for doing this.

Robert.

On 1 June 2016 at 15:23, Robert Osfield <robert.osfi...@gmail.com> wrote:

  
Hi Stuart,

Thanks for the modified file.  I've just reviewed this, as is it would
break the build for others as you remove paths from the search list
rather than just add a new one.  The addition of the debug library is
desirable but would raise the issue of mixing debug and release libs,
something that the present ones do in the opposite direction so the
original script isn't ideal on this either.

I can easily insert your additions into the OSG's FindFreetype.cmake,
however, I do wonder if it's not best now to just adopt CMake's own
FindFreetype.cmake.  CMake has come along way since the early days
when we adopted and it's own list of Find scripts was lacking.

I will have a bash with removing the OSG's FindFreetype.cmake so the
it utilizes CMake own version, if this works well I'll check it in to
git master.

On 1 June 2016 at 11:54, Stuart Mentzer <osgfo...@tevs.eu> wrote:


  Hi,

[I know this is more of a build issue but I was asked to bring this here to get a wider swath of OSG experts.]

I am doing Windows builds with VC++ 2015 and latest build from sources of the 3rd party libraries. A few issues with the current freetype lib cause the build to fail and we want to get the right patches to support different versions of freetype. The 2 issues are:

The include path structure doesn't have a freeetype2 directory anymore so the stock FindFreetype.cmake isn't working. In the attached FindFreetype.cmake I just hacked it to work with the new layout but that obviously won't work for the old layout. Does some CMake guru know the right way to do this? Would it work to just drop the OSG custom FindFreetype.cmake and use the CMake one (which seems to have both include/freetype2 and include supported in the latest CMake)?

The debug build doesn't find freetyped.lib because freetyped isn't in the NAMES list. I added freetyped to NAMES but if that isn't the right/safe way to do it it would be helpful to hear a better idea.

Thank you!

Cheers,
Stuart[/list]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67315#67315




Attachments:
http://forum.openscenegraph.org//files/findfreetypecmake_210.txt


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


  
  ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



  

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] freetype build support on Windows

[Stuart Mentzer]

Hi,

[I know this is more of a build issue but I was asked to bring this here to get 
a wider swath of OSG experts.]

I am doing Windows builds with VC++ 2015 and latest build from sources of the 
3rd party libraries. A few issues with the current freetype lib cause the build 
to fail and we want to get the right patches to support different versions of 
freetype. The 2 issues are:

The include path structure doesn't have a freeetype2 directory anymore so the 
stock FindFreetype.cmake isn't working. In the attached FindFreetype.cmake I 
just hacked it to work with the new layout but that obviously won't work for 
the old layout. Does some CMake guru know the right way to do this? Would it 
work to just drop the OSG custom FindFreetype.cmake and use the CMake one 
(which seems to have both include/freetype2 and include supported in the latest 
CMake)?

The debug build doesn't find freetyped.lib because freetyped isn't in the NAMES 
list. I added freetyped to NAMES but if that isn't the right/safe way to do it 
it would be helpful to hear a better idea.

Thank you!

Cheers,
Stuart[/list]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67315#67315




Attachments: 
http://forum.openscenegraph.org//files/findfreetypecmake_210.txt


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [ANN] Windows Binaries of OSG 3.4.0 : Visual C++ 2015 and Intel C++ 2016

[Stuart Mentzer]

Chris Hanson wrote:
> Hey Stuart, we should coordinate.


Sure. I'll email you directly for parts of the discussion that won't be of 
general interest.

Since the first info I posted for you I have got the builds scripted after the 
initial CMake setup tweaks.

Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67019#67019





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [ANN] Windows Binaries of OSG 3.4.0 : Visual C++ 2015 and Intel C++ 2016

[Stuart Mentzer]

Hi Sebastian,


SMesserschmidt wrote:
> Can you elaborate on the specific versions used for the 3rd-party libraries? 
> Especially if you compiled against Qt and possibly which version.


I built against Qt 5.6 and osgQt was built. I used the latest version of 
dependencies:
curl 7.48.0
freetype 2.6.3
giflib 5.1.4
glut 3.7
libjpeg 9b
libpng 1.6.21
libtiff 4.0.6
minizip GitHub tip
zlib 1.2.8


> Interesting, can you point to some sources why the /fp:fast is needed 
> for auto-vectorization? I'm pretty sure I've seen at least SSE2 
> vectorization on some meta-programming matrix code of mine. Precision 
> is  a real issue for me, so forgive my skepticism.


Yes, it is hard to find the documentation on this. The "fast" option is 
required for floating point loops to fully auto-vectorize because vectorization 
can reorder operations, thus breaking strict IEEE rules. Similarly, if you put 
#pragma simd on a loop it will enable "fast" for you. A reference for this with 
VC++ is:
https://blogs.msdn.microsoft.com/vcblog/2015/10/19/do-you-prefer-fast-or-precise/
  (see A7. Auto-Vectorization)
For Intel C++ one reference is the comment by Tim P. (who knows Intel 
compilers) in:
https://software.intel.com/en-us/forums/intel-c-compiler/topic/508146
where he says "/fp: options other than fast prevent vectorization which depends 
on optimizing order of operations"

It is probably most accurate to say that some vectorization is possible without 
the "fast" options but avoiding associativity limits vectorization. I'm not 
sure if /fp:fast=1 gives the full auto-vectorization with less precision loss. 
It would be good to have an option that allows reordering for loop 
vectorization but still uses the full precision math library calls, but I don't 
think that exists. I get the sensitivity to precision, which is why I'm trying 
to indicate that this first Intel C++ build is sort of experimental. Once we 
give it a workout and see the positive and negative effects of various options 
we'll know better what build variations are worth providing.

Regards,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67017#67017





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [ANN] Windows Binaries of OSG 3.4.0 : Visual C++ 2015 and Intel C++ 2016

[Stuart Mentzer]

Hello dear OSG-community,

OSG 3.4.0 Windows binaries built with Visual C++ 2015 and Intel C++ 2016 are 
now available from this page on my company's site:
http://objexx.com/OpenSceneGraph.html

A ReadMe.txt file in the root directory of the expanded package has some 
details.

These are 64-bit builds with the default GL2 OpenGL level and these 
dependencies: curl, freetype, giflib, glut, jpeg, lpng, minizip, tiff, zlib. We 
can add other plugins (GDAL, Collada, ...) based on community interest.

There is a vanilla VC++ build and also builds optimized for AVX2 (Haswell and 
later) CPUs. We are going to do some performance comparisons to see if the AVX2 
and/or Intel C++ are beneficial for our application: we also welcome feedback 
on performance from the community.

The Intel C++ build should be binary compatible with VC++ 2015 so you don't 
need Intel C++ to use it. Note that it was built with /fp:fast=2 to enable 
auto-vectorization of floating point loops: this could cause small precision 
loss that might matter with larger/geo distance scales. If vectorization isn't 
significant/beneficial this option may be dropped: input on this is welcomed.

We hope to do some OSG profiling and experiment with tuning on the Windows side 
with VTune: if we find anything interesting we'll post it on our OSG page and 
submit code back to the developers.

We don't have a need for 32-bit builds or older compilers but feel free to ask  
;) .

Since we need these ourselves we plan to post binaries for future OSG and 
compiler releases as a way to give back to the OSG community.

Best regards,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67012#67012





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015

[Stuart Mentzer]

  
  
Hi Chris,
Here's what I've got. You probably need to adjust the bat for
  your PATH setup. It isn't polished for general use yet so let me
  know if you have questions. I have only verified it with osgviewer
  so far: VC++ is (still!) too broken for MI + covariant returns to
  build my application so I have to refactor a bit before I can go
  further.
[The batch file is embedded in the text: most email systems block
  bat files.]

Stuart
--
  
Stuart G Mentzer
Objexx Engineering
Office  1.781.455.1150 x11
Mobile 1.781.708.3872

  
On 4/20/2016 5:23 PM, Chris Hanson
  wrote:


  
​Stuart, I am about to build OSG with VS2015 Community. Is your
build cookbook available somewhere so I'm not reinventing the
wheel?
  
  
  
  ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



  

OSG VC++ 2015 Build on Windows

Notes:
 mcd is a script for md then cd
 A subset of optional dependencies was used for this first try

cmake.VC.r.bat: (installs OSG to C:\OSG) (without /arch arg for build that 
works on generic CPU)
@echo off
setlocal
set 
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\bin;C:\MinGW\bin;C:\Git\cmd;C:\CMake\bin
set INCLUDE=
set LIB=
set LIBPATH=
call setVC14.64.bat
set CC=cl
set CXX=cl
del CMakeCache.txt >nul 2>nul
C:\CMake\bin\cmake.exe -G "MinGW Makefiles" -DCMAKE_COLOR_MAKEFILE:BOOL=0 
-DCMAKE_INSTALL_PREFIX="C:/OSG" -DCMAKE_BUILD_TYPE=RELEASE 
-DCMAKE_CXX_FLAGS_RELEASE="/nologo /EHsc /DNOMINMAX /DWIN32_LEAN_AND_MEAN 
/DNDEBUG /O2 /GS- /MD" -DCMAKE_C_FLAGS_RELEASE="/nologo /EHsc /DNOMINMAX 
/DWIN32_LEAN_AND_MEAN /DNDEBUG /O2 /GS- /MD" %*
make -j%NUMBER_OF_PROCESSORS% VERBOSE=true
make install
endlocal


zlib:
mcd zlib_build
..\cmake.VC.r.bat ../zlib
copy zconf.h ..\zlib

minizip: (after zlib)
option(USE_AES "enables building of aes library" OFF)
mcd minizip_build
..\cmake.VC.r.bat -DZLIB_LIBRARY:FILEPATH="../zlib_build/zlib.lib" 
-DZLIB_INCLUDE_DIR:PATH="../zlib" ../minizip

curl:
option(CURL_STATICLIB "Set to ON to build libcurl with static linking." ON)
mcd curl_build
..\cmake.VC.r.bat ../curl

freetype:
mcd freetype_build
..\cmake.VC.r.bat /I ../freetype

giflib:
copy osg-3rdparty-cmake\giflib\* giflib
mcd giflib_build
..\cmake.VC.r.bat -DGIFLIB_SOURCE_DIR:PATH="../giflib" -DSKIP_INSTALL_ALL=1 
../giflib

glut:
copy osg-3rdparty-cmake\glut\* glut
mcd glut_build
..\cmake.VC.r.bat -DGLUT_SOURCE_DIR:PATH="../glut" -DSKIP_INSTALL_ALL=1 ../glut

jpeg:
copy osg-3rdparty-cmake\libjpeg\* jpeg
mcd jpeg_build
..\cmake.VC.r.bat -DLIBJPEG_SOURCE_DIR:PATH="../jpeg" -DSKIP_INSTALL_ALL=1 
../jpeg

lpng: (after zlib)
mcd lpng_build
..\cmake.VC.r.bat -DZLIB_INCLUDE_DIR:PATH="../zlib" 
-DZLIB_LIBRARY:FILEPATH="../zlib_build/zlib" -DPNG_STATIC=1 ../lpng

tiff:
mcd tiff_build
..\cmake.VC.r.bat -DCMAKE_PREFIX_PATH:PATH=".." ../tiff
(not finding zlib, jpeg, ... packages)

Collect all 3rd party libraries in 3rdparty\lib directory and rename them:
freetype.lib
giflib.lib
glut32.lib
jpeg.lib
libcurl.lib
libcurl.dll
libcurl.dll.manifest
libpng16.lib(rename from libpng16_static.lib)
libpng16.dll
libpng16.dll.manifest
minizip.lib
tiff.lib
tiff.dll
tiff.dll.manifest
zlib.lib

Collect all 3rd party library headers in 3rdparty\include

OSG:

Put OSG 3.4.0 source in OSG directory

Top-level CMakeLists.txt:
 IF(MSVC) block (Use newest Windows Kits directory):
# Objexx
set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} 
/LIBPATH:\"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64\"" 
CACHE INTERNAL "" FORCE)
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} 
/LIBPATH:\"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64\"" 
CACHE INTERNAL "" FORCE)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} 
/LIBPATH:\"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64\"" 
CACHE INTERNAL "" FORCE)
include_directories(AFTER "C:/Projects/OSG/freetype/include")
 Enable packages on this line and add C:\CMake\bin to PATH so cpack is found:
OPTION(BUILD_OSG_PACKAGES "Set to ON to generate CPack configuration files 
and packaging targets" ON)

mcd OSG_build
..\cmake.VC.r.bat ../OSG___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015

[Stuart Mentzer]

Thanks Sebastian.

Good reminder about /arch:AVX2. I can post a separate binary package built with 
this for people with newer CPUs if it shows a good performance gain.

I'll also experiment with /fp:fast and see what the performance gain is, but it 
sounds like it might not be a good idea for an OSG distribution package.

I'll try to get the Intel C++ builds working and I'll report back if I have any 
interesting findings. The docs claim binary compatibility with VC++ 2015 with 
/Qvc14. If there is interest in the CMake additions to support Intel C++ I can 
push them to a GitHub branch.

If anyone can point me to good performance benchmarks that would be helpful in 
sorting out the VC++ and Intel C++ options and performance.

Thanks,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66861#66861





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015

[Stuart Mentzer]

Hi,

After some struggle I have managed to make a cookbook for building OSG with 
Visual C++ 2015. This is very exciting because I should finally be able to 
build our structural impact modeling application on Windows. There are a few 
items that would be great to get some feedback on:

For best (release build) performance would it make sense to use /fp:fast (along 
with /O2 /GS-) or could this create problems with propagation of the NaNs that 
can arise in OSG?

Would trying to build with Intel C++ likely to give significantly better 
performance? This is probably a question of whether OSG would benefit from its 
better auto-vectorization.

If I stick with the VC++ 2015 OSG build I should be OK linking my application 
built with Intel C++ 2016 to it since they seem to be binary compatible, right?


Since I'll need to build future OSG releases I am willing to host the Windows 
OSG (starting with 3.4.0) binary packages on our company website if someone on 
the OSG team wants to add a link to it on the Stable Releases page. Just let me 
know who best to contact.

Thank you!

Cheers,
Stuart[/list]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66848#66848





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session

[Stuart Mentzer]

Hi,

To clarify, problem is already solved with the fix to xorg.conf I posted. 
glxinfo and glxgears were not running correctly and now they are.

Yes, I am running nvidia drivers properly and all was well under F17 as I 
stated. This is a bug in F18 that should get fixed eventually.

Thanks all,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=52323#52323





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session

[Stuart Mentzer]

Thanks for all the input.

The Files section with those 2 lines already appears in 
/etc/X11/xorg.conf.d/00-nvidia.conf but for some reason isn't getting picked up 
in F18. I am not sure there is a benefit to copying that to 
/usr/share/X11/xorg.conf.d/ as well. I am no expert on how the nvidia drivers 
use the xorg.conf system but since it is obsolete on Fedora it is a likely 
source of future grief, unfortunately.

Not the place to debate distros but I can't agree with Fedora 18 being a 
lemon although I didn't use the new installer that is attracting complaints. 
Each Fedora release has problems initially that require these sorts of 
work-arounds but that is the nature of the beast. It is still a great 
development platform when you need the latest tools, although my Kubuntu 12.10 
system is almost as up to date (except for kernels of course) and was a lot 
easier to set up. YMMV.

Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=52337#52337





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session

[Stuart Mentzer]

Hi Robert,

No luck: Both osgviewer and my (debug build) app bring down the session even 
running under gdb.

Running my app in its non-GUI mode that brings up a stand-alone OSG window 
doesn't kill the session. Instead I get:

Code:

Error: Not able to create requested visual.
  GraphicsWindow has not been created successfully.
Error: Not able to create requested visual.
  GraphicsWindow has not been created successfully.
Viewer::realize() - failed to set up any windows




I don't know if that is helpful. We probably need to wait for someone else to 
chime in on whether OSG on F18+nVidia is working for them.

BTW the current nvidia driver is 304.64-2.fc18. I think later drivers may be 
available in an rpmfusion testing repository in case we want to try that route.

Cheers,
Stuart[/code]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=52292#52292





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session

[Stuart Mentzer]

Hi Robert,

You were right: the problem was broader than OSG. The fix was to modify 
/etc/X11/xorg.conf so that these 2 lines were in the Files section:


Code:
Section Files
ModulePath /usr/lib64/nvidia/xorg
ModulePath /usr/lib64/xorg/modules
EndSection




This comes from http://forums.fedoraforum.org/showthread.php?p=1626150

I hope this helps some other F18 users (until this bug is fixed).

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=52308#52308





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Fedora 18 with nVidia driver: OSG crashes session

[Stuart Mentzer]

Hi,

I recently upgraded a system from Fedora 17 to 18 (64-bit KDE spin). I am using 
the rpmfusion nvidia drivers and the upgrade (using the new fedup) seems to 
have gone well.

Problem is, now my OSG applications as well as osgviewer crash my session 
instantly and send me back to the login screen! I didn't have any problem on 
Fedora 17. I did all the normal post-upgrade cleanups (distro sync, etc.) and 
all the OSG packages seem to be properly upgraded to the latest 3.0.1.1-3.fc18 
versions.

There is clearly something seriously wrong here. Any ideas? I'm happy to help 
debug this further.

Thanks,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=52267#52267





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Fedora 16 + nouveau + OSG 3.0.1 = assertion failure

[Stuart Mentzer]

Hi,

Just updated to Fedora 16 running the nouveau video driver and now my app using 
OSG and osgviewer give this on exit:

Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion 
`map-l_init_called' failed!

Anyone else seeing/seen this?

Otherwise, I'm happy to see that my app built with 2.8.4 seems to run mostly 
fine without changes under 3.0.1. I looked for a porting guide but didn't find 
one. If anyone has pointers on needed or suggested changes for 3.0.1 I'd 
appreciate it.

Thank you!

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43783#43783





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org