From: Aleksej S. <as...@in...> - 2009-03-14 04:33:41
|
Hello! Same use case: I install CLISP with some default set of modules, then I install, e.g., Maxima, which requires CLISP interpreter. Then I realize that I want PostgreSQL, I install lipq, build CLISP module, and... And now I have problem: with current implementation of modules, it is problematic to add postgresql module set to have it by default. It involves too much manual work or weird scripting, if you want to automatize it. It would be nice, if CLISP followed this strategy at installation: 1. Install "base" linking set. 2. Install each built module set in separate subdirectory, e.g. $(PREFIX)/lib/clisp/module/$(modulename) (You can use recursive "make install" for this.) 3. Create "full" linking set from base and installed modules. This way it becomes easier to maintain installed modules and it is easier to replace "full" linking set. If this plan is approved, I even volunteer to implement it. -- CKOPO BECHA... CKOPO CE3OH... |
From: Sam S. <sd...@gn...> - 2009-03-16 17:18:17
|
Hi, Aleksej Saushev wrote: > > Same use case: I install CLISP with some default set of modules, > then I install, e.g., Maxima, which requires CLISP interpreter. > Then I realize that I want PostgreSQL, I install lipq, build > CLISP module, and... > > And now I have problem: with current implementation of modules, > it is problematic to add postgresql module set to have it by default. > It involves too much manual work or weird scripting, if you want to > automatize it. > > It would be nice, if CLISP followed this strategy at installation: > 1. Install "base" linking set. > 2. Install each built module set in separate subdirectory, e.g. > $(PREFIX)/lib/clisp/module/$(modulename) > (You can use recursive "make install" for this.) > 3. Create "full" linking set from base and installed modules. > > This way it becomes easier to maintain installed modules and it is > easier to replace "full" linking set. I started to concoct a long answer to the tune of "that's how it already works" but then I realized that this is all backwards. full should be gone altogether. --with-dynamic-modules should be the default. fixing that should be where you spend your cycles, not fixing the technology from the previous millennium. the only reason dynamic modules were not the default before is that they require -fPIC which takes a register away and costs a few %% in performance. since we cannot use that register with threads anyway, switching to dynamic modules is the way to go. Sam. |