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
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)
- 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
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
Yes, we agree. (But please, don't attach the message you reply to on this list.)
/ Martin Nilsson (Åskblod)
Previous text:
2003-01-27 02:45: Subject: Re: Module system and building modules (was Bz2)
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
/ Brevbäraren
On Mon, Jan 27, 2003 at 03:25:01AM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum wrote:
Yes, we agree. (But please, don't attach the message you reply to on this list.)
this actually goes for the exporter too. it keeps attaching the previous message unnecessarily...
greetings, martin.
Well, it isn't that wrong in that direction. By custom, LysKOM messages rarely quotes the messages they respond to (typically only when a message contains several different issues and one wish to link the responses to each of them) while normal email almost always quotes. Therefore it's reasonable that the exporter adds quotes to the messages written in LysKOM. It ought to strip excessive quotes from the emails it imports too, but I guess it's a bit difficult to come up with good heuristics for that.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-27 10:27: Subject: attaching messages (was: Module system and building modules (was Bz2))
On Mon, Jan 27, 2003 at 03:25:01AM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum wrote:
Yes, we agree. (But please, don't attach the message you reply to on this list.)
this actually goes for the exporter too. it keeps attaching the previous message unnecessarily...
greetings, martin.
/ Brevbäraren
On Mon, Jan 27, 2003 at 07:05:03PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Well, it isn't that wrong in that direction. By custom, LysKOM messages rarely quotes the messages they respond to (typically only when a message contains several different issues and one wish to link the responses to each of them) while normal email almost always quotes. Therefore it's reasonable that the exporter adds quotes to the messages written in LysKOM.
it is not reasonable.
first, appending the old message is hated and depreciated on almost all mailinglists i know. quoting is done, but NOT the way the exporter does it. therefore this does not really solve what you are trying to solve.
second the style whether things are quoted at all or not has nothing to do with wether you use a lyskom client or an email client, but it depends on the consensus of the forum.
the consensus of this forum (and all lyskom forums) is, to hardly ever quote anything. this consensus is fine, and email users should be expected to follow that consensus, and don't need special treatment.
another assumption you make is, that email readers are unable to look up old mails. this will only be true if they delete all read mails. but then they have only themselves to blame. lyskom is a system where messages are stored for unlimited time, and i'd expect email users to accept that they will need to store their own copies if they want to be able to read old messages like lyskom users are able to.
note that, being an email user myself i am not expecting from anyone anything more than from myself.
greetings, martin. ps: it is interresting to note that the message handling in lyskom is very similar to that in sTeam (www.open-steam.org). if there was a Protocols.Lyskom.Server, then we could turn sTeam into a lyskom server, and have lyskom completely in pike :-)
Changing export format is a possibility. Exporting to two lists, with and without the commented text is another. Does anyone like the added quotation at the end? (That would argue for the second option.)
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-01-27 19:47: Subject: Re: attaching messages (was: Module system and building modules (was Bz2))
On Mon, Jan 27, 2003 at 07:05:03PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Well, it isn't that wrong in that direction. By custom, LysKOM messages rarely quotes the messages they respond to (typically only when a message contains several different issues and one wish to link the responses to each of them) while normal email almost always quotes. Therefore it's reasonable that the exporter adds quotes to the messages written in LysKOM.
it is not reasonable.
first, appending the old message is hated and depreciated on almost all mailinglists i know. quoting is done, but NOT the way the exporter does it. therefore this does not really solve what you are trying to solve.
second the style whether things are quoted at all or not has nothing to do with wether you use a lyskom client or an email client, but it depends on the consensus of the forum.
the consensus of this forum (and all lyskom forums) is, to hardly ever quote anything. this consensus is fine, and email users should be expected to follow that consensus, and don't need special treatment.
another assumption you make is, that email readers are unable to look up old mails. this will only be true if they delete all read mails. but then they have only themselves to blame. lyskom is a system where messages are stored for unlimited time, and i'd expect email users to accept that they will need to store their own copies if they want to be able to read old messages like lyskom users are able to.
note that, being an email user myself i am not expecting from anyone anything more than from myself.
greetings, martin. ps: it is interresting to note that the message handling in lyskom is very similar to that in sTeam (www.open-steam.org). if there was a Protocols.Lyskom.Server, then we could turn sTeam into a lyskom server, and have lyskom completely in pike :-)
/ Brevbäraren
I and Henrik Rindlöw started writing a threaded lyskom server in pike several years ago. The code probably suffers some bitrot.
/ Niels Möller ()
Previous text:
2003-01-27 19:47: Subject: Re: attaching messages (was: Module system and building modules (was Bz2))
On Mon, Jan 27, 2003 at 07:05:03PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Well, it isn't that wrong in that direction. By custom, LysKOM messages rarely quotes the messages they respond to (typically only when a message contains several different issues and one wish to link the responses to each of them) while normal email almost always quotes. Therefore it's reasonable that the exporter adds quotes to the messages written in LysKOM.
it is not reasonable.
first, appending the old message is hated and depreciated on almost all mailinglists i know. quoting is done, but NOT the way the exporter does it. therefore this does not really solve what you are trying to solve.
second the style whether things are quoted at all or not has nothing to do with wether you use a lyskom client or an email client, but it depends on the consensus of the forum.
the consensus of this forum (and all lyskom forums) is, to hardly ever quote anything. this consensus is fine, and email users should be expected to follow that consensus, and don't need special treatment.
another assumption you make is, that email readers are unable to look up old mails. this will only be true if they delete all read mails. but then they have only themselves to blame. lyskom is a system where messages are stored for unlimited time, and i'd expect email users to accept that they will need to store their own copies if they want to be able to read old messages like lyskom users are able to.
note that, being an email user myself i am not expecting from anyone anything more than from myself.
greetings, martin. ps: it is interresting to note that the message handling in lyskom is very similar to that in sTeam (www.open-steam.org). if there was a Protocols.Lyskom.Server, then we could turn sTeam into a lyskom server, and have lyskom completely in pike :-)
/ Brevbäraren
On Mon, Jan 27, 2003 at 08:15:02PM +0100, Niels Möller () @ Pike (-) developers forum wrote:
I and Henrik Rindlöw started writing a threaded lyskom server in pike several years ago. The code probably suffers some bitrot.
oh, cool, i'd only need the protocol implementation, if that is not to complicated then the bitrod should be managable. could you share the code with me?
(not that i promise that i'll do anything with it, but you never know :-)
greetings, martin.
Do you mind if I tar up our old lyskomd-mkII code and stick a GPL or something on it?
Not sure if it's of much use, though.
/ Niels Möller ()
Previous text:
2003-01-27 23:31: Subject: Re: attaching messages (was: Module system and building modules (was Bz2))
On Mon, Jan 27, 2003 at 08:15:02PM +0100, Niels Möller () @ Pike (-) developers forum wrote:
I and Henrik Rindlöw started writing a threaded lyskom server in pike several years ago. The code probably suffers some bitrot.
oh, cool, i'd only need the protocol implementation, if that is not to complicated then the bitrod should be managable. could you share the code with me?
(not that i promise that i'll do anything with it, but you never know :-)
greetings, martin.
/ Brevbäraren
On Mon, Jan 27, 2003 at 11:45:04PM +0100, Niels Möller () @ Pike (-) developers forum wrote:
Do you mind if I tar up our old lyskomd-mkII code and stick a GPL or something on it?
no, go ahead, that would be excellent. gpl would be most suitable.
Not sure if it's of much use, though.
and as i said, not sure if i'll ever do something with it, but who knows :-)
greetings, martin.
<curious> Now - what is this beast? </curios>
/ Peter Lundqvist (disjunkt)
Previous text:
2003-01-28 00:28: Subject: Re: attaching messages (was: Module system and building modules (was Bz2))
On Mon, Jan 27, 2003 at 11:45:04PM +0100, Niels Möller () @ Pike (-) developers forum wrote:
Do you mind if I tar up our old lyskomd-mkII code and stick a GPL or something on it?
no, go ahead, that would be excellent. gpl would be most suitable.
Not sure if it's of much use, though.
and as i said, not sure if i'll ever do something with it, but who knows :-)
greetings, martin.
interested in doing pike programming, sTeam/caudium/pike/roxen training, sTeam/caudium/roxen and/or unix system administration anywhere in the world. -- pike programmer working in europe csl-gmbh.net open-steam.org (www.archlab|(www|db).hb2).tuwien.ac.at unix bahai.or.at iaeste.(tuwien.ac|or).at systemadministrator (stuts|black.linux-m68k).org is.(schon.org|root.at) Martin Bähr http://www.iaeste.or.at/~mbaehr/
/ Brevbäraren
which one? lyskomd-mkII or sTeam?
greetings, martin.
lyskomd-mkII
/ Peter Lundqvist (disjunkt)
Previous text:
2003-01-28 00:59: Subject: Re: attaching messages (was: Module system and building modules (was Bz2))
which one? lyskomd-mkII or sTeam?
greetings, martin.
/ Brevbäraren
Do you mind if I tar up our old lyskomd-mkII code and stick a GPL or something on it?
no, go ahead, that would be excellent. gpl would be most suitable.
The question was not directed at you. One of the drawbacks of using the email interface is that you couldn't see that though.
/ Peter Bortas
Previous text:
2003-01-28 00:28: Subject: Re: attaching messages (was: Module system and building modules (was Bz2))
On Mon, Jan 27, 2003 at 11:45:04PM +0100, Niels Möller () @ Pike (-) developers forum wrote:
Do you mind if I tar up our old lyskomd-mkII code and stick a GPL or something on it?
no, go ahead, that would be excellent. gpl would be most suitable.
Not sure if it's of much use, though.
and as i said, not sure if i'll ever do something with it, but who knows :-)
greetings, martin.
interested in doing pike programming, sTeam/caudium/pike/roxen training, sTeam/caudium/roxen and/or unix system administration anywhere in the world. -- pike programmer working in europe csl-gmbh.net open-steam.org (www.archlab|(www|db).hb2).tuwien.ac.at unix bahai.or.at iaeste.(tuwien.ac|or).at systemadministrator (stuts|black.linux-m68k).org is.(schon.org|root.at) Martin Bähr http://www.iaeste.or.at/~mbaehr/
/ Brevbäraren
Be my guest.
/ Henrik Rindlöw (korsar vägar)
Previous text:
2003-01-27 23:40: Subject: Re: attaching messages (was: Module system and building modules (was Bz2))
Do you mind if I tar up our old lyskomd-mkII code and stick a GPL or something on it?
Not sure if it's of much use, though.
/ Niels Möller ()
Ok, now available as
http://www.lysator.liu.se/~nisse/archive/lyskomd-mkII-0.0.tar.gz
I checked in a COPYING file and the STATUS.txt which seems to list unimplemented requests (when connecting with the elisp-client). Appearantly the code was written during autumn 1997.
Seems we wrote most of the comments in Swedish ;-)
/ Niels Möller ()
Previous text:
2003-01-28 07:33: Subject: Re: attaching messages (was: Module system and building modules (was Bz2))
Be my guest.
/ Henrik Rindlöw (korsar vägar)
On Tue, Jan 28, 2003 at 10:05:05AM +0100, Niels Möller () @ Pike (-) developers forum wrote:
http://www.lysator.liu.se/~nisse/archive/lyskomd-mkII-0.0.tar.gz
thank you!
Seems we wrote most of the comments in Swedish ;-)
i'll just usr the roxenchat interactive swedish to english translator for help then ;-)))
greetings, martin.
[This thread is obviously off topic now, but it's hard to continue elsewhere.]
The correspondence between email lists and quoting vs LysKOM conferences and lack of quoting is a good one, so that saying that the custom is related to the clients - or more accurately to the protocols - is not unreasonable.
True, I made an assumption about that email clients might not be able to look up the old messages. I was being defensive; assuming otherwise would rule out some clients. But if it's a policy of the email export list to require people to have such capable clients then it's of course fine to change the exporter.
Btw, in my opinion you quote a bit too much, especially since you're obviously aware that we like to avoid quoting here. E.g. in your response there I think your quote of my message was unnecessary.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-27 19:47: Subject: Re: attaching messages (was: Module system and building modules (was Bz2))
On Mon, Jan 27, 2003 at 07:05:03PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Well, it isn't that wrong in that direction. By custom, LysKOM messages rarely quotes the messages they respond to (typically only when a message contains several different issues and one wish to link the responses to each of them) while normal email almost always quotes. Therefore it's reasonable that the exporter adds quotes to the messages written in LysKOM.
it is not reasonable.
first, appending the old message is hated and depreciated on almost all mailinglists i know. quoting is done, but NOT the way the exporter does it. therefore this does not really solve what you are trying to solve.
second the style whether things are quoted at all or not has nothing to do with wether you use a lyskom client or an email client, but it depends on the consensus of the forum.
the consensus of this forum (and all lyskom forums) is, to hardly ever quote anything. this consensus is fine, and email users should be expected to follow that consensus, and don't need special treatment.
another assumption you make is, that email readers are unable to look up old mails. this will only be true if they delete all read mails. but then they have only themselves to blame. lyskom is a system where messages are stored for unlimited time, and i'd expect email users to accept that they will need to store their own copies if they want to be able to read old messages like lyskom users are able to.
note that, being an email user myself i am not expecting from anyone anything more than from myself.
greetings, martin. ps: it is interresting to note that the message handling in lyskom is very similar to that in sTeam (www.open-steam.org). if there was a Protocols.Lyskom.Server, then we could turn sTeam into a lyskom server, and have lyskom completely in pike :-)
/ Brevbäraren
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
On Sunday, January 26, 2003, at 08:00 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
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.
Ahh, I see, though isn't there a potential for name clash with AC_*? It wasn't at all clear to me that this system even existed. How exactly is it supposed to fit together (ie does someone have some files that use this method?)
dynamic_module_makefile defines such a set. But maybe it should be larger than what it is today.
I did have a quick look at that, and it seems to have the basics down (build, install, test, etc) that I'd consider critical.
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.
Thanks for the clarification... it seems to be more of a head start than I imagined.
Bill
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.
Ahh, I see, though isn't there a potential for name clash with AC_*?
I suppose, but it might be a little bit late to change the name now. The macro has had this name since pike 0.6.
It wasn't at all clear to me that this system even existed. How exactly is it supposed to fit together (ie does someone have some files that use this method?)
The whole point is that you don't have to "use this method" explicitly in any files; the files are exactly the same as when you compile in the main pike build tree.
dynamic_module_makefile defines such a set. But maybe it should be larger than what it is today.
I did have a quick look at that, and it seems to have the basics down (build, install, test, etc) that I'd consider critical.
There were some others like "uninstall" mentioned though. Don't hesitate to think up more.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-27 02:37: Subject: Re: Module system and building modules (was Bz2)
On Sunday, January 26, 2003, at 08:00 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
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.
Ahh, I see, though isn't there a potential for name clash with AC_*? It wasn't at all clear to me that this system even existed. How exactly is it supposed to fit together (ie does someone have some files that use this method?)
dynamic_module_makefile defines such a set. But maybe it should be larger than what it is today.
I did have a quick look at that, and it seems to have the basics down (build, install, test, etc) that I'd consider critical.
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.
Thanks for the clarification... it seems to be more of a head start than I imagined.
Bill
/ Brevbäraren
Actually, now is probably as good a time as any to change AC_MODULE_INIT to PIKE_MODULE_INIT or something similar, since the module API has changed anyway.
/ Per Hedbor ()
Previous text:
2003-01-27 12:27: Subject: Re: Module system and building modules (was Bz2)
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.
Ahh, I see, though isn't there a potential for name clash with AC_*?
I suppose, but it might be a little bit late to change the name now. The macro has had this name since pike 0.6.
It wasn't at all clear to me that this system even existed. How exactly is it supposed to fit together (ie does someone have some files that use this method?)
The whole point is that you don't have to "use this method" explicitly in any files; the files are exactly the same as when you compile in the main pike build tree.
dynamic_module_makefile defines such a set. But maybe it should be larger than what it is today.
I did have a quick look at that, and it seems to have the basics down (build, install, test, etc) that I'd consider critical.
There were some others like "uninstall" mentioned though. Don't hesitate to think up more.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Hm. Point taken. I suppose we can leave the old name as an alias for backwards compatibility.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-27 12:50: Subject: Re: Module system and building modules (was Bz2)
Actually, now is probably as good a time as any to change AC_MODULE_INIT to PIKE_MODULE_INIT or something similar, since the module API has changed anyway.
/ Per Hedbor ()
On Sun, Jan 26, 2003 at 07:46:45PM -0500, Bill Welliver wrote:
hilfe> Tools.PPAN()->install("Protocols.OpenSSL", "1.2");
actually CPAN is "Comprehensive Perl Archive Network"
a "comprehensive pike archive network" would be CPAN as well, so we need to come up with a completely different name.
greetings, martin.
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
Henrik Rindl�w (korsar v�gar) ＠ Pike (-) developers forum -
Johan Sundstr�m (a hugging punishment!) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Baehr -
Martin Nilsson (�skblod) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Niels M�ller () ＠ Pike (-) developers forum
-
Per Hedbor () ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum
-
Peter Lundqvist (disjunkt) ＠ Pike (-) developers forum