Actually, you're both correct. I worked on that macro as a project to write an autoconf script that installs a pike application, but the issues are still the same when talking about a pike module outside of the pike src tree:
1. identify the pike we want to compile/install for 2. find out where it expects to find its modules (/path/to/pike is often a symlink, so we have to follow that to it's source) 3. find out where its c includes are installed 4. make sure its a version that is supported by the "package", be it a pike c-module or a standalone pike app.
No matter how you end up deciding how to manage the namespace, you still have to worry about the problem of configuring, compiling and installing the modules, wherever they fit in the namespace.
My initial thoughts go something like this:
A pike module should contain an autoconf script that takes several well-defined arguments, such as the --with-pike arg that the macro I worked on defines.
Once the autoconf script is run, there should be a set of well defined make targets that build, test and install (and potentially uninstall) the module wherever it should go.
Once you define the "interface", how it gets implimented is less important, although you're presumably want to provide a "toolkit" for making it easier to create the required interface, along with the requisite docs (how do smartlink, precompile.pike work, etc?)
Once this consistent build/test/install method is available, you can think about how to automate the install process ala CPAN:
hilfe> Tools.PPAN()->install("Protocols.OpenSSL", "1.2");
PPAN: Finding Protocols.OpenSSL PPAN: Downloading Protocols.OpenSSL PPAN: Unpacking ...
and so on.
Or am I over-simplifying things?
Bill
9634015 talks about "packages that require pike", which presumably means other things than pike modules. In that case it might be something useful, although I can't at the moment think of anything that a simple AC_PATH_PROG(pike) wouldn't solve...
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-26 20:06: Subject: Re: Bz2
He made a short description of it in 9634015. I'm not familiar with the issue, so I can't say whether it solves the same problem.
/ Martin Stjernholm, Roxen IS