I've checked in some changes to various portions of the module build code. It doesn't look like i've broken anything yet, but if everyone could keep an eye out for problems, that would be great.
Also, while it seems to work well in the pike tree and for the very simple cases i've thrown at it, it doesn't yet install the modules it has prepared into the pike installation. It actually doesn't appear that the makefiles ever did that. Can someone comment on this situation? What was the plan for having pike -x module actually install the module it prepares?
Thanks in advance! Bill
dynamic_module_makefile contains an "install" target, which copies the .so file into the module directory of the installed pike. It looks like it only works for pikes installed with --traditional, though. There were probably never any code to install pike-parts of modules.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-10-29 21:04: Subject: module build process
I've checked in some changes to various portions of the module build code. It doesn't look like i've broken anything yet, but if everyone could keep an eye out for problems, that would be great.
Also, while it seems to work well in the pike tree and for the very simple cases i've thrown at it, it doesn't yet install the modules it has prepared into the pike installation. It actually doesn't appear that the makefiles ever did that. Can someone comment on this situation? What was the plan for having pike -x module actually install the module it prepares?
Thanks in advance! Bill
/ Brevbäraren
The install target doesn't seem to be used during the build/install of pike proper. I will therefore make the bold statement that it should be used during the build and installation of external modules, and will proceed to rework it with that in mind. I don't think we need a separate local_install target, as we can just pass the destination directory on the make command.
Speaking of the destination, what's the most reliable way of finding the system module directory? master()->pike_module_path[-1] seems to be the right location when PIKE_MODULE_PATH is also set. Anyone have information to the contrary?
Bill
I don't think we need a separate local_install target, as we can just pass the destination directory on the make command.
It would still be convenient, and it would help enforce some kind of de-facto standard location for locally installed modules, so that one reasonably can assume that it's, say, $HOME/pike-modules and not $HOME/pike/local_modules or $HOME/PikeStuff or whatever. If nothing else, it's useful to have a common term to talk about.
Speaking of the destination, what's the most reliable way of finding the system module directory?
The same way Tools.Standalone.module finds out the include directory. I.e. you should extend the master to store lib_prefix in a separate variable. Preferably it should be possible to query it too with pike -x module.
I see there's a share_prefix too which is intended for architecture independent data, i.e. undumped modules. Can't find any installation method that installs there, though.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-30 06:10: Subject: Re: module build process
The install target doesn't seem to be used during the build/install of pike proper. I will therefore make the bold statement that it should be used during the build and installation of external modules, and will proceed to rework it with that in mind. I don't think we need a separate local_install target, as we can just pass the destination directory on the make command.
Speaking of the destination, what's the most reliable way of finding the system module directory? master()->pike_module_path[-1] seems to be the right location when PIKE_MODULE_PATH is also set. Anyone have information to the contrary?
Bill
/ Brevbäraren
It would still be convenient, and it would help enforce some kind of de-facto standard location for locally installed modules, so that one reasonably can assume that it's, say, $HOME/pike-modules and not $HOME/pike/local_modules or $HOME/PikeStuff or whatever. If nothing else, it's useful to have a common term to talk about.
ok. you have convinced me of the folly of my ways :) what do you think the recommended local location should be?
$HOME/lib/pike/modules $HOME/pike/modules
on OSX, every user gets $HOME/Library, so perhaps the best place isn't the same for each system...
The same way Tools.Standalone.module finds out the include directory. I.e. you should extend the master to store lib_prefix in a separate variable. Preferably it should be possible to query it too with pike -x module.
ok. i'll look into that.
I see there's a share_prefix too which is intended for architecture independent data, i.e. undumped modules. Can't find any installation method that installs there, though.
at one point, weren't compiled modules and pure pike files kept in separate locations?
Bill
$HOME/lib/pike/modules $HOME/pike/modules
I think $HOME/pike-modules would be ok. It shouldn't be several directory levels, at least; in 95% of the cases it'd only be extra steps one would have to go through.
on OSX, every user gets $HOME/Library, so perhaps the best place isn't the same for each system...
Maybe not, but a standard place regardless of platform is clearly useful otoh. Would there be a tangible benefit placing it in that directory on OS-X?
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-30 18:10: Subject: Re: module build process
It would still be convenient, and it would help enforce some kind of de-facto standard location for locally installed modules, so that one reasonably can assume that it's, say, $HOME/pike-modules and not $HOME/pike/local_modules or $HOME/PikeStuff or whatever. If nothing else, it's useful to have a common term to talk about.
ok. you have convinced me of the folly of my ways :) what do you think the recommended local location should be?
$HOME/lib/pike/modules $HOME/pike/modules
on OSX, every user gets $HOME/Library, so perhaps the best place isn't the same for each system...
The same way Tools.Standalone.module finds out the include directory. I.e. you should extend the master to store lib_prefix in a separate variable. Preferably it should be possible to query it too with pike -x module.
ok. i'll look into that.
I see there's a share_prefix too which is intended for architecture independent data, i.e. undumped modules. Can't find any installation method that installs there, though.
at one point, weren't compiled modules and pure pike files kept in separate locations?
Bill
/ Brevbäraren
On Thu, Oct 30, 2003 at 07:55:04PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
on OSX, every user gets $HOME/Library, so perhaps the best place isn't the same for each system...
Maybe not, but a standard place regardless of platform is clearly useful otoh. Would there be a tangible benefit placing it in that directory on OS-X?
yes, less clutter, and less iritation for the user. i hate it how hundreds of apps place stuff in my homedir with sometimes making it hard to know which file belongs to which app.
on macosx at least all that mess disappears in a subdirecory. (and it's less messy, because each app has it's own subdirectory)
hence on macosx there can only be one good place: $HOME/Library/Pike/
for the same reason i do not like $HOME/pike-modules/ or $HOME/pike/ chances are that i already have a directory like that to maintain my own code and don't want pike to accidently overwrite anything there.
my point is, we can't just pick a directory and use it. if we pick a directory we must check if it doesn't exist already, otherwise abort. in general i prefer asking the user to specify a directory.
greetings, martin.
Of course it should be possible to use something else. The point with a preferred place is primarily that it gives a well-known name to talk about - one can say for instance "check in your ~/pike-modules directory" instead of "check in the directory where you've chosen to have pike modules in your home directory". Even if someone actually using a different directory he will still know what is meant.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-30 20:31: Subject: Re: module build process
On Thu, Oct 30, 2003 at 07:55:04PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
on OSX, every user gets $HOME/Library, so perhaps the best place isn't the same for each system...
Maybe not, but a standard place regardless of platform is clearly useful otoh. Would there be a tangible benefit placing it in that directory on OS-X?
yes, less clutter, and less iritation for the user. i hate it how hundreds of apps place stuff in my homedir with sometimes making it hard to know which file belongs to which app.
on macosx at least all that mess disappears in a subdirecory. (and it's less messy, because each app has it's own subdirectory)
hence on macosx there can only be one good place: $HOME/Library/Pike/
for the same reason i do not like $HOME/pike-modules/ or $HOME/pike/ chances are that i already have a directory like that to maintain my own code and don't want pike to accidently overwrite anything there.
my point is, we can't just pick a directory and use it. if we pick a directory we must check if it doesn't exist already, otherwise abort. in general i prefer asking the user to specify a directory.
greetings, martin.
/ Brevbäraren
yes, less clutter, and less iritation for the user. i hate it how hundreds of apps place stuff in my homedir with sometimes making it hard to know which file belongs to which app.
good point
hence on macosx there can only be one good place: $HOME/Library/Pike/
my point is, we can't just pick a directory and use it.
well, we can pick reasonable defaults, and i think that $HOME/Library/Pike is a good place to start for osx, for others, that remains to be decided. from there, it would be good to have an easy way to change this; perhaps as an argument to pike -x module.
I'm not strongly opposed to $HOME/pike-modules, but if every app did that, it would be a mess :) at the very least, it should be simple to override by an end user.
Maybe not, but a standard place regardless of platform is clearly useful otoh. Would there be a tangible benefit placing it in that directory on OS-X?
besides being a relatively logical location, it prevents cluttering up the home directory of non-wizards...
Bill
Every app already does that, I would say. But that's for configuration files. This is not quite so bad since it's one place that's shared by all modules.
besides being a relatively logical location, it prevents cluttering up the home directory of non-wizards...
It would otoh defeat this way to establish a canonical term. Well, that can probably be done through other means.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-30 20:40: Subject: Re: module build process
I'm not strongly opposed to $HOME/pike-modules, but if every app did that, it would be a mess :) at the very least, it should be simple to override by an end user.
Maybe not, but a standard place regardless of platform is clearly useful otoh. Would there be a tangible benefit placing it in that directory on OS-X?
besides being a relatively logical location, it prevents cluttering up the home directory of non-wizards...
Bill
/ Brevbäraren
I see there's a share_prefix too which is intended for architecture independent data, i.e. undumped modules. Can't find any installation method that installs there, though.
The share_prefix is used during the build-phase by the master.pike for the uninstalled pike.
/ Henrik Grubbström (Lysator)
Previous text:
2003-10-30 14:03: Subject: Re: module build process
I don't think we need a separate local_install target, as we can just pass the destination directory on the make command.
It would still be convenient, and it would help enforce some kind of de-facto standard location for locally installed modules, so that one reasonably can assume that it's, say, $HOME/pike-modules and not $HOME/pike/local_modules or $HOME/PikeStuff or whatever. If nothing else, it's useful to have a common term to talk about.
Speaking of the destination, what's the most reliable way of finding the system module directory?
The same way Tools.Standalone.module finds out the include directory. I.e. you should extend the master to store lib_prefix in a separate variable. Preferably it should be possible to query it too with pike -x module.
I see there's a share_prefix too which is intended for architecture independent data, i.e. undumped modules. Can't find any installation method that installs there, though.
/ Martin Stjernholm, Roxen IS
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Baehr -
Martin Stjernholm, Roxen IS ＠ Pike developers forum