Well, I've read through your message three times, and I'm sorry to say, I'm still not sure what you're asking for help on. So the best I have to offer is some generic advice, which will hopefully help somewhat.

First of all, I was one of the first people to use 'jam', but I've been away from it for a couple of years, dumped back into the messy 'make' world during that time. So when I got back to 'jam', it took me awhile to get into it again. But that was because I'd forgetten one very important thing: if your rule (or even more basic, your approach) is getting overly complicated, you've done it wrong. Since remembering that, things have gone much better for me -- 'jam' really wants you to keep things simple.

The other thing I remembered was: use whatever's already there as much as you can, and if you can't use it directly, steal from it as much as you can.

Since I don't have an IDL compiler, and I've never used one, I don't know what it actually generates, but I suggest you look at how the yacc stuff is handled in Jambase, and see if you can use that as a template for your .idl files. Ultimately, what you want is pretty straightforward: to have your library depend on the .o's contained in it, and for them to depend on the generated .c's and .h's, which depend on the .idl's. That's not really different from a library built from .y's -- it just looks like you generate a few more .c's and .h's.

As for the #include'ing of other .idl files, I think you should be able to just use "HDRPATTERN" as is -- assuming the inclusion statement in these .idl files is a #include as usual. If not, you could reset "HDRPATTERN" for those files, or just add it as an OR to the pattern.

Well, I hope this helps a little anyway. If you haven't figured out an answer by now, here are the things I'd need to know: what does the IDL compiler generate (i.e., are the filenames predetermined, or assigned by you on the command-line), and why are you producing files you don't really need (how does that make things "simpler"); what does 'jam' currently do when you run it with the setup you have now (output is best); and what does it not do that you wanted it to (from your message, it seems that all it's not doing now is understanding that the generated .h's are dependencies, and if that's the case, I think you can fix that by just including them in the DEPENDS).

Diane (dia...@whistle.com)