[Scons-dev] Why not merge SCons.Util.NodeList into SCons.Node.NodeList?

[Mats Wichmann]

On 8/7/22 16:03, Ryan Saunders wrote:
> Hello,
> 
> I am working on a tool integrating vcpkg into SCons, and I've hit a
> curious feature of SCons architecture. Specifically, I would like to be
> able to do the following:
> 
> dlls = []
> dlls += env.VCPkg('packagename').SharedLibraries()
> 
> My "target" type from the VCPkg builder is a custom class that exposes a
> SharedLibraries() function. But the actual return type of calling
> env.VCPkg(...) is a SCons.Node.NodeList, which has essentially no
> functionality. If it were a SCons.Util.NodeList instead, then I'd be
> able to do this, as the "Util" version has the ability to invoke methods
> on its contents and return a new NodeList containing the result.
> 
> Questions:
> 
>  1. Is there a way for me to force SCons to return my targets in a
>     Util.NodeList?
>  2. Why does SCons.Util.NodeList even exist as a distinct type from
>     SCons.Node.NodeList? It seems like the functionality of
>     SCons.Util.NodeList could be merged into SCons.Node.NodeList, and
>     then you'd have just one, more useful class.
>  3. If the answer to (2.) is "because no one's done it", shall I send a PR?

Hi, Ryan - thanks for dropping in.

I submitted a PR to merge these a while back, as it seemed brainless to
me too.

However, I had trouble convincing myself it wouldn't have an impact, or
perhaps alternatively, that joining them would actually have a benefit,
which is a consideration, too, in an under-resourced project.

So the answer to (2) is *not* "because no one's done it", and yet...

You could amuse yourself with this:

https://github.com/SCons/scons/pull/3992

At last glance, it didn't like the idea of being rebased, I don't recall
how tricky that ended up looking.

If you have really good reasons, maybe this is worth resurrecting.