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

2016-09-05 Thread Robert Osfield
Thanks Stuart, your FindFreetype.cmake is now checked into OSG master, so will be part of the OSG-3.6 release. Cheers, Robert. On 21 June 2016 at 19:01, Stuart Mentzer wrote: > Hi Robert, > > Here is what should be the final version of FindFreetype.cmake that is based > on the

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

2016-06-21 Thread 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

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

2016-06-09 Thread Stuart Mentzer
On 6/9/2016 9:15 AM, Robert Osfield wrote: Hi Stuart, On 9 June 2016 at 12:39, Stuart Mentzer 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

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

2016-06-09 Thread Robert Osfield
Hi Stuart, On 9 June 2016 at 12:39, Stuart Mentzer 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

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

2016-06-09 Thread 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

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

2016-06-08 Thread 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

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

2016-06-08 Thread Robert Osfield
Hi Stuart, On 8 June 2016 at 16:11, Stuart Mentzer 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)

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

2016-06-08 Thread 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

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

2016-06-08 Thread Robert Osfield
Hi Stuart, On 8 June 2016 at 15:54, Stuart Mentzer 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

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

2016-06-08 Thread 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

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

2016-06-08 Thread Robert Osfield
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

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

2016-06-07 Thread 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

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

2016-06-07 Thread 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

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

2016-06-07 Thread 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

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

2016-06-06 Thread Robert Osfield
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

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

2016-06-05 Thread 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

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

2016-06-05 Thread Robert Osfield
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

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

2016-06-04 Thread 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

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

2016-06-04 Thread Robert Osfield
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

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

2016-06-03 Thread 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

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

2016-06-02 Thread 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

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

2016-06-02 Thread Robert Osfield
Hi Stuart, The PNG link in freetype is something we can't hardwire into the OSG's freetype plugin as it will break the build for those who use freetype without PNG and don't have png available. Could you check the CMake FindFreetype.cmake to see if it has any var for additional libraries that

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

2016-06-02 Thread 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

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

2016-06-02 Thread Robert Osfield
Hi Stuart, On 2 June 2016 at 02:08, Stuart Mentzer wrote: > 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

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

2016-06-01 Thread 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

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

2016-06-01 Thread Robert Osfield
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

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

2016-06-01 Thread Robert Osfield
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,

[osg-users] freetype build support on Windows

2016-06-01 Thread 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