Using pike 7.6.25. I noticed that when i have module.pmod.in/module.pmod, I can't use the @module@ tag since the resulting .so-file is in the parent directory, so the typical "inherit .___Lua;" fails, since there's no such .so to load in the same dir. Not sure where/how to fix this. For now, I don't use @module@, but spell the entire path ( Public.Lang.___Lua ).
Kaos wrote:
Using pike 7.6.25. I noticed that when i have module.pmod.in/module.pmod, I can't use the @module@ tag since the resulting .so-file is in the parent directory, so the typical "inherit .___Lua;" fails, since there's no such .so to load in the same dir. Not sure where/how to fix this. For now, I don't use @module@, but spell the entire path ( Public.Lang.___Lua ).
Ok, ran across this again for Ncurses now.. I added the unused (afaics) MODPATH variable to the install of the .so in dynamic_module_makefile, changed this line in the install target: $(TMP_BINDIR)/install_module module.so $(SYSTEM_MODULE_PATH)/$(MODDIR)$(MODPATH)$(MODULE_WRAPPER_PREFIX)$(MODNAME).so ;\
and then added MODPATH=Ncurses.pmod/ to my Makefile.in file, so now the ___Ncurses.so ends up in the Ncurses.pmod dir and I can again use @module@ in my .pmod files.
Not the very best approach, I see, but it does the job as work around for now :) I guess a better approach would be to fix this in install_module or similiar where it may look up the directory stats and stuff to make a sound decision for the module in question without the need to hack in the specifics in the Makefile.in.
//K
I added the unused (afaics) MODPATH variable to the install of the .so in dynamic_module_makefile, changed this line in the install target: $(TMP_BINDIR)/install_module module.so $(SYSTEM_MODULE_PATH)/$(MODDIR)$(MODPATH)$(MODULE_WRAPPER_PREFIX)$(MODNAME).so
Um, isn't that what MODDIR is supposed to be for? See the Parser module.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
I added the unused (afaics) MODPATH variable to the install of the .so in dynamic_module_makefile, changed this line in the install target: $(TMP_BINDIR)/install_module module.so $(SYSTEM_MODULE_PATH)/$(MODDIR)$(MODPATH)$(MODULE_WRAPPER_PREFIX)$(MODNAME).so
Um, isn't that what MODDIR is supposed to be for? See the Parser module.
Well, I don't know (will look in Parser mod to see what I find) and it certainly isn't fixed in well manner, but it works. The trick was to not affect the path for the .pmod files, since then they would still end up in a different directory from the .so, which was the problem to start with.
I can look into making a better solution, but I'll guess it'll take a bit longer, since I have to learn how this stuff works and figure out what my changes will affect.
If you have a module.pmod.in and some C code, both the generated module.pmod and the .so file should be installed in the MODDIR subdirectory of the module directory. Maybe they aren't (the Parser module doesn't seem to use a module.pmod.in), but then that would be the bug to fix rather than add a new construct that does the same thing.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
If you have a module.pmod.in and some C code, both the generated module.pmod and the .so file should be installed in the MODDIR subdirectory of the module directory. Maybe they aren't (the Parser module doesn't seem to use a module.pmod.in), but then that would be the bug to fix rather than add a new construct that does the same thing.
Ah, I see.. yes. Although there's no module.pmod.in when it's time for install. During make, it has been compiled into a module.pmod/... [all .pmod files from module.pmod.in/ ]
But the I guess it's the Parser that is bogus. Didn't see when it was used during install though. Have to make a closer look at this. Strange no one else seems to have noticed this though. Is my setup so uncommon?
Example of my setup:
Foo/ configure.in Makefile.in module.pmod.in foo.cmod
Foo/module.pmod.in/ module.pmod
make gives: module.pmod/module.pmod foo.c module.so install gives, at target module: ___Foo.so Foo.pmod/module.pmod desired after install: Foo.pmod/module.pmod Foo.pmod/___Foo.so
If module.pmod.in is a file, then install gives (correctly): Foo.pmod ___Foo.so (no .pmod dir)
The reason for having module.pmod in a dir named module.pmod.in is to be able to have more .pmod/.pike files installed with the module. Haven't found any other way, so I guess it's the supposed way of doing this... ?
//K
Having module.pmod.in as a directory is pretty uncommon I'd say, yes, so I'm not surprised there are bugs in the handling of it. Who implemented it in the first place?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Having module.pmod.in as a directory is pretty uncommon I'd say, yes, so I'm not surprised there are bugs in the handling of it. Who implemented it in the first place?
Ah, then I understand. If no one else toss in a fix for it, I'll have a go at making it, but don't expect any thing too soon..
Just make sure you agree with whomever invented the "module.pmod.in as directory" feature what the intended behaviour is. What you suggested looks OK to me, but I've never used that feature...
If make generates module.pmod/module.pmod instead of the normal module.pmod (why?), it probably would make sense to have it generate module.pmod/__Foo.so as well.
I believe that the rationale is that you should create a situation where a later module can be installed further down the tree without having to manipulate the directory structure first. I don't recall who did the implimentation (I'm pretty sure it wasn't me).
Bill
On Wed, 17 Nov 2004, Marcus Comstedt wrote:
Just make sure you agree with whomever invented the "module.pmod.in as directory" feature what the intended behaviour is. What you suggested looks OK to me, but I've never used that feature...
If make generates module.pmod/module.pmod instead of the normal module.pmod (why?), it probably would make sense to have it generate module.pmod/__Foo.so as well.
What's so uncommon about that, especially if you hold out the possibility for nested modules or use the "file is a class" paradigm. I use it all the time.
Bill
On Wed, 17 Nov 2004, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Having module.pmod.in as a directory is pretty uncommon I'd say, yes, so I'm not surprised there are bugs in the handling of it. Who implemented it in the first place?
Not enough to notice that it doesn't actually work together with C modules, apparently. :-)
I've written 3 or 4 modules that use this, and haven't had any problems, so I don't think it's fair to say that...though there are a number of other problems that I've not figured out yet.
Bill
On Wed, 17 Nov 2004, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Not enough to notice that it doesn't actually work together with C modules, apparently. :-)
So you have a module with a module.pmod.in/module.pmod which uses @module@, and get it to work? Did you try it recently, because it seems to contradict Kaos' experience. Maybe you can compare your setups?
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
Kaos -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum