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