Hi Tim; Before going too much further note that I've got a semi-implemented "load" operator in my source already, which fulfills a similar function except in a less sophisticated way: it just calls a function in the loaded object after loading and that function can do whatever it wants.
I can send along a patch if you're interested in checking it out. I have some regression tests added, documentation, autoconf, etc. Boris and I discussed this on the alpha list a number of months ago and his position was that we should not try to restrict things. His suggestion was to follow the GCC model and just let people do what they wanted to. The downside of this is that we wouldn't be defining a big stable API: we would reserve the right to change things internally with every release, which would potentially break loadable objects. There are some outstanding issues: the first one is that I'd like the "load" operation to behave like the "include" operation, in that make would try to rebuild the target of the load and, if it were rebuilt, re-exec itself to reload it. That's not implemented yet. Second, the way in which the objects are found for loading. Do we just use the default dlopen() process? Or do something more (or less!) sophisticated? Finally, as you've noted in order for this to be useful generally we need to start publishing some header files. What goes into them and how they get published is something of an open question. It's possible that this will require a significant reworking of the current make header files (which would be OK with me since they're pretty messy currently). We could choose the public interface through what structures and functions we put into the publicly-facing header. The most obvious interface is "define a new function", but others could also be useful: eval, set variables, etc. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
