1. It appears that as far as pike is concerned, C modules can reside

anywhere in the module tree, as long as they're a .so file.

Correct.

2. The dynamic module makefile, however, appears to have no provision for

making modules that don't live at the root of the namespace

Not true in Pike 7.5. Use makefile variable MODDIR to specify the subdirectory.

3. Similarly, the dynamic module makefile doesn't seem to want to deal

with modules that either a) have no compiled module component, or b) have more than 1 pike file component, which is assumed to be called module.pmod.in and ends up as ModuleName.pmod, derived from the directory name that is being built in.

Correct. This is probably rather easy to fix in modules/common_module_makefile.in .

Ideally, it would be good to have a method that handles these variations on the standard pike-distribution-module theme.

I think there already are provisions for this. Marcus?

1. We should have a way to insert information into the modref when a new

module is installed. This way, if I add a new module, the inline documentation is integrated with the existing modref. Now, I'm not very knowledgable on how this works, but I'm guessing that it would probably involve both installing documentation as part of the build procedure, along with some of the source [xml] files that would be needed to rebuild the documentation after inserting the new material.

This is probably solved easiest by installing the full intermediate XML file autodoc.xml, and joining the new XML files to it. The autodoc tools are already installed, however the structure files currently aren't.

2. In order to do an integrated module install/remove feature, we probably

need a "receipts" store to keep track of what files belong to with modules, so we can be sure that we delete all of a module, or don't overwrite portions another module accidentally. Part of this could probably be accomplished by making a wrapper to mkdir,install,etc that added or removed entries from a contents file ala the solaris package manager.

This sounds like stuff to put in Tools.Standalone.module.

/ Henrik Grubbström (Lysator)

Previous text:

2003-08-19 18:08: Subject: module build/install procedure

---

I've been fiddling with the existing build tools, as a precursor to a proposal for a module repository ala CPAN, and I've got a few observations:

1. It appears that as far as pike is concerned, C modules can reside

anywhere in the module tree, as long as they're a .so file.

2. The dynamic module makefile, however, appears to have no provision for

making modules that don't live at the root of the namespace

3. Similarly, the dynamic module makefile doesn't seem to want to deal

with modules that either a) have no compiled module component, or b) have more than 1 pike file component, which is assumed to be called module.pmod.in and ends up as ModuleName.pmod, derived from the directory name that is being built in.

Can anyone comment on any of these statements? Would it be good to remove these limitations, or perhaps add an external_dynamic_module_makefile that does that?

Ideally, it would be good to have a method that handles these variations on the standard pike-distribution-module theme.

Also, I've got some other thoughts that anyone is welcome to comment on:

1. We should have a way to insert information into the modref when a new

module is installed. This way, if I add a new module, the inline documentation is integrated with the existing modref. Now, I'm not very knowledgable on how this works, but I'm guessing that it would probably involve both installing documentation as part of the build procedure, along with some of the source [xml] files that would be needed to rebuild the documentation after inserting the new material.

2. In order to do an integrated module install/remove feature, we probably

need a "receipts" store to keep track of what files belong to with modules, so we can be sure that we delete all of a module, or don't overwrite portions another module accidentally. Part of this could probably be accomplished by making a wrapper to mkdir,install,etc that added or removed entries from a contents file ala the solaris package manager.

Obviously, a CPAN for pike [with auto download-build-install] is really just icing on the cake. It's something that we really can't do without having a seamless module management experience, both for users and developers. I'm willing to put some time in on this, but I am hesitant to go mucking around with some of this stuff without getting a blessing from the full-time developers.

As always, comments and suggestions are welcome!

Bill

/ Brevbäraren

2. In order to do an integrated module install/remove feature, we probably

need a "receipts" store to keep track of what files belong to with modules, /.../

Compared to the other things you've mentioned, I think this is fairly unimportant and could be added later if/when there's an actual need. It seems like a bit of duplicate work since there often are tools for it in the distributions that many use. It could potentially even conflict with such packaging system. E.g. a Debian packaging would probably have a package for each module and using the internal install feature would then cause inconsistencies in the Debian package tracking, and perhaps vice versa.

The problem that different modules would overwrite files for each other doesn't seem like a big one to me, provided that they don't conflict in the module namespace. And managing the module namespace is a separate issue; Nilsson already has a suggestion about that.

Another problem worth mentioning regarding an integrated module installer is to deal with shared installations. I take it that the system would semi-automatically download and install the required modules when an application is started. The user that wants to run the application typically wouldn't have write permission to some centrally installed Pike. So the system has to be able to deal with modules installed locally for every user.

This issue is a real PIA with Mozilla Firebird extensions, for example. Some extensions can only be installed centrally (despite that their installers offer the option to install locally for the user; they simply don't work after that), some can only be installed locally for the user, and some won't work at all unless the user has the whole Firebird installation locally. I think the problem there is that too much freedom has been left to the extension writer, which essentially writes the installer himself. Apparently many of the developers only run with local installations and therefore haven't thought of this problem, or haven't tested their solutions in a shared environment.

I'm willing to put some time in on this, but I am hesitant to go mucking around with some of this stuff without getting a blessing from the full-time developers.

Sounds very good to me. If you have more technical issues I'm sure you'd get some input on them. (Personally I'd welcome a bit of cleanup and/or documentation of the module make system; every time I dig into those parts I have to spend a lot of time figuring out which configure/make variable comes from where and what the effect on an override really is. A change to a consistent naming scheme for those variables would probably make it a whole lot easier.)

/ Martin Stjernholm, Roxen IS

Previous text:

2003-08-19 18:08: Subject: module build/install procedure

---

I've been fiddling with the existing build tools, as a precursor to a proposal for a module repository ala CPAN, and I've got a few observations:

1. It appears that as far as pike is concerned, C modules can reside

anywhere in the module tree, as long as they're a .so file.

2. The dynamic module makefile, however, appears to have no provision for

making modules that don't live at the root of the namespace

3. Similarly, the dynamic module makefile doesn't seem to want to deal

with modules that either a) have no compiled module component, or b) have more than 1 pike file component, which is assumed to be called module.pmod.in and ends up as ModuleName.pmod, derived from the directory name that is being built in.

Can anyone comment on any of these statements? Would it be good to remove these limitations, or perhaps add an external_dynamic_module_makefile that does that?

Ideally, it would be good to have a method that handles these variations on the standard pike-distribution-module theme.

Also, I've got some other thoughts that anyone is welcome to comment on:

1. We should have a way to insert information into the modref when a new

module is installed. This way, if I add a new module, the inline documentation is integrated with the existing modref. Now, I'm not very knowledgable on how this works, but I'm guessing that it would probably involve both installing documentation as part of the build procedure, along with some of the source [xml] files that would be needed to rebuild the documentation after inserting the new material.

2. In order to do an integrated module install/remove feature, we probably

need a "receipts" store to keep track of what files belong to with modules, so we can be sure that we delete all of a module, or don't overwrite portions another module accidentally. Part of this could probably be accomplished by making a wrapper to mkdir,install,etc that added or removed entries from a contents file ala the solaris package manager.

Obviously, a CPAN for pike [with auto download-build-install] is really just icing on the cake. It's something that we really can't do without having a seamless module management experience, both for users and developers. I'm willing to put some time in on this, but I am hesitant to go mucking around with some of this stuff without getting a blessing from the full-time developers.

As always, comments and suggestions are welcome!

Bill

/ Brevbäraren