[Scons-users] SCons Tools maintenance

Luke Tunmer luke.tunmer at gmail.com
Thu Nov 9 07:34:12 EST 2017


I have developed a regular Python package that when imported into an
SConstuct file, looks for other SCons Python packages using the
entry_points mechanism of setup tools. It then calls each of these entry
points to get the Tools path that will allow tools to be found when they
are added to an environment. This means that these extensions just have to
be installed into the virtualenv from which the scons is running. This is
done by having a requirements.txt file that lists all the SCons extensions
tools needed for the product or component.

Then we have an internal devpi server which allows these SCons extension
packages to be found.

I would like one day to see SCons directly support the idea of entry_point
extensions, which seems to used increasingly as a means to introduce
plugins into larger frameworks.

Regards
Luke


On 9 November 2017 at 11:33, Nacho Piqueras <natxo.piq at gmail.com> wrote:

> Hello all,
>
> Even if it is a not very much documented feature, I find SCons' Tools one
> of the most powerful concepts to arrange a build that involves several code
> transformations. In our projects we use a lot of 3rd party code generators
> and we wrap them into SCons tools to bring their functionality to the build
> environment.
>
> The problem we face is that tools packages are distributed per project.
> Currently all SCons tools that are required for a specific project are
> included into a site-tools folder inside that project. Being this way, we
> have the source code distribution problem: sometimes the code for a tool
> drifts from one project to another and it is difficult to track
> bugs/improvements through projects.
>
> Because scons tools are really coupled with the tool they wrap we could
> try to distribute the python package with the tool (the code generator),
> but this is not always possible. Fresh install of a tool does not bring the
> scons tool with it.
>
> Also, we would like to unit test the code of a tool. This involves mocking
> a scons environment somehow... for at least testing that the action would
> be correctly called, or the sequence of actions correctly arranged (scons
> tools' code often define scanners, emitters...). I still have not figured
> out how to do it.
>
> I would like to know how people using SCons distribute their SCons' tools
> code, how do you deal with this situation.
>
> For example, maybe we could package scons tools and install them with pip
> into a virtualenv created for a project...
>
> Many thanks for your thoughts on this question and for keeping SCons
> evolving.
>
>
> _______________________________________________
> 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/20171109/6fdc754e/attachment.html>


More information about the Scons-users mailing list