[Scons-dev] A new architecture...
Hi all, the discussions about new features in SCons during the last weeks, have led me to start working on some architectural changes for SCons. They aim at refactoring the module/package structure, such that it's possible to better support customized - Taskmasters - File signature calculation (currently fixed to MD5 hash sums) - Node factories (and connected with that custom Nodes) - Build and Node Info (and connected with that custom signature DBs, like a JSON implementation for easier debugging) . Please note that my pull request doesn't directly implement and provide these functionalities (well, some of it), but simply tries to lay out the foundation for them. There is definitely more work ahead... Once we have this in place, it should be much easier to support e.g. additional Taskmasters like an EspeciallyParanoidTaskmaster (see Tom Tanner's proposal at https://pairlist4.pair.net/pipermail/scons-users/2015-December/004320.html and following), or a DebuggingTaskmaster where you get a lot of additional info about the current "machine state", and can walk through a complete build in single steps. I don't know when this PR will be ready, but just wanted to inform you all that someone is working on this somewhere. :) Your comments and suggestions are welcome. Best regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] A new architecture...
On Sun, Dec 27, 2015 at 3:58 PM, Dirk Bächle wrote: > > the discussions about new features in SCons during the last weeks, have led > me to start working on some architectural changes > for SCons. They aim at refactoring the module/package structure, such that > it's possible to better support customized > > - Taskmasters > - File signature calculation (currently fixed to MD5 hash sums) > - Node factories (and connected with that custom Nodes) > - Build and Node Info (and connected with that custom signature DBs, like a > JSON implementation for easier debugging) I am afraid I don't understand architectures without a visual representation. In ideal world d3.js and Inkscape skills are taught in school, but maybe we could at least try? "refactoring module/package structure" is not a useful activity for me without rationale, and "to better support" is not a good one. 1. problem 2. solution 3. action Right now it is: 1. problem: some not good enough support 2. solution: refactoring and moving files 3. action: start working Sorry for the harsh tome. Just want to be more constructive and extract a little bit more value for those scarce bits of time that we here have. > . > Please note that my pull request doesn't directly implement and provide > these functionalities (well, some of it), but simply tries to lay out the > foundation for them. There is definitely more work ahead... Where is the link to PR? > Once we have this in place, it should be much easier to support e.g. > additional Taskmasters like an > > EspeciallyParanoidTaskmaster > > (see Tom Tanner's proposal at > https://pairlist4.pair.net/pipermail/scons-users/2015-December/004320.html > and following), or a > > DebuggingTaskmaster Where is it? https://www.google.com/search?q=DebuggingTaskmaster Looks like Bitbucket doesn't work for us. > where you get a lot of additional info about the current "machine state", > and can walk through a complete build in single steps. What are the classes / objects that store the build state? 1. class FS (filesystem tree that is known to SCons) Q. How to dump FS state? 2. class Node (a pointer to a Graph of build nodes) Q. How to dump graph of build nodes? A. Find one node, and fetch it's child, parent and discover the whole graph this way. Q. How? 3. Any other objects? > I don't know when this PR will be ready, but just wanted to inform you all > that someone is working on this somewhere. :) > Your comments and suggestions are welcome. I miss the "EventBuffer" for SCons to be able to review any architecture refactoring. See Twisted logging to get the idea: https://twistedmatrix.com/documents/15.2.1/core/howto/logger.html A buffer with about 1000 events that could be dumped at any time during SCons processing. It should at least include those type of events: - SCons state initialization phases - SCons state processing phase - Target building phase It would be better to share your prototypes in small chunks and as early as possible. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] A new architecture...
Hi Anatoly, On 28.12.2015 15:24, anatoly techtonik wrote: [...] Right now it is: 1. problem: some not good enough support 2. solution: refactoring and moving files 3. action: start working Sorry for the harsh tome. Just want to be more constructive and extract a little bit more value for those scarce bits of time that we here have. don't worry...if it's coming from you, I know that you're not trying to hurt me. So be as harsh with me as you want. Neither the pull request, nor the other mentioned changes, are finished or in a state ready to be published. My mail was thought to be nothing more than an announcement, sorry if you missed that point. I'll try to make this clearer next time, by prefixing the title with "Announcement:". Best regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] A new architecture...
On Mon, Dec 28, 2015 at 5:36 PM, Dirk Bächle wrote: > Hi Anatoly, > > On 28.12.2015 15:24, anatoly techtonik wrote: >> >> [...] >>> >>> Right now it is: >>> >>> 1. problem: some not good enough support >>> 2. solution: refactoring and moving files >>> 3. action: start working >>> >>> Sorry for the harsh tome. Just want to be more constructive and extract a >>> little >>> bit more value for those scarce bits of time that we here have. > > > don't worry...if it's coming from you, I know that you're not trying to hurt > me. So be as harsh with me as you want. > > Neither the pull request, nor the other mentioned changes, are finished or > in a state ready to be published. My mail was thought to be nothing more > than an announcement, sorry if you missed that point. I'll try to make this > clearer next time, by prefixing the title with "Announcement:". No. That's good. Don't bother yourself. At least I've felt some motivation to implement that EventBuffer idea, and there is now a mailing list entry that I can refer too if somebody will ask me about it. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
