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.
Pike modules have autoconf scripts, yes. They should contain AC_MODULE_INIT, and any specific tests that the module code itself needs.
Which pike to compile for is determined by which pike you use to run `pike -x module' through.
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.
dynamic_module_makefile defines such a set. But maybe it should be larger than what it is today.
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?)
You don't have to worry about smartlink and precompile; smartlink is handled totally transparently, and for precompiled stuff you only need to make a dependency on the cmod file and dynamic_module_makefile will handle the rest.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-27 01:47: Subject: Module system and building modules (was Bz2)
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:
- identify the pike we want to compile/install for
- 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)
- find out where its c includes are installed
- 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
/ Brevbäraren