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

[David Fang]

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

Al,
        Sorry for delay, been a long day/night here.  My thoughts:

        Ok.  Don't forget, you can move all the autotool scripts into a
subdir using AC_CONFIG_AUX_DIR([subdir]) in configure.ac.  Less clutter.

> > > 1. It definitely DOES create a run-time dependency.  If we
> >
> > No, libtool is never needed as a run-time dependence.
>
> 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.

I think I'm seeing what you mean by plug-in now, that it's not just
typical shared libraries built on top of shared libraries.  You want users
to be able to build-modules in their local working directories without
going through installations, hence the 'need' for a practical
link-management like libtool for users.  Is this what you have in mind?

Since you intend for model-writers to plug-in/link against gnucap, you
could try to simplify things by propagating linker flags (the same used in
building gnucap) to a configuration file.  The flags contain more than the
usual paths, but also some flags deduced by libtool, if you're making some
libtool-like assistance to model-compilation.  (Is this what you had in
mind about 'libtool-light'?)  It could be a piece of boilerplate Makefile
that can be included by plugins' Makefiles.
e.g. "include /usr/local/lib/gnucap/mk/modelgen.mk"
(/lib instead of /share, because it will be architecture-dependent)
This way, no additional configuration is necessary for the plug-in build,
just re-using the results of the core's configuration.

> 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?

Yes, I've seen the compile phases at work... but don't have a good survey
of what's out there.

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

Requiring a C++ compiler is not a big deal.  Can you summarize why the
.model files were a headache?  (The mail archive I'm reading through lumps
all messages with the same subject "new gnucap development snapshot" into
the same thread, which mixes things up incoherently...)

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

Well, not necessarily big so much as written with the intent of
installation and re-use.  For throw-away work, the above suggestion of
providing an installed boilerplate Makefile might suffice.

> Actually, compiling on the fly. To the user, it will look like
> installing the source.
>
> > Is that
> > necessary?
>
> Yes.

Understood now.

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

If you provide the invariant components of the Makefile, you're nearly
done.  Boilerplate and locally determined parts can be provided by the
installation of gnucap.  Everything is preconfigured except for listing
local files, which the user provide.  No additional configuration
necessary.  Do you intend to provide an installed makefile?

Should the quick-hack model code take on a life of its own, it's only an
incremental amount of work to package it up, just depending on a gnucap
core installation for configuration information.

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

I don't think you need to worry about rpm/deb matters, those tools have
wrappers scripts and conventions to work with any typical autotoolized (or
mimicked)  project.  I've never had to worry about them, and my colleagues
have built rpms and debs from my distributions just fine.

Now, for portability issues, admittedly autoconf's core tests don't cover
much about C++, and the autoconf-macro archive is slightly better.  This
doesn't sound like a solution, but write solutions only for the problems
that arise: don't worry every known issue out there.  If you discover a
C++-ism that needs a configure test, I'm more than willing to submit a
macro test for it, as are other developers on the list -- I've been doing
this for some time, following the evolution of C++ support from g++ 2.95
to 4.2.

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

So if you provide a "gnucap-config" script and/or pre-configured
boilerplate Makefile, installed in an architecture-dependent path, then
you should be most of the way there to the way you want plugins to be
built.  Is this what you're likely to try?


Ok, it's time for me to pass-out.
Zzzzzzzz... [murmurs of coding in sleep]


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
        -- (2400 baud? Netscape 3.0?? lynx??? No problem!)