Hi Gerrit,
Gerrit Voss wrote:
> On Thu, 2007-06-28 at 11:28 +0200, Carsten Neumann wrote:
> 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).
The SConscripts fill LibraryInfo objects with information about the
library. The actual scons environments used to build the libraries are
created by the functions createLibEnv, createTestEnv, createUnittestEnv.
> 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.
The fields of a LibraryInfo object have a pretty direct mapping to
entries in the environment, but there is still a postprocessing step.
Additionally most SConscript files only call addFiles(lib_map,
'LibName') and visitSubdirs which hides most of the filling of
LibraryInfo objects.
However, it is true that there is no abstraction for external libraries,
i.e. the entries in LibraryInfo.libs are simply added to the LIBS
construction variable of the environment.
> 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.
OK, the name SConscript can easily be changed. More important is the
fact that these files are executed/called by the SConscript function of
scons. That means they have access to all of scons features which I find
a nice advantage over the mechanism used to execute the build.info files.
> 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.
I'm not sure I understand this. If it can build more than OpenSG it
should do OK for OpenSG alone, no?
Thanks,
Carsten
-------------------------------------------------------------------------
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
