[Scons-users] Just abandoned an attempt to subclass Node.FS.Dir() .. alternative?
mattaw at gmail.com
Tue Dec 9 14:39:40 EST 2014
So there isn't an easy way to subclass a Dir or File that I overlooked? Or
avoid duplicating tons of wrappers and other code to support a new node
that looks very like a Dir and a File?
The problem is ModelSim again:
vlib foo (create library foo which is a directory on the FS with an _info
file underneath and acquires new directories based on calls to other tools)
vcom bar.vhd -work foo (creates subdirs under foo per module in the file
using unpublished name mangling to do so)
vlog baz.sv -work foo (same but a different hardware language)
there is a vdir command to list the source files for an object and various
properties such as mtime etc from inside a library.
there is a vdel command to remove items from inside a library.
I want to create a type of Dir that has a builder to invoke vlib and does
its signature checking against the hash of the _info file (as it is updated
on every change).
I then want to create a type of File that has dependency information inside
it for a builder to figure out what to build first (the attributes) but
that the target is going to be the vlib directory as there is no equivalent
of a .o file.
I think rather than mess about with .stamp files in my current
implementation I would prefer a node that actually models what I want and
executes the necessary system functions to do it however new nodes are
rather a pain. I have found some documentation on them however as the
targets/sources are very similar to files and directories it makes sense to
me to try to use them.
Any more advice before I get stuck in?
On 9 December 2014 at 13:55, Dirk Bächle <tshortik at gmx.de> wrote:
> Hi Matthew,
> On 09.12.2014 14:07, Matthew Swabey wrote:
>> I just finished an attempt to subclass Node.FS.Dir() to be a Modelsim
>> library and the amount of code needing changes would probably be about 500
>> lines or more.
>> So forget that idea.
>> How about creating the Dir object and then appending attributes to
>> identify it, custom builders that will use and modify those attributes and
>> possibly adding some methods that can be used to manage how it works
>> (thinking of overriding the signature detection/generation)?
>> Then I could treat it as a Dir after instantiation (which is what most of
>> the code that needs changes is all about - how many wrappers!).
>> Thoughts? Potential pitfalls? I can imagine adding extra methods could be
>> dangerous because of the need to memoize them etc.
>> one potential pitfall would be the planned switch to using __slots__
> inside the Node class. So, adding methods will require you to derive from
> the base class and add "slots" for your new methods. When adding simple
> variables, please use the provided "Node.attributes" and attach your infos
> there (you may want to check the Java/c builder for an example)...this will
> stay during the refactoring.
> Best regards,
> Scons-users mailing list
> Scons-users at scons.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scons-users