I've been fiddling with the existing build tools, as a precursor to a proposal for a module repository ala CPAN, and I've got a few observations:
1. It appears that as far as pike is concerned, C modules can reside anywhere in the module tree, as long as they're a .so file.
2. The dynamic module makefile, however, appears to have no provision for making modules that don't live at the root of the namespace
3. Similarly, the dynamic module makefile doesn't seem to want to deal with modules that either a) have no compiled module component, or b) have more than 1 pike file component, which is assumed to be called module.pmod.in and ends up as ModuleName.pmod, derived from the directory name that is being built in.
Can anyone comment on any of these statements? Would it be good to remove these limitations, or perhaps add an external_dynamic_module_makefile that does that?
Ideally, it would be good to have a method that handles these variations on the standard pike-distribution-module theme.
Also, I've got some other thoughts that anyone is welcome to comment on:
1. We should have a way to insert information into the modref when a new module is installed. This way, if I add a new module, the inline documentation is integrated with the existing modref. Now, I'm not very knowledgable on how this works, but I'm guessing that it would probably involve both installing documentation as part of the build procedure, along with some of the source [xml] files that would be needed to rebuild the documentation after inserting the new material.
2. In order to do an integrated module install/remove feature, we probably need a "receipts" store to keep track of what files belong to with modules, so we can be sure that we delete all of a module, or don't overwrite portions another module accidentally. Part of this could probably be accomplished by making a wrapper to mkdir,install,etc that added or removed entries from a contents file ala the solaris package manager.
Obviously, a CPAN for pike [with auto download-build-install] is really just icing on the cake. It's something that we really can't do without having a seamless module management experience, both for users and developers. I'm willing to put some time in on this, but I am hesitant to go mucking around with some of this stuff without getting a blessing from the full-time developers.
As always, comments and suggestions are welcome!
Bill