Re: Gnucap and summer of code

al davis <[email protected]>
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <[email protected]>
On Saturday 17 March 2012, Felix Salfelder wrote:
> > ("Gnucap has been using two different build systems, [the
> > autoconf based] does not provide features needed for
> > development or multiple simultaneous builds.")
> 
> what would these features for development be?

You can use the alternate build system with "configure.old".

One feature is the ability to have several simultaneous builds 
..  "make debug"  "make g++"  "make mingw" .

change the file list without needing to rerun configure.

It doesn't obscure "make" issues that come up with porting.

That's what I can think of for now.

> > With plugins, neither of these is any where near adequate,
> > and there is enough work to do to justify it as a whole
> > summer project. It needs to handle plugins as part of the
> > base install, and plugins added later. It needs to provide
> > an environment to handle user plugins nicely.
> 
> I have already implemented something related:
> - a module directory containing source for .so's.
> - install .so's to something like $prefix/lib/gnucap
> - gnucap looks for modules there (via config.h)
> - .. and traverses a colon-seperated includepath list
> - ~/.gnucaprc and $(pwd)(../)*/.gnucaprc loading
> - a gnucap-conf script that helps out of tree .so builds
> - (maybe more, don't remember)
> 
> all of this is rather ad-hoc and needs review, sanity checks
> and rebase against upstream gnucap. if it intersects what
> you have in mind, i'd be willing to help with these...

In my own "fork", that I planned to merge back, I have separated 
out "apps" (potentially plugins) from "lib" (the core that can't 
be plugins) and "main" (the minimum non-lib to get it started).  
"include" is also separated.

Installation should install the "include" files, because they 
are needed to build plugins.  "lib" builds a single .so that is 
always used.  "apps" is most of the commands, models, etc. which 
can be in individual plugins, or all in one, or anything in 
between.

main:
The main program .. builds "gnucap" executable.
links to gnucap.so by the loader
then explicitly loads the plugins in "apps", which are optional.
main.cc lang_verilog.cc

lib:
Core library .. builds "gnucap.so"
ap_construct.cc ap_convert.cc ap_error.cc ap_get.cc ap_match.cc 
ap_skip.cc bm.cc bm_cond.cc bm_value.cc c__cmd.cc c_attach.cc 
c_file.cc d_logic.cc d_logicmod.cc d_subckt.cc e_base.cc 
e_card.cc e_cardlist.cc e_ccsrc.cc e_compon.cc e_elemnt.cc 
e_model.cc e_node.cc e_storag.cc findbr.cc globals.cc io.cc 
io_contr.cc io_error.cc io_findf.cc io_out.cc io_xopen.cc 
l_ftos.cc l_pmatch.cc l_timer.cc l_trim.cc l_wmatch.cc 
m_base_in.cc m_base_math.cc m_expression_dump.cc 
m_expression_in.cc m_expression_reduce.cc m_fft.cc m_spline.cc 
plot.cc test_readline.cc u_function.cc u_lang.cc u_nodemap.cc 
u_opt1.cc u_opt2.cc u_parameter.cc u_prblst.cc u_probe.cc 
u_sim_data.cc u_xprobe.cc 

apps:
Plugins supplied with core, 
loaded by default, but can be left out
bm_complex.cc bm_exp.cc bm_fit.cc bm_generator.cc bm_model.cc 
bm_poly.cc bm_posy.cc bm_pulse.cc bm_pwl.cc bm_sffm.cc bm_sin.cc 
bm_tanh.cc bmm_semi.cc bmm_table.cc c_clear.cc c_comand.cc 
c_delete.cc c_exp.cc c_genrat.cc c_list.cc c_measure.cc 
c_modify.cc c_param.cc c_prbcmd.cc c_sim.cc c_status.cc 
c_sweep.cc c_system.cc d_admit.cc d_cap.cc d_cccs.cc d_ccvs.cc 
d_coil.cc d_cs.cc d_meter2.cc d_poly_cap.cc d_poly_g.cc d_res.cc 
d_switch.cc d_trln.cc d_vcg.cc d_vcr.cc d_vcvs.cc d_vs.cc 
func_core.cc lang_spectre.cc lang_spice.cc lang_verilog.cc 
measure_at.cc measure_average.cc measure_cross.cc 
measure_eval.cc measure_integral.cc measure_max.cc 
measure_min.cc measure_rms.cc measure_slewrate.cc s__init.cc 
s__out.cc s__solve.cc s_ac.cc s_dc.cc s_fo.cc s_tr.cc 
s_tr_set.cc s_tr_swp.cc 

include:
installed at $PREFIX/include/gnucap
allows building of plugins
note that "spice-wrapper.cc" is also installed here.
ap.h bm.h c_comand.h c_nodset.h constant.h d_coment.h d_dot.h 
d_logic.h d_subckt.h declare.h e_aux.h e_base.h e_card.h 
e_cardlist.h e_ccsrc.h e_compon.h e_elemnt.h e_model.h e_node.h 
e_storag.h e_subckt.h globals.h io_.h io_error.h io_trace.h 
l_compar.h l_denoise.h l_dispatcher.h l_lib.h l_stlextra.h 
l_timer.h m_base.h m_cpoly.h m_divdiff.h m_expression.h 
m_interp.h m_matrix.h m_phase.h m_spline.h m_wave.h md.h mode.h 
patchlev.h s__.h s_tr.h spice-wrapper.cc trace_off.h trace_on.h 
u_cardst.h u_function.h u_lang.h u_limit.h u_nodemap.h u_opt.h 
u_parameter.h u_prblst.h u_probe.h u_sdp.h u_sim_data.h 
u_status.h u_time_pair.h u_xprobe.h 

modelgen:
builds "gnucap-modelgen" executable (a model compiler)
links to gnucap.so by the loader
mg_.h mg_error.cc mg_in.cc mg_main.cc mg_out.h mg_out_common.cc 
mg_out_dev.cc mg_out_dump.cc mg_out_h.cc mg_out_lib.cc 
mg_out_model.cc mg_out_root.cc 

translate:
builds "gnucap-translate" executable
a standalone format translator.
links to gnucap.so by the loader
loads two lang_* plugins explicitly
has only a "main.cc"


This is not the final list.  There are problems with the build, 
so it is not "released".  

There are issues with some files...
include/s_tr.h ... is not supposed to be available for plugins
include/d_*.h ... incomplete work.
include/d_logic.h, include/e_node.h ... disorganized code to 
support the Verilog "connectmodule".
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.