On Sunday 26 May 2013, Felix Salfelder wrote: > so actually the tree does not equal the repository? what > exactly are you referring to with "tree"? > > i'd say plugins that are new should go to where the plugins > are (i.e. into 'apps'). patches/improvements to plugins > should go to where the plugin already is. what's the big > deal? lets put it into a different branch and merge it once > it's complete.
"apps" is the collection of plugins that are loaded by default. To develop a new plugin, all you need is the plugin itself that you are working on. You don't need the whole program source. So, I should be able to "apt-get install gnucap", and be able to develop and test new or replacement plugins, without recompiling the whole simulator. So that "different branch" should only include that plugin being worked on, nothing else, which could be one file. Most plugins have only one file. To someone wanting to use the new plugin, all they need to do is "load path/to/new/plugin". You don't need to reinstall the main program. It's like user data. Maybe it IS user data. "load" is really no harder than "include", and should be thought of as the same. Looking at an operating system, you may be thinking of plugins as like kernel modules. That's one use. How about thinking of them as the "apps" .. application programs you run under the OS. Stuff you "include" like command scripts, subcircuits, and spice "models", are analogous to running a shell script in an OS. Stuff like compiled plugins, Verilog models, Spice C models, are analogous to compiled applications you run under the OS. Sticking with the OS analogy, the ones that come with the simulator might be analogous to "/bin", while the outside ones more analogous to "/usr/bin". _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
