Hi,
On Sun, 2008-12-14 at 10:25 -0300, Thiago Bastos wrote:
> Hi Gerrit,
>
>
> I'm partially looking into this after trying to figure out why
> scons
> doesn't want to build native win64 stuff. And OS X seems to be
> broken
> too, looking at more recent mails.
>
> Glad to hear that!
>
>
>
> So one general question for the cmake users, how do I
> propagate
> information, e.g. lists of values, up. E.g. from a subdir
> cmakelists.txt to the ones above. Ideally without writing it
> to files. But looking at OpenSG's structure it might be the
> best
> to traverse the source tree and write out files and use these
> to
> setup all the targets as a second step.
>
> CMake has several types of properties. A property can be assigned to a
> file, a directory, a target, or globally to CMake.
> Include and lib directories are commonly controlled via directory
> properties, which by default are propagated downwards (i.e. from
> parent dirs to sub dirs).
> If you wish you could define a new global property using
> "define_property" and then manipulate it via "get/set_property".
that's what I tried but I never got a list accepted as the value for
a property. The list seem to be confused with multiple prop/value pairs.
A single value works fine. Ideally I would like to attach it to the
target and not modify a global value.
>
>
> As a concrete example, how do I tell the OSGSystem build env.
> where to
> find the OSGBase includes.
>
> Ideally I want to get away from the scons way of either
> finding it
> locally via include"" or in the global install dir. That just
> does
> not seem to work well and is the worst part of the scons build
> system.
>
> Switching to include <> might be a solution, but I'm not sure
> how to
> handle the OpenSG subdir part of #include<OpenSG/XX>
>
> I would strongly advise you to take the simplest path to solve this
> problem.
> The CMakeList.txt in your root dir (which would be alongside the
> SConstruct) is used to set global stuff.
> Simply declare all the directories you want to have added to the
> include path there. For instance:
>
> SET( sourceDir ${CMAKE_HOME_DIRECTORY}/Source )
> INCLUDE_DIRECTORIES(
>
> ${sourceDir}/Base/Base
> ${sourceDir}/Base/Field
> ...
> )
That's what I really really really don't want. For something the size of
OpenSG that get's really messy. And IIRC there is a limit how many
include dirs can be set through the command line, which is typically a
limitation of the shell used during the build stage. That's one reason
I'm thinking about going back to one intermediate include dir per lib.
> Of course, you could create variables (e.g. OSGBASE_INCLUDE_DIRS,
> OSGSYSTEM_INCLUDE_DIRS) with the list of dirs for re-use.
> But I would not do anything fancy/complex to find the directories
> automatically if the list of dirs only change at rare occasions.
>
> Anyway, if you define the variables manually now, you could later on
> switch to an automatic approach that finds and defines the variables
> automatically.
I worked around it by writing a file per lib that is filled during the
traversal and that can be reused in dependent targets. That seem to work
reasonably well.
kind regards,
gerrit
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
