Hi,
On Thu, 2007-06-28 at 11:28 +0200, Carsten Neumann wrote:
> Hi,
>
> Allen Bierbaum wrote:
> > Dirk Reiners wrote:
> >> Carsten Neumann wrote:
> >>> I'd appreciate it if you could try this out and give me some feedback on
> >>> your experience (I might have accidentally killed your favorite feature
> >>> ;) ).
> >> in general I like it, it seems cleaner than before. The only thing I'm not
> >> too
> >> happy about is the need to have an SConscript in each directory, but for
> >> now
> >> let's keep it that way.
> >
> > That does sounds like a step back. What is the reason for doing it this
> > way as opposed to build.info files or even SConscript files only being
> > in the "parent" directories for libraries?
>
> it is far simpler to implement and IMHO understand. I've just added a
> warning that complains about directories without SConscript file, this
> should avoid confusion when new directories are added to the tree. I
> could even turn this into an error, to make it harder to miss ?
a little more,
there is a subtle change I'm a little bit worried about. The build.info
files abstracted much of the inner workings quite well. You basically
just filled a set of predefined variables and the BuildInfo Scanner
mapped them back to the internal structure (e.g. lib_map). The
SConscript files on the other hand expose the internal structure (as
far as I understand them). So any change to the internal structure has
the possibility to affect all the SConscript files whereas for the
build.info case this usually should not be the case.
Handling lib dependent default values if something was not set by
build.info also seems easier because you had a default postprocessing
step before the internal structure was filled.
I'm also not quite sure if SConscript is the best way to name these
files. build.info was IMHO better suited as that exactly describes what
they do. I don't know if how much of a mixup with the common scons
meaning can happen.
kind regards,
gerrit
PS: As usual I used the OpenSG scons structure for other things, so I'm
never quite sure if everything is valid for OpenSG only builds.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
