[Scons-dev] 2013+ projects

[Dirk Bächle]

Hi Gary,

thanks for compiling this list...it should keep us busy for the next 
three years or so. ;)
See my further comments below.

On 27.01.2013 23:26, Gary Oberbrunner wrote:

> Here's my ideas about what projects are important this year (and into 

> the future -- there's too much here for a year unless we attract some 

> new developers).  I put this out as food for thought, and to start 

> discussion -- I'm sure you will have different opinions, things I 

> haven't thought about.  Please chime in!

>

> SCons projects for 2013

>

>   * Toolchain revamp

>


Yes, this is important and gets my full support. About the goals of 
"decoupling tools from the core" and
"allowing tools to take args" I had the following ideas:

1.) We could try to establish a "contrib" or "add-on" folder in the 
SCons installation. In a separate repository (scons_contrib) we collect 
all the more recent (and stable) SCons Tools/Builders and ConfigChecks. 
A user can download this whole package and install it, which would place 
everything alongside the normal SCons install as it exists now.
By adding the "contrib" directory to Python's search path, it would be 
transparent to the user from where exactly he imports a Tool or a ConfCheck.
Sounds like additional work, and it probably is. But most of it can be 
automated I think...we could add the convention that external SCons 
Tools have to tag their stable revisions with "stable-x.y.z" and then 
pick the latest number as candidate for the "contrib" package.

2.) The default options of Tools, like name and path of an executable 
(miktex vs. pdftex) or the preferred detection order, could be stored in 
a config file (I'd suggest YAML format because it allows comments, in 
contrast to JSON).
The path search order for them would be the same like for the Tool 
modules themselves, such that users can override system settings by 
adding another config file in their private site_scons/site_tools 
directory. Just a half-baked idea so far...


>  *

>      o

>   * Node cleanup

>


I'd rather name this one "design cleanup". We should take a close look 
at our current architecture and try to improve it, this would probably 
also be helpful for documenting how SCons works internally (see also my 
latest pull request for pylint compliance). When it comes to optimizing 
for speed, the "subst" machine should be a top priority.
Anyway, +1 from me.


>   * Taskmaster

>       o not most important in 2013

>

Right, it's not the Taskmaster's fault...


>  *

>      o

>

>   * Python 3

>


Not so important for me personally, but I can understand the people who 
crave to have it. We should probably just dive in, give 2to3 a spin and 
see how big the problems really are.


Other things that might need attention:

- Cleanup after the switch to Mercurial. With this I mean saying 
"Goodbye" to our old workflows (e.g. bug party) and documenting this 
properly on the Wiki.
- Bug slashing, especially for all the (very) old documentation issues.
- Updating the web front page by replacing the comments of people/groups 
that aren't actually using SCons anymore.


So much for today, best regards,

Dirk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130204/1428f438/attachment-0001.html>