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. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
