[Cook] Help wanted with unorthodox use of cook

[Reuben Thomas]

On Fri, 2 Mar 2007, Pendergraft, Jerry wrote:

> Yes cook can do the things you want. And I'd be happy to contribute some 
> cook fragments.

Great!

> But it is not clear from this email what your process is beyond include 
> dependencies?

Basically nothing, except that building involves expanding them.

> Are you producing "output" html files with the includes expanded in them?

Yes.

> If so then those are your build product and cook just needs to know when 
> to re-build them based on calculated dependencies. And if that process 
> uses something like -I/a/b/c to find the includes, it will be quite simple 
> to deal with.

The main point here is that the include path is always implicit in the path 
of the page you're building relative to the root of the tree, as I attempted 
to explain in my previous email: when searching for a particular include 
"inc" in directory "./foo/bar/baz", the implicit include path in C notation, 
assuming that you search the left-most directory first, is:

-Ifoo/bar/baz -Ifoo/bar -Ifoo I.

Is that clear now?

> The cook features that can help with this is "cascade dependencies", and 
> the resolve function. It can also support a baseline and change structure 
> so you need not have all sources in the same directory tree.

Thanks for the pointers.

Now what I'm wondering is whether I have to supply an include program to 
scan the tree, find the includes, and output all the dependencies, or 
whether I can cheat somehow. There seem to be three "special" things to do:

1. Parse my particular include syntax (I use $include{filename}). As far as 
I can see I can't get c_incl to do this without risking false positives.

2. Generate the dependencies for a particular built file. This is not quite 
as simple as scanning its current includes, as the introduction of a new 
file can change them, so it depends on directories on its search path as 
well as the files that currently get included. I'm not sure if c_incl 
handles this, but it should: for example suppose you have:

-I/usr/include -I/usr/local/include

and suppose that one of the files you depend on is "libgui.h", found in 
/usr/local/include. Now suppose you install /usr/include/libgui.h. The 
dependent should be rebuilt, as this new libgui.h supercedes the old one by 
virtue of the path ordering. Similar things happen in my system (you can 
specialise a file by pushing it down the directory path towards the leaf).

3. Expand the includes. Since by now you've calculated exactly which files 
get included by each $include command, it seems a pity not to use the 
information; to do this you need a map somewhere of "foo" -> 
"/full/path/to/foo".

I feel like I'm making a mountain out of a molehill, so I suspect the next 
iteration is to try writing some code and to be told I'm doing completely 
the wrong thing, rather than to try to work everything out ahead of time. 
Still, I'll wait for your comments on the above first.

thanks,

Reuben

-- 
http://rrt.sc3d.org/ | aphorism, n.  a wise lie