On Tue, Oct 20, 2015 at 6:39 PM, Jason Kenny <[email protected]> wrote: > > I would hope that the concepts I talked about here are something we can > find common ground on and talk about defining some common name for. I know > this is a large e-mail, However I like very much some thoughts about what I > suggest at high level to form a base of communication for use on the tool > design. > I am for the opposite approach - find place in SCons for components already present in Parts ASAP. Choose the ones that will be reused anyway. Like if there is a code that does lookup in path on Linux, registry on Windows etc. I would like to see a Finder module for that. Maybe even `finder` module that is independent of SCons.
Then I'd like to have a "tool discovery debugger" that will invoke SCons/Parts API to just do tool bootstrapping part on tool discovery and print output to the screen. Then I'd like to see how do we actually specify the tools. Is it the current Environment(tools=['list', 'of', 'names']) or there are some use cases that are not covered by this call. Maybe there are some tales that tell that this is inconvenient. And the thing that I feel is needed that for all these new objects - Platform, ToolInfo etc. it to have static state that could be dumped into JSON/YAML and restored from. For debugging, caching, for sharing settings, whatever. -- anatoly t.
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
