Hi Bill, # Current Search Mechanism
>From what I understand of the toolpath search mechanism it searches: 1. within scons\engine\SCons\Tool for the tools bundled with scons 2. A list of directories specified within the toolpath parameter 3. A variable called DefaultToolpath within the scons source (by default is empty) I checked experimentally and it looks as if the syspath is not included in the search for tools so I don't think it can pick up on modules at present when searching for tools. I've already added in the dot syntax in a prior commit to do something different The dot syntax is currently coded to search sub-directories within toolpaths so if you have a toolname like 'Test1.TestBuilder1' and a list of toolpaths like C:\Lib\toolpath1 C:\Lib\toolpath2 C:\Lib\toolpath3 The places it's going to search will be something like scons\engine\SCons\Tool\Test1\TestBuilder1 C:\Lib\toolpath1\Test1\TestBuilder1 C:\Lib\toolpath2\Test1\TestBuilder1 C:\Lib\toolpath3\Test1\TestBuilder1 I could change that around so that the dot means something else and use another character such as forward slash (pythonesque) as the directory separator instead. That might be a better idea # Overrinding For overriding, it's currently just currently adding to the toolpath parameter behind the scenes so the behaviour will be the same as that, I'm not sure how that works currently If toolpath overrides the inbuilt tools then this should work the same way # Suggested syntax There's a few different ways of changing the syntax around To give some examples of what I'm thinking based on what you've said 1. With the below example I've change the dot to a forward slash within the toolname "TestBuilder1" - look for tool in root of toolpath directory "ExampleDir1/TestBuilder1" - look for tool in sub-dir of toolpath directory "ExampleDir1/ExampleDir2/TestBuilder1" - look for tool in sub-dir of toolpath directory 2. This example uses a # prefix in the toolname to specify to use a python module as the base search directory (add to the toolpath) "scons_toollib_example#TestBuilder1" "scons_toollib_example.submod1#TestBuilder1" "scons_toollib_example#ExampleDir1/TestBuilder1" "scons_toollib_example#ExampleDir1/ExampleDir2/TestBuilder1" 3. We could also keep the toolmods option to avoid using a prefix as well all that will do is find the directory where the module is located and add that directory to the toolpath list Any thoughts? Many Thanks Richard On 20 July 2017 at 20:05, Bill Deegan <[email protected]> wrote: > Wouldn't this work and not require any changes? > Or if it doesn't already work, wouldn't that be easier syntax? no > additional arguments, if it's got a '.' in it then you know it's part of a > package? > > toollist = ['scons_toollib_example.TestBuilder1'] > env = Environment(ENV = os.environ, tools = toollist) > env.TestBuilder1('testdest1.txt', 'testsrc1.txt') > > How would you handle overloaded tool names in a module? > For example > scons_toollib_example has a gcc tool? > > -Bill > > > > On Thu, Jul 20, 2017 at 2:53 PM, RW via Scons-dev <[email protected]> > wrote: > >> Hi, >> One of the features I'm interested in is the ability to have tools loaded >> externally via a package installed via pip. >> This way if you wanted to, you could ether install tools as a separate >> repo via pip, or move some of the existing tools into separate repo's >> >> I think I've come up with a way to do it which doesn't involve much code. >> But before I add in any tests or additions to the man page / user docs I >> wanted to check if this is an okay way to implement this >> >> I've put the commit here: >> https://bitbucket.org/grbd/scons/commits/af3ea9f2d4468479f7f >> 7be73afd455b0f2067409 >> >> With this method there's an additional option on the environment >> constructor called toolmods >> >> ``` >> toollist = ['TestBuilder1'] >> env = Environment(ENV = os.environ, tools = toollist, toolmods = >> ['scons_toollib_example']) >> env.TestBuilder1('testdest1.txt', 'testsrc1.txt') >> ``` >> >> This option looks up the directory where the module is located in the sys >> path and adds it to the toolpath >> (e.g. C:\Python27\Lib\site-packages\scons_toollib_example) >> >> A side effect is that the module file gets imported at the same time >> (scons_toollib_example\__init__.py is run) >> I just do this to get the full path to the module when adding to the >> toolpath, although you could probably use that to modify scons or do >> something else when the tool is referenced if you wanted to. >> >> Is this implementation is a good idea? if so I'll look into adding some >> tests and user doc entries for it before doing a pull request >> >> Many Thanks >> Richard >> >> _______________________________________________ >> Scons-dev mailing list >> [email protected] >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> >> >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
