gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] Gnucap and summer of code


From: al davis
Subject: Re: [Gnucap-devel] Gnucap and summer of code
Date: Tue, 27 Mar 2012 11:35:20 -0400
User-agent: KMail/1.13.7 (Linux/2.6.32-trunk-amd64; KDE/4.6.5; x86_64; ; )

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]