Re: missing info in the models tarballs.

> You need this info to build them, unless you are lucky..
>
> They are designed to be unpacked in the gnucap core root.
> (where src, modelgen, COPYING, and those files are)  so plugins
> is one of those.  All of them will create plugins, so if you
> unpack them all in the same place, you will get subdirs in
> plugins.
>
> If you unpack them anywhere else, you need to edit the
> file "Make2".  Change the line GNUCAP_INCLUDE to identify where
> the gnucap include files are.

Al,
	Heh, after unpacking and reading through the Makefiles, I decided
to move plugins/ into the gnucap source tree, upon seeing the
-I ../../../src flag.  And then this message came along... :)

> Obviously I do not intend to leave it this way.  Obviously, the
> correct way is not obvious!
>
> More info,hopefully a discussion, will follow.  I am treading
> new ground here.

Testing on powerpc-apple-darwin8:

% make
(cd asrc; make)
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
g++ -O2 -g -I. -I../Include -DTRACE_UNTESTED -DSPICE_3f -DHAS_STDLIB -fPIC
-I../../../src -Wall -Wextra  -c ../Include/wrapper.cc
/usr/include/stdlib.h:226: error: declaration of C function 'int
setenv(const char*, const char*, int)' conflicts with
../Include/cpstd.h:54: error: previous declaration 'void setenv()' here
../Include/wrapper.cc: In static member function 'static void
MODEL_SPICE::init_ckt()':
../Include/wrapper.cc:247: warning: the address of 'static CKTcircuit*
MODEL_SPICE::ckt()', will always evaluate as 'true'
make[1]: *** [wrapper.o] Error 1

And in cpstd.h:

#ifndef linux
extern void setenv();
#endif /* linux */


Not even close to actual prototype.  :(
Let's make this portable... I'm willing to help autoconfiscate.
#ifndef-ing hardcoded platforms is not robust.

> To the autoconf lovers ...  If these files use autoconf, it
> becomes a run time dependency for gnucap.  That is not
> acceptable.  Plugin source is considered to be user data.

Autoconf doesn't necessarily make it a run-time dependence.
How do you want this to work?  Build/install gnucap-core into some path,
providing core include headers and libraries?
Compile plugin-models into shared libraries, perhaps installed headers
into /prefix-path/include/gnucap and core libraries into
/prefix-path/lib/gnucap/?  Have plug-in modules be configured with an
argument to the gnucap install paths?  --with-gnucap=[PATH], perhaps?
I'm willing to assist in the autotools department, once I understand tha
goals.

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