Design problem with Ptah - Journal of Omnifarious
Aug. 14th, 2005
12:38 am - Design problem with Ptah
A brief description of the design at this point:
I have nodes and builders. A node knows which other nodes it depends on, and it has a set of abstract attributes to describe that dependency that are set up as flags.
The dependency flags are MUST_EXIST, BUILT_FROM, and OUTDATED_BY. Here are there descriptions:
- This states that the depended upon node is used to build this node. It additionally implies a MUST_EXIST, and an OUTDATED_BY dependency.
- This dependency type says that the depended upon node must be built successfully for this node to be built. Being built successfully may simply entail checking to see if the file exists.
- This dependency says that if the depended upon node changes since the dependent node was last built, the dependent node should be built again. But it does not require the depended upon node to be successfully built. The change in state from 'buildable' to 'not-buildable' is one sort of change that can outdate something. Since the set of header files that are needed to build a .o file can change, this is the appropriate dependency for header files. If a header file changes or is removed, the .o file needs to be rebuilt, but if the .h file goes away that doesn't necessarily mean that the .o file is now not buildable.
A file node automatically has a MUST_EXIST dependency on the containing directory. This allows you to easily arrange for directories to be created for copying header files to or building .o files into.
There is a bit of magic surrounding file nodes. If you construct a file node for a particular path, it will always be the same object.
A node also knows what builder object is supposed to be used to build it. The builder objects follow the flyweight pattern. All the .o nodes that build a .o file from a .c file may use the exact same builder object.
Here's my problem...
How do I handle tools like
flex with this structure?
flex takes in a .l file describing a lexer and produces a .h file with
#defines for all the lexemes and a .c file containing the lexer itself. This can be described by the dependency graph just fine, but it's hard to describe how the .c and .h files are built because a builder isn't supposed to know which nodes it's operating on until it's invoked, and then it's only told what node it's building. The .c and .h files are sibling nodes that don't really know about each other.