[Scons-users] SCons.Node.Python.Value on target_factory

[Philipp Kraus]

Am 08.04.2013 um 07:33 schrieb Gary Oberbrunner:


> 

> 

> 

> On Sun, Apr 7, 2013 at 9:42 PM, Philipp Kraus <philipp.kraus at flashpixx.de> wrote:

> 

> Am 08.04.2013 um 03:11 schrieb Bill Deegan:

> 

>> Any reason your not just doing Execute(your_actions)?

>> Are you using the dependencies? It looks like not.

>> Unless I'm misunderstanding, you just want an alias to run some commands for you.

> 

> The discussion goes off-topic, please forgot the previous discussion and take a look to this example only:

> 

> ------------

> import SCons.Action

> 

> env = Environment()

> 

> env["BUILDERS"]["WithPyValue"]    = SCons.Builder.Builder( action = SCons.Action.Action("echo testbuild 1"),    source_factory = SCons.Node.FS.File, target_factory = SCons.Node.Python.Value )

> env["BUILDERS"]["WithoutPyValue"] = SCons.Builder.Builder( action = SCons.Action.Action("echo testbuild 2"), source_factory = SCons.Node.FS.File )

> 

> 

> env.WithPyValue("target1", "source1")

> # env.WithoutPyValue("target2", "source2") 

> ---------------

> 

> 

> In this case my system produce:

> 

> scons: Building targets ...

> scons: `.' is up to date.

> scons: done building targets.

> 

> IMHO it should produce an error "source1" not exists, but in this case it should be the default target.

> 

> 

> Probably you're not using the generated python value (returned by WithPyValue) anywhere.  SCons by default builds all filesystem targets under '.'. Your target (a Value) is not a file under . so SCons doesn't think it needs to be built.


Ah, that's the answer, so where / why you need this typ of node, if you used primary file nodes? Which is the main use for this Node type (way needs Scons this node type)?
Did I understand it correct, that the Python.Value is something like a glue node between, for pushing "any" Python data to the action command ?

For some explantion: I see a build process as an abstract question "I know a  build and I need some information how it can be build". My build process is describe by a dependency (directed) graph eg an adjacence list / (symmetric) matrix
which creates the dependency information of my parts of the build process. This graph must be without any cycles, so I can find one unique way from a target node to the a node which is needed by the target.
Each node in the build process has got a information eg a flah it is build or not, and where the node stores their information. So I can get run through the target node to all depended nodes and can ask the node for building.

Scons creates the depency graph with the emitter, because the emitter describe in which way one node is transformed by the build process to another. The builder runs after the emitter and builds the node physically. 

So in my thinking I see a depency graph with nodes, for the graph it is irrelevant which type the node is (eg file, pseudo, URL). Because I can not create a directed graph in practice, because I need a undirected graph, I need the information
how I can run from target to the leaf nodes, but also I need the information how I can run from leaf to target, so I need a undirected graph. The graph stores the nodes and nodes can be any build information which connects two other nodes. 
This connection is describe by the emitter. The target / alias is a pointer to a special node (the root node in a build way). Scons calls this root node and goes recursive down to the leaf nodes and goes back to the root by calling the emitter to
create the full dependency graph, after that the builder is on each node is run.

I have spoken from graph nodes, for the build process it is irrelevant, which content the node representats. In practice I need this information eg it can be a file or dir or Python.Value. So I would create a abstract class "node" and create child classes eg filenode, pythonvalue, .... and on this also node.filenode.file, node.pythonvalue.int, .... So I can build my graph and ask each node if it exists or not. The emitter knows, which nodes are be created and the builder know how to handle them. 
In this abstract view I can create a "pseudo node" or an "URL node", because an URL node is a child of a node.python.value.string, stores a string (for the URL). The emitter knows eg how to transform this string into eg a file

I try to understand why primary file nodes used by scons, I think I see the build process more theoretically but Scons do it more practical, seems to be a mistake myself. Scons seems to work on physical existing file & dir nodes, so a creating of a pseudo node or URL node is very difficult, because the core for building must be changed. 

For my example I expect, that a node, which is a Python.Value also build by default like a file node. 
The intention of my thread is exactly this problem, because I'm more theoretically and I have got some times problems to understand the practical build process of Scons.



> Try making it a dependency of something else:

>   foo=env.WithPyValue(...)

>   bar=env.Command(...)

>   Depends(bar, foo)

> or something like that.

> 

> But if you're making a source code builder, it may be instructive to learn (as Bill says) that SCons has had one for a long time, it never worked that well, and most people found it easier to just check out the source outside of SCons or just Execute() the source code commands.


In my case I use URLs (only a "parameter" for the action), so I need a target_factory type, which represents the URL. In this case I can not use a file node, optimal I need a new nodetype "URL". But in the build process such as a URL node, must be a "always build" flag, because Scons can not determine if the URL has been changed before the data is downloaded. 
I have got one process, that does not work with an Execute :-) because the execute can not return the file list which are checkout, so I run the checkout command and I hope I can do this by an emitter. 

Thanks

Phil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://four.pairlist.net/pipermail/scons-users/attachments/20130408/be8c6d60/attachment.html>