I'm not sure I follow your comment; perhaps we agree . There definitely is a dependency- you can't have a system for finding, downloading, etc without having a consistent method for creating the modules in the first place. I was unaware that any efforts had been made to provide that method. In my mind, it's far more important to have a method for doing it than it is to have some pike code that automates the process for me (ala CPAN). I just wanted to throw my thoughts on that in as well.
Bill
On Sunday, January 26, 2003, at 07:55 PM, Martin Nilsson (Åskblod) @ Pike (-) developers forum wrote:
Though this is the most important part of the module system, there is really no dependency in any direction between this and the system for finding, downloading, verifying, etc modules.
/ Martin Nilsson (Åskblod)
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) 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
/ Brevbäraren