[Scons-dev] SCons-like build system

[Kenny, Jason L]

HI,

Looks nice. It will be nice to see more documentation on this. I am interested in how you deal with target platforms and tool section ( I see that you suggest that tool version selection exists).

Another test which would be useful for me is how well does this scale. You show an example with lots of node in a given aql file. The issue I see with this is that in my case I have 1000+ build (parts) files that need to be loaded. The some of the total targets (objs,so|dll, etc) would be about 200K. One issue with this is that it takes time to load each file. What I have seem with SCons, and looks like you have a similar issue, is that to load a build file, means it has to be processed/executed by python. This takes time as user tend to scan the disk to get the source files and python code is executed. As the build gets larger the time to rebuild when one file changed take much longer. Parts ( currently) does some work to avoid loading build files to SCons to reduce the startup time to get a build going. What would take Scons 2-3 minute to get started with a build, now takes 3 to30 second ( depending on states…).

Just something to think about. I have number of other suggestion on what could be done in you DB to store cetain states to allow rebuild to get going very fast. Some other these I have not done in Parts yet ( as I don’t have “easy” control over the main execution logic )

Jason

From: Scons-dev [mailto:scons-dev-bounces at scons.org] On Behalf Of Constantine
Sent: Wednesday, January 14, 2015 1:38 AM
To: SCons developer list
Subject: Re: [Scons-dev] SCons-like build system

Hi Jason,

>> What I would like to know as I did not see it in the example right off is, how do you deal with lots of components.

I guess you mean this example: https://github.com/aqualid/aqualid/wiki/An-introduction-to-Aqualid#build-sub-projects


lib = Script('../lib/make.aql')['lib']



dll = tools.cpp.LinkSharedLibrary( 'tool_api.cpp', lib, target = 'toolapi',

                                   cpppath = lib.options.api_cpppath,

                                   api_cpppath = '.',

                                   cppdefines = 'MAKING_LIBRARY' )

We call function 'Script()' to build component 'lib'.
This function returns a dictionary of all local variables defined inside the executed script. Then we get the 'lib' Node.

To build a shared library we use the lib's CPPPATH:
  cpppath = lib.options.api_cpppath,

Option 'api_cpppath' will have correct CPPPATH to use headers of this library.
Inside component 'lib' we are free to change directories layout whenever we want.

>> Also your benchmarks… is this 32-bit or 64-bit.
I used 64-bit Linux, 2 cores CPU and available 1.3 GiB of RAM, no swap

Thank you.
Best regards,
Konstantin.

On Wed, Jan 14, 2015 at 1:07 AM, Kenny, Jason L <jason.l.kenny at intel.com<mailto:jason.l.kenny at intel.com>> wrote:
Interesting.

I like some of the stuff you have here. I can only do so much in Parts wrapping SCons, some of it has to be in the core

What I would like to know as I did not see it in the example right off is, how do you deal with lots of components. One feature I have in Parts and often see people implement in different ways in raw SCons is passing information between different files. The common case of this is when link a lib file in to your main program you don’t know what the real name of the lib file is or you want to be protected from having a build break because a component for whatever reason change the output name.

Also your benchmarks… is this 32-bit or 64-bit. I missed it on the webpage. I ask as you show Scons blowing up a 100K node. I know I have a build here with Scons at 200K worth of files node as it works fine ( build in about 2 hours with 24 cores and 16GB of memory for SCons and the tools/compilers.)

Jason


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150114/22a0e7a1/attachment.html>