[Scons-users] SCons as a library

[Kenny, Jason L]

>>

Right.
For instance. In fudepan, fbuild keeps track of the fundation's projects, so any newcomer can download fbuild and say fbuild targets and it will list the projects available to him, he can then download it with fbuild myproject:checkout and run its unittests with fbuild myproject:test and so on...

Does Parts works like that?

>>


Parts allows Scons to drive the build for the most part. It adds an idea of a component called a Part. The Part can be given a VCS object (like VcsSvn(...) ) that would define information about where to get the code for the Parts. Currently Parts will check out all the Part()s that are defined when you start a build, and only update the code if:

1)      The information about what to check out is different ( such as you point to a different branch, or select a different branch as with the SmartSvn object)

2)      You request the code to be updated via the -update switch. ( default to all component, but can be given options to update only a given set of 1 or more components)

Checkouts are done in parallel using the value of -j, however this can be overridden with a --vcs-jobs option to be serial or more parallel.

I hope someday to have time to implement a new format, or a continuous loader that would allow me to only check out the components needed ( vs all of them). The current logic is as it is because we don't know what Parts depend on other parts on a fresh build, so we have to check out the code to get the part file information. Given that a Part file is a python file at the end of the day people can scan the drive with their own code. This generally means at the moment I have I check out all the data ( not just a Parts file) to make sure that part file when read ( and given who it is done in scons "executed" in python) that directories and files it expects to find are there.

As far as testing goes we have a notion of a unit test. (ie an program that is the test) The api can be customized to do stuff with gold testing, however a different API would be better for this. To run a test you might say:

#run all tests in mycomp
Scons run_utest::mycomp
#run test1 in mycomp
Scons run_utest::mycomp::test1

Or if you had "sub" parts you might any to run all the tests in mycomp and any sub-part. This would be done via
Scons run_test::mycomp::  # ending :: is like a *, ( without * shell issues :) )
Or you could run all tests defined in the Sconstruct via :
Scons run_utest::

  Parts does not have a central repro of project information it points to what projects exists or don't, or how they relate and what versions of the components exists. I did not do this for a few reasons. However I could see this as a nice addon.

Hope this helps. Let me know if there are any other questions
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20131010/083346ad/attachment.htm