Catching up ... On Monday 15 June 2009, David Fang wrote: > >> I consider choosing which plugins to static link to be > >> something a regular user building the program should be > >> able to do. This is not supported by autotools as far as > >> I know. > > Is there a compelling reason to force plug-ins to link > statically? They work very well dynamically. Won't > configure --disable-shared do the trick?
I have asked that question myself, and don't know what the answer is. I don't see how "--disable-shared" applies here. The idea is that modules designed as plugins can be static linked or used as real plugins at the users choice. In the latest snapshot, there are 67 such modules that are designed as plugins, but static linked by default if you don't edit the makefile. (if I counted correctly) The reason to static link some plugins is so the plain executable does something useful, and to make it possible to use gnucap on a system that does not easily support on-demand dynamic linking. It also makes it possible to have a simple "demo", for example with the capabilities needed for use in teaching a particular course, that is a simple plain executable that does not require proper installation. Likewise, it is also possible to static link none of them, and rely on dynamic linking for all of them. The ones that are dynamic linked can be split into two groups ,, One group is those that are automatically loaded at start-up. The other group is those that are not automatically loaded until explicitly requested by the user. So, as far as configuration is concerned, it seems to me that it should be easy for a user to select which "plugins" are static linked, if any, to make such an executable. and ... How should the list of plugins to be loaded at start-up be configured? You can do it now in .gnucaprc or the system gnucap.rc, by listing a bunch of "load" commands. You can also list them on the command line. Should there be something like a default directory containing plugins that are automatically loaded at startup? _______________________________________________ Gnucap-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnucap-devel
