Re: [Gnucap-devel] git repo proposal

[al davis]

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".