Okay, tests and changes to documentation now added in also I've raised a pull request here https://bitbucket.org/scons/scons/pull-requests/481/addition-of-support-for-nested-tools-tools/diff
Many Thanks Richard On 15 June 2017 at 20:36, Bill Deegan <[email protected]> wrote: > Interesting. > > Would need some tests to cover this new functionality. > Also likely some additions to documentation (manpage/user guide) > src/CHANGES.txt > > > > On Thu, Jun 15, 2017 at 2:52 PM, RW via Scons-users <[email protected] > > wrote: > >> Hi, >> I've recently coded up a new feature under a fork >> https://bitbucket.org/grbd/scons/overview >> >> I figured I'd get some opinions first before submitting a pull request. >> I'm not sure if the feature follows the Scons way of doing things, >> although I think it might allow for more organisation within the Tools >> directory >> I'd appreciate any feedback on if folks think this is a good or bad idea >> etc, I've included some details below on how it works. >> The general gist of it is, this will allow for dotted or nested Tools >> without the need for additional toolpaths. >> To give some examples >> >> ``` >> env = Environment(ENV = os.environ, tools = ['Dir1.Dir2.SomeTool']) >> env.SomeTool(targets, sources) >> ``` >> will search for the tool from >> SCons\Tool\Dir1\Dir2\SomeTool.py or SCons\Tool\Dir1\Dir2\SomeTool\ >> __init__.py >> >> For a couple of use cases: >> >> I've noticed cmake has a large nubmer of find modules for finding library >> / header paths for different libraries >> such as 'FindDoxygen' or 'FindCUDA' for example. >> If some of these were written for scons, you could bundle them all into a >> Finders sub-directory for 'Finders.FindDoxygen', 'Finders.FindCUDA' etc >> >> Another example would be the MSBuild related builders >> I wouldn't want to interfere with the existing builders already there, >> but as a hypothetical example >> for a single tool 'MSBuild.MSVC' or 'MSBuild.DotnetCore' for example >> which would map to SCons\Tool\MSBuild\MSVC.py or >> SCons\Tool\MSBuild\DotnetCore.py >> for all MSBuild related tools you could use 'MSBuild' which would map to >> SCons\Tool\MSBuild\__init__.py which might pull in all tools in that >> directory. >> >> For existing tools, the behaviour should be exactly the same as before. >> so SomeTool will map to SCons\Tool\SomeTool.py or >> SCons\Tool\SomeTool\__init__.py which is the current behaviour >> >> There's also a small fix in there for the python3 code when loading a >> Tool as a package >> I found this was needed under Windows at least, it's the line >> ``` >> file_package = os.path.join(file_package, '__init__.py') >> ``` >> >> So far I've tested this under python2 and python3 with different forms of >> Tool names. >> and under Linux (Ubuntu Mate VM) and Windows 10, using tools local to >> Scons build dir and as part of a toolpath externally such as scons-contrib >> >> I've run the fill tests with "runtest.py -a -o test.log" >> then compared the output of unpatched vs patched sources for any >> differences (non so far) >> I can attach those on a follow up mail if needed >> >> Many Thanks, >> Richard >> >> _______________________________________________ >> Scons-users mailing list >> [email protected] >> https://pairlist4.pair.net/mailman/listinfo/scons-users >> >> >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
