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