Re: [Scons-users] Nested / namespaced Tools

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 <bill-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org> 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