[Scons-users] Just abandoned an attempt to subclass Node.FS.Dir() .. alternative?

[Matthew Swabey]

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?

Matthew

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,
>
> Dirk
>
> _______________________________________________
> 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/20141209/bf2e9c39/attachment-0001.html>