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

[David Fang]

Al,

> Neither Dan nor I could figure out a better way that worked.

        I hope you were able to figure out the dependencies issue with the
previous suggestions.

> > > You are thinking of relatively few big plugins that involve
> > 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.
>
> That is the intent.  Actually, even for distributed plugins that
> are single files, I expect to distribute only that single file.
> For plugins that are multiple files, I expect its
> own "Makefile" will be only a list files.  The options,
> everything gnucap specific, comes from the installed
> boilerplate Makefile.

Also to make life a little simpler w.r.t. linker management, you could
install that configure-generated "./libtool" script, perhaps renamed
"gnucap-libtool" as a script called by your boilerplate Makefile.  The
./libtool only contains information that independent of the install path,
as a result of detecting platform and linker characteristics (though the
user may have passed --disable-shared or --disable-static).  After you add
AC_PROG_LIBTOOL in configure.ac and re-autogen.sh, the default compilation
rules (.cc.o) in Makefile[.in] are now libtool-wrapped commands, that you
could rip for your installed boilerplate Makefile.  (And they still
include dependence-tracking if you enabled it.)

> Again, I expect that most of them will be written in a modeling
> language.  The provider of a model wants it to work with all
> simulators.  It is likely that they acutally used something
> like Spectre or some other commercial simulator.  Also, some
> will develop on gnucap with the intent that Spectre users can
> use the model.

> > 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.
>
> That is the main reason for using autoconf.  It has features
> they depend on.  People have been building packages before
> gnucap used autoconf, but they needed to do more manual
> configuration.

<selfish>
The gnucap in fink (Mac OS X ports) is rather outdated.  I'm hoping that
by working these build issues out, we can bump up the version in the
distribution with the next release.  :)
</selfish>

> > 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.
>
> Dan just made one to track the link order issue.  (Dan: how
> about posting it?)

Are you trying to list link objects in a configure-dependent order?  I'd
advise against doing that, and just go with making dispatch robust to
arbitrary global initialization ordering.  Reasons and suggestions are in
previous thread.

> The biggest one still unresolved, that has been there for years,
> is in template instantiation. (often confused with
> specialization).  Older versions of ACS/gnucap had an
> option "COMPILE_TEMPLATES", "MANUAL_TEMPLATES",
> "LINK_TEMPLATES" .  As of now, only "COMPILE_TEMPLATES"
> is supported, but 5 years ago Borland worked only with
> "COMPILE_TEMPLATES".  Gnu and MS (strange pair here)
> worked only with "MANUAL_TEMPLATES".  Sun worked
> only with "LINK_TEMPLATES".
>
> (Now you will ask what those words mean....)
>
> It would be nice if there was a test to see if LINK_TEMPLATES
> is supported, because it significantly speeds up compiling
> and reduces generated code size.  Actually, I don't know
> if it is worth the test just for this.  There still may be a
> problem with Sun's compiler.

I have a guess as to what these mean: do you mean extern templates, i.e.
suppressing implicit instantiation in favor of explicitly instantiating
(one-time) elsewhere?  First, "extern template" is a GNU extension, and is
non-standard.  You can easily detect it and use it if you like.  Without
extern templates, you can accomplish separate template compliation by
splitting the class definition from their method definitions into separate
source files (say, .tcc).  By not #include-ing the method definitions, you
prevent implicit instantiation and can control exactly where you want
templates instantiated.  One does this to minimize replication, as you've
said.  However, the STL container headers ship most definitions along with
the class definitions, making it difficult to suppress implicit
instantiation -- that's what "extern template" was for.  (But you get some
inlining benefits even at low optimization levels.)

Another lesser known gcc option is -frepo (for template repository) that
tries to manage template replication for you in an auxiliary file shared
by all compilations, where ALL templates go.  If you're really concerned
with replication, try that out.  You can also use 'nm' to hunt for
weak-linkage symbols that are the result of implicit instantiations.

Regarding code size: in template-heavy code, as much as 95% of object size
can be attributed to debugging symbol info with -g (default configure
CXXFLAGS).  (See what 'strip' does to your executable size.)  The presence
of debug symbols has had no measurable impact on performance to me.  Data
point: I have a 250 MB binary (from C++) that is 15 MB after stripping,
and runs just as fast before vs. after.  Investigations into code size
should account for the debug bloat.

> 2.95 was the first clean version of g++, that supported STL
> properly.  Most of the problems went away with that release.

I have some bad memories of 2.95, mostly in the department of standard
conformance, still evidenced by the frequency of questions on mailing
lists about why "my 2.95 code no longer compiles."  It was still the
best free compiler for its time, but these days, I wouldn't go out of my
way to support anything older than 3.3.

> Like I say ... I did notice the time stamps on much of your
> email.  :-)

What, they're perfectly reasonable by Pacific time standards!
It's like I'm still on the west coast after all these years...

> Grad school ... I remember it well....  Be sure to allocate time
> for recreation, physical activity.  For me it was bicycling and
> cross country skiing. There is some really great bicycling
> around Ithaca. I was in Rochester, but did lots of bicycling in
> the finger lakes area.  A ride around Cayuga Lake should be
> very enjoyable.

*sigh* In recent times, I've lost sight of recreation.  My bike is in
unusable shape, and I'm not in much better shape myself.  :S  I did give
snowboarding a shot a few weeks ago (first time) which was mad fun!
Looking forward to more attempts in the future.

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