[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] git repo proposal
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] git repo proposal |
Date: |
Mon, 27 May 2013 07:40:09 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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
- Re: [Gnucap-devel] git repo proposal, (continued)
Re: [Gnucap-devel] git repo proposal, Felix Salfelder, 2013/05/26
- Re: [Gnucap-devel] git repo proposal, al davis, 2013/05/26
- Re: [Gnucap-devel] git repo proposal, al davis, 2013/05/26
- Re: [Gnucap-devel] git repo proposal, al davis, 2013/05/27
- Re: [Gnucap-devel] git repo proposal, Felix Salfelder, 2013/05/27
- Re: [Gnucap-devel] git repo proposal, John Griessen, 2013/05/27