Re: [Gnucap-devel] missing info in the models tarballs.

[al davis]

On Sunday 25 February 2007 01:05, David Fang wrote:
> > I decided to try it ..  That is play with it to compile a
> > plugin.
> >
> > It consists of a couple of shell scripts, and some other
> > files which are essentially a database of all of the things
> > that need configuring.
> >
> > It has a reasonably good interface, only slightly more
> > complicated than just compiling on a single known system.
> >
> > 1. Compile:
> > libtool --mode=compile g++ -c c_list.cc
> >
> > 2. Link:
> > libtool --mode=link g++ c_list.lo -o libc_list.la -rpath
> > /tmp
> >
> > Now the .so file is hiding in the directory ".libs".
>
> Hi Al,
>       The rationale for hiding the shlib in .libs is because there
> can be two instances of using it, before installation in the
> build directory, and after installation, in its final
> destination.  When you 'make install', it will do the
> necessary re-linking the path if necessary, depending on
> platform.  Basically, there should be no need to run libtool
> (the one generated by configuration from ltmain.sh) by hand.

I was just saying where it is.  If it were my choice I would 
have made it a visible directory instead, but putting it there 
is better than cluttering the source directory.  I approve!  
Sorry if it didn't sound that way.

If you look at the way the old build system works, you will see 
that it does it that way.

> > 1. It definitely DOES create a run-time dependency.  If we
> > use it in this manner, you will need libtool installed to
> > fully run gnucap.
>
> No, libtool is never needed as a run-time dependence. 
> Libtool (./libtool) is just a self-contained configured
> script that manages the build and installation.  If you're
> thinking of running the libtool script by hand, you're
> probably not going about it right way.  Once it installs the
> libraries, it's work is done.

I don't think the libtool authors anticipated the way I want 
gnucap plugins to work.  I expect that most of them will be 
compiled models and test benches, mostly written in VHDL-AMS  
or Verilog-AMS. 

Commercial simulators that do behavioral modeling are usually 
slower than Spice-type simulators.  I will not accept any speed 
penalty.  Gnucap is faster than Spice-type simulators now, and 
will remain so, even with behavioral modeling.  On-the-fly 
compiling of models is a requirement.

Not only are they slower.  They compile!!!  and still are 
slower!

Most Verilog and VHDL digital simulators require the user to 
compile.  They may hide it, but they do compile.  How many of 
them run interactively?

This means that I have already accepted that a C++ compiler will 
be required at run time for full functionality.  The 
translators from the modeling language to C++ are very 
fast.  "gnucap-modelgen" is already part of gnucap.  Part of 
the simulator source is ".model" files.  This caused a major 
autoconf headache.  In the future, this will be moved to 
plugins, possibly compiled at run time.

> When you write plugins (say, as separate packages), they will
> be distributed with the same libtool scripts and templates. 
> The configure process should be told where the core is
> installed, and append CPPFLAGS and LDFLAGS accordingly for
> the plug-in's build.  The installation of the plugin's shared
> libraries will again be managed by libtool (the generated
> script).  After installation, libtool has no role in running
> the executable or loading plugins.

You are thinking of relatively few big plugins that involve 
significant development effort.  I expect that the majority 
will be hack jobs, used once and never distributed.  As I said, 
compiled models and test benches.
>
> > Some relief ...  such dependency is only there if you want
> > to use source plugins.
>
> Do you mean installing the sources of the plugins?

Actually, compiling on the fly. To the user, it will look like 
installing the source.

> Is that 
> necessary?

Yes.

From a user perspective, ideally it would look interpreted, but 
the speed penalty is too big.

> > 2. The libtool tarball is about 3 MB. about 3 times the
> > size of the gnucap basic tarball. (core + enough plugins to
> > be useful) It contains lots of stuff for lots of systems.
>
> You don't need to ship libtool along with!  Only the few
> scripts that are automatically added by libtoolize [--force
> --copy] are included in the distribution.  Those are
> automatically packaged up by automake.  (You can confirm by
> running "make distcheck")

That brings up one of my objections to the architecture of 
autoconf.  In general, a Makefile has 3 parts ..
1. project determined - list of files, etc.
2. locally determined - compiler switches, directories, file 
extensions.
3. boiler plate - stuff that is just copied.

My old system uses 3 files: Make1, Make2, Make3, cats them when 
you run make.  There is no separate step.

In terms of when they are changed .. Make3 is almost never 
changed.  Make2 is changed when you move to another system.  
Make1 is changed when you modify the code.

I consider it to be an absolute requirement that you do not need 
to reconfigure after changing Make1.  For the program as a 
whole, missing this one relegates the configuration tool to 
being an end user tool only, not suitable for development, so I 
keep the old system around.

For a plugin, it is not acceptable to configure again for every 
plugin.  The configuration has been done for the main program, 
that should be enough.  With my old system, it is.  You just 
need a new Make1.

With my old system, configuration is simply the generation of 
Make2.

With autoconf .. since you say "make distcheck" ...  It took a 
lot of effort to get it to an acceptable form.  That latest 
version gives an error message but at least it builds a 
reasonable file.  That part has been a real pain.

My old system fails in two important ways .  The first is that I 
never made Make3 complete enough to have all the targets that 
are needed by people writing RPM, DEB, etc packages without 
tweeking.  They are accustomed to the files being verbed, and a 
few other certain things to be in the usual places.  The second 
is that I don't have the big library of tests for portability 
issues and installation issues.  On the other hand, the tests 
autoconf has for C++ are sparse and carry a heavy C burden. For 
my old system, these are not architectural issues.  They are 
just incomplete work.

What is wrong with autoconf is architectural issues.  The work 
is very complete.

Now .....  for plugins.  People writing plugins should not need 
to deal with autoconf.  Most of them are non-programmers.  Most 
plugins will have their source in one file.  What to do with 
one file should be obvious.  A few will be multiple files.  
Here, just listing the files and specifying some names should 
be all that is required.

The multiple files in the Spice model plugins are an artifact of 
Spice.  On the average, they are about 10 times the size they 
should be.  With the tools that will be in gnucap, any of those 
will be able to be redone easily in one reasonably sized file.

For an idea of the difference, compare the file "d_mos8.model" 
to all the files in plugins/bsim/BSIM3v330 .  They are roughly 
equivalent.  The difference will get bigger (the .model file 
will get smaller) when the model compiler gets the capability 
to automatically generate derivatives, and is converted to a 
standard language.  Standard means there is an ISO or IEEE 
document defining the language, and it is widely used.