Small suggestion: is it possible to remove references to freetype219
from FindFreeType.cmake?
This version does not works with 2.3.10 anyway (and helps generate my
error...)
Thanks!
mario
Colin Dunlop wrote:
> Hi Robert (JS and Paul),
>
> I solved my WIN32 FreeType problem that I mentioned to you off-line.
>
> If I rename:
> ~OSG/3rdparty/3rdParty_win32binaries_vs80sp1
> to:
> ~OSG/3rdparty
>
> then the CMake will configure correctly the variables:
> FREETYPE_INCLUDE_DIR_freetype2
> FREETYPE_INCLUDE_DIR_ft2build
> to
> $(FREETYPE_INCLUDE_DIR)
>
> Prior to this I was setting the CMake variable ACTUAL_3DPARTY_DIR
> to my preferred location and then pressing Configure. All worked
> apart from FreeType where the two variable refused to set and
> the plug-in was not put into the build... (The other three
> FREETYPE_INCLUDE_DIR, LIBFREETYPE_LIBRARY, FREETYPE_LIBRARY_DEBUG
> are always set ok.
>
> However obviously something is a wrong when this assumption is
> being made. Every other part of the CMake configuration and build
> works fine when I rename my 3rdparty directory and then just set
> manually my ACTUAL_3DPARTY_DIR in CMake and call Configure. So
> I guess something in FindFreeType.cmake is working when the 3rd
> party directory is "default" and not when it's changed - strange!
>
> Anyway I've been looking at this all day and I'll keep digging
> unless somebody else can see it straight away... Maybe it's my
> set-up and a rouge env variable or PATH entry so I'll have to dig.
> But if some other Windows user could confirm they get this bug
> also then I can know it's not my set-up.
>
> No need to delay the build for this one - 99.9% of people will
> use the default, however now that Mike's stuff is in SVN it's
> easier to make the above switch. I actually use the 7.1 stuff
> also so having them both named OSG/3rdparty is not an option ;)
>
> Sorry for the wild goose chase that came back to my back door.
>
> Time to turn in 4 some zzzzzzzzzz's.....
>
> Cheers,
>
> Colin.
>
> Some background info below I was about to post until 2 minutes ago:
>
> ****************************************************************
>
> There is still a minor FreeType CMake problem IMO that has been
> mentioned on the list and solved with manual intervention, but
> would be nice to clean up. Maybe I'm the only person getting
> this, but I've retested on two machines from fresh svn of OSG
> and Mike's VS8sp1 3rd-party dependencies so I don't think I'm
> going mad or anything.
>
> One problem I am still seeing is that even after pointing cmake at
> the 3rd-party directory and pressing configure a few times is that
> the freetype plug-in is refusing to appear as a build target. After
> browsing the archive you can get around this by manually pointing
> the unresolved variables:
>
> FREETYPE_INCLUDE_DIR_freetype2
> FREETYPE_INCLUDE_DIR_ft2build
>
> to the FREETYPE_INCLUDE_DIR value (set to $(FREETYPE_INCLUDE_DIR) ).
> So even with a valid entry for FREETYPE_INCLUDE_DIR, LIBFREETYPE_LIBRARY
> and FREETYPE_LIBRARY_DEBUG CMake will mark the plug-in as not to be
> built without the latter two above variables.
>
> So without being a cmake or freetype expert is this a valid course
> of action? Also the missing variables are both marked as []advanced
> and therefore invisible to people by default.
>
> All now working ok but I'll investigate further as I not being a CMake
> expert I can't quite see how the ordering of the
> Find3rdPartyDependencies.cmake and FindFreeType.cmake work together?
> Seems the Find3rdPartyDependencies.cmake has the lines:
>
> FIND_DEPENDENCY(FREETYPE ft2build.h
> "freetype;freetype219;freetype234;freetype234MT;freetype235"
> ${OSG_3RDPARTY_BIN} "_D")
> IF(FREETYPE_FOUND)
> #forcing subsequent FindFreeType stuff to not search for
> other variables.... kind of a hack
> SET(FREETYPE_INCLUDE_DIR_ft2build ${FREETYPE_INCLUDE_DIR}
> CACHE PATH "")
> SET(FREETYPE_INCLUDE_DIR_freetype2 ${FREETYPE_INCLUDE_DIR}
> CACHE PATH "")
> MARK_AS_ADVANCED(FREETYPE_INCLUDE_DIR_ft2build
> FREETYPE_INCLUDE_DIR_freetype2)
>
> but in my case the FREETYPE_FOUND section is never entered? I intend to
> investigate this further. This only happens on a completely cache free
> new set-up and once you set these variables freetype will always build.
> I repeat only ever shows up if you change the build directory to a
> fresh one and clear the cache. You don't have to press OK to see this
> happening as "Generate" will make a skeleton of the build tree in the
> build location and the "freetype" directory is absent from the
> src/osgPlugins directory. Obviously this is easier to see in an out of
> source build which I prefer anyway.
>
> ****************************************************************
>
> Jean-Sébastien Guay wrote:
>
>> Hi Robert,
>>
>>
>>> I haven't yet received any update on the Windows/FreeType
>>>
>> As Paul and I mentioned (you probably just didn't see it in the rest of
>> the list traffic) this was surely caused by a stale CMakeCache.txt or
>> something specific to that user. No one else has experienced this
>> (except when we moved from the old 3rdParty binaries to Mike's SVN a
>> while ago, which seems to be what happened for this user too) so I don't
>> think it's an issue with the project as a whole.
>>
>>
>> On Windows, when CMake generates the Visual Studio project files, they
>> no longer contain the headers under the "Header files" folder in the
>> core projects. This doesn't affect the build itself, but it's
>> inconvenient since we're used to having all the sources and headers
>> there. Is there an additional tweak to make to the CMake configs?
>>
>> The build itself seems to be going fine. I'll let you know when it finishes.
>>
>>
>> J-S
>>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
--
Ing. Mario Valle
Data Analysis and Visualization Services | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
