[osg-users] freetype build support on Windows

[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 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
>