[Scons-users] SCons as a library

[Matias Iturburu]

2013/10/10 Kenny, Jason L <jason.l.kenny at intel.com>


>  >>** **

>

> 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 J )****

>

> 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****

>

>

Ok, so there is not much overlap, in the sense that there are clearly
different goals with both projects.
So my first question still remains.
Is there a way that I could load a SConstruct (or SConscript) dynamically
and call the SCons main entry point from a python script without relying in
a subproces call?





> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

>

>



-- 
<http://www.tallertechnologies.com>
Matías Iturburu
Software Engineer

*San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

*
*Phone: +54 351 4217888 / +54 351 4218211
Skype: matias.iturburu*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20131010/8d52a1c0/attachment-0001.html