[osg-users] freetype build support on Windows

Sun Jun 5 14:51:08 PDT 2016

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_Mentzer at 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" <osgforum at 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 at lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>>
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org