Re: [Gnucap-devel] incomplete stuff

[al davis]

On Friday 20 March 2015, Felix Salfelder wrote:
> > To me, the highest priority in gnucap now is to finish the 
> > incomplete work we have.  There is lots of it!
> 
> my favourites are the build system and the output
> pluggability. i need help/input to get this done. without
> these, the work on the qucs-plugins is in limbo, no matter
> what happens to adms.

Top priority to me is to bring in the extra features in the 
forks gnucap-uf and gnucap-arails making them available to 
everyone without making an all or nothing trade.  Most of the 
changes should be plugins.  The gnucap-plugins repository exists 
for this purpose.  Part of the intent of the plugin system is to 
enable what would otherwise require many private forks, without 
real forks.

To do this, some changes to the core library are needed.  
Looking at gnucap-uf and gnucap-arails, they have some core 
changes.  Some changes are good and should be accepted into the 
main gnucap.  Some changes are arbitrary.  Some are defective or 
harmful.  All of that needs to be presented and reviewed.

The main gnucap, especially the core library, is maintained to a 
high standard, carefully reviewed.  The plugins in the gnucap-
plugins repository are intended as not formally reviewed.

The build system is a high priority to me too, but the autotools 
branch is very far from complete, clean, and stable.  Even if it 
were ready for release, the intent of the development branches 
in the main repository is that all real development happens in 
the development branches, each with a purpose, differing from 
master or unstable only in what is being developed there, 
expecting to do a fast-forward merge for final acceptance.  
Until then, you can use it as a substitute for master, which 
tests it, finding bugs and other needed changes.

A proper configuration system should be modular, or at least 
look like a module, with a well defined interface to the rest of 
the program.  With reasonable modularity, it should be simple to 
substitute a different configuration system or even manual 
configuration.  Also, the configuration system should do only 
configuration.  Anything else is a violation of the principles 
of modularity.

Most plugins are single files and should not require a build 
system.  Everything needed should be available when the program 
is installed.  The scripts must not be tied to a particular main 
program build system.  If they are, that build system is not 
ready for merge to master.  It's still a work in progress.

Of my own incomplete work. I wish I could get onto the verilog-
modelgen, but the highest priority is to finish some details of 
the plugin system, particularly loading directories and 
compiling.  The build system depends on this, so the build 
system cannot be considered complete until this is done.

Also, we need to consider ports to non-gnu systems, particularly 
Apple and Microsoft.  Even if not explicitly supported, we need 
to be careful to not explicitly block those platforms by issues 
in the build system.


The qucs-plugins ....  Notice that the word plugins is plural.  
When complete, there will be a collection of them.  Each one can 
be completed one at a time, gradually adding to the completeness 
of the system.  Only one of them is dependent on gnucap output 
pluggability.  Temporarily, a suitable workaround would be a 
postprocessor program that takes a gnucap output file as inputs 
and generates a qucs dataset file.

More important, on the qucs-plugins, we need to define the 
goals.  That's another email.