[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_Mentzer at 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_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
>