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
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
