[Scons-users] Nested / namespaced Tools

[Bill Deegan]

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 <scons-users at scons.org>
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
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170615/4a93311c/attachment.html>