Hi,
On Mon, 2008-12-15 at 17:55 +0100, Carsten Neumann wrote:
> Hi Gerrit,
>
> -------- Original-Nachricht --------
> > Datum: Sun, 14 Dec 2008 14:42:09 +0800
> > Von: Gerrit Voss <[email protected]>
> > An: [email protected]
> > Betreff: Re: [Opensg-core] OpenSG AddonHacks broken with recent scons-addons
>
> > On Tue, 2008-11-04 at 10:09 -0300, Thiago Bastos wrote:
>
> [SNIP - CMake]
>
> > 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.
>
> heh, I was going to do the same thing over the holidays.
> Are you considering a serious effort in this direction or are you only trying
> to see if it can be done ?
actually by now yes, I spend the last two days on it and so far most of
the libs build with all options we had with scons.
Missing are currently the generated code (fcd/lex/yacc), tests,
unittests, and some of the compiler flags.
Currently it's not the most elegant solution as quite some things
are done explicitly instead of being wrapped into functions/macros.
But overall I quite like the simplicity so far.
I'll see if I can commit something within this week.
> > 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.
> >
> > As a concrete example, how do I tell the OSGSystem build env. where to
> > find the OSGBase includes.
>
> On a test cmake build for collada-dom I used a global property to pass source
> lists upward.
> I had wrapped the set_property call inside a function:
>
> function(add_cdom_src)
> set_property(GLOBAL APPEND PROPERTY ${ARGV})
> end_function(add_cdom_src)
I currently write things (sources, inc dirs) to one file per lib and
include that one later on as I need the information. I tried the
property way with the target and there lists did not work.
> > 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>
>
> hm, I've looked a bit at the KDE build to see how they do things and for them
> just using include_directories seems to work. Do you know of a system where
> this will run into
> limitations or do you think we could start optimistically and work around
> problems when they arise ?
just include directories can work if you use them explicitly and have
few of them, with OpenSG I think there are to many. I still would
like to keep the feature that you can just add a subdir and things
get picked up automatically. But this still needs some work.
But in general, yes I work optimistically and go on until I get stuck
and than come up with a solution. Later on I plan to quickly go over it
and maybe wrap one thing or the other to functions.
> PS: I'm in Germany until early Jan, are you visiting this year too ?
I will be in Darmstadt from 24/12 - 14/01.
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
