Re: git repo proposal

Hi Al.

On Sun, May 26, 2013 at 06:49:39PM -0400, al davis wrote:
> 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.

does that imply, they never change/grow/get\ fixed?

how about placing optional/experimental plugins into <gnucap-git>/opt?
here, also alternatives could be developped (if needed).

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

i fully agree. compiling a single plugin should be as simple as
possible. the simulator source is not needed to develop plugins. just
the headers. on debian these would go into a gnucap-dev package. gnucap
should suggest gnucap-dev.

this should not be mixed up with compiling plugins collections or
packaging extra stuff. and gnucap should /NOT/ implement a build system
for plugin packages just to make plugin development possible.

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

everybody should be able to provide gnucap-plugins or gnucap-plugin
packages in whichever way (s)he likes. this should not conflict or
interfere with either gnucap development or the gnucap build system.

a branch containing just one plugin can be easily hosted by its author.
until you decide to move it into <gnucap-src>/opt.

once, verilog (or something like it) support is up, there won't be much
movement in c-code device modelling anylonger, so the whole
compilation mess will reduce to a .v{a,ms} -> .so translation facility.
probably a program within a package like gnucap-adms. this routin could
be easily wrapped into a 'load' command.

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

i agree. for single plugins. just like "include" just includes single
files. whole packages, like gnucap-geda have dependencies. like
libgeda-dev. gnucap-adms needs admsXml. packages provide more than just
a single device plugin. gnucap-geda must provide development headers for
the net and port devices, gnucap-adms must provide an executable... all
extra packages should ship unit tests. running unit tests is done with
"make check" just before installation. there is an endless list of
things, a "load" command will never support. so why bother?
this is a simple case for software distributors.

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

whichever analogy you choose, gnucap is not either an OS nor a software
distribution. let's use it as a simulator. let's allow others to extend
it by writing either device models or other software that uses it. lets
draw a clear line between user and developer.

regards
felix