[Scons-dev] SCons + Tup?

[Kenny, Jason L]

>> Glad you like it. Personally I only have small builds so I have no 

>> experience of big builds, but I know many on this list have, and 

>> indeed Jason has very big builds and has built Parts, which is an add 

>> on to SCons with a few changes to core SCons - which we are hoping to 

>> absorb into SCons as and when we can.



>It looks interesting :-) I understood the idea is checking only the part ("subtree"?) where a file was edited. Are there any possibilities that it could create any inconsistencies?


No not really.. the real risk is not loading important information need to build the needed target or not detecting something changed. The Core Scons logic is pretty solid. The code, I admit needs some cleaning up, but that is a different issue. Honestly I believe given what I have in the works that some refactoring of some logic in SCons to better use the stored information and add a few of the methods in Parts will allow SCons to start up much faster and scale much better with large builds. The issues if the tree getting inconstant is basically what scons is about. It is design to look for items that are inconstant since the last build, and those are the items we want to rebuild.


>From a simple point of view the issue of file based differences is simple to do. The issue that is more complex is environmental differences, which define how to build items. The issue of some build files defining some value that is passed around in and environment or via some import export api is what is hard to deal with. The way Scons is done at the moment is that it processes all the file maps all the data, then see what is different is part of why it is "slow". It is also a reason why it is correct, and can scale easily to large builds, as it is much easier to define a large system without having to deal with ordering issues, unlike other system, classically Make, which depends on the user to define the files and information in the correct order for the build to be correct. Because system like Make in general say the build error are probably the user fault for not setting up the environment correctly, or the dependency correctly, it can run very fast, as it just has to start doing work as soon as it see something to do. SCons on the other hand has a lot more to check for and to map to make sure it can start building. This ability is what I love about it. It is nice to say to a system build these files as a program, and it depends on some stuff that you may or may not know about yet and the system puts it together and does the right thing. This allow me as a developer to work on my problems, not on how to build the code. 


Jason