[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] gnucap development snapshot 2009-06-11
Re: [Gnucap-devel] gnucap development snapshot 2009-06-11
Sun, 28 Jun 2009 18:44:36 -0400
KMail/1.11.4 (Linux/2.6.26-1-amd64; KDE/4.2.4; x86_64; ; )
On Sunday 28 June 2009, David Fang wrote:
> Hi Al,
> I've started to build the bsim plug-ins for gnucap, and ran
> into some issues that could use clarification.
Thank You !!!!!!!!!!!
> In BSIM3v301:
> g++ -O2 -g -I. -I../Include -DTRACE_UNTESTED -DSPICE_3e
> -DPREDICTOR -DHAS_STDLIB -fPIC -I../Gnucap -Wall -Wextra -c
> /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 make: *** [spice-wrapper.o] Error 1
> is caused by:
> #ifndef linux
> extern void setenv();
> #endif /* linux */
cpstd.h is from Spice. copied without modification.
I considered rewriting the spice headers, decided not to, for
now, but I may reopen that decision someday.
> Barrage of questions :)
> Usage model:
> In the plug-in source, spice-wrapper.cc points a translation
> unit in the base package. Is spice-wrapper.cc shared among
> multiple plug-ins?
That is part of what I refered to when I said there would be a
rearrangement of the files. I have been putting it off mainly
because of trouble with autotools.
spice-wrapper.cc must be available to build spice model plugins,
so it must be available when gnucap is installed. I was
thinking it would be either in $prefix/lib or $prefix/include.
> Do you plan to require that the base
> package's source be unpacked and present for building
No. Just includes. I need to go over and decide which ones.
For now, you can probably assume all of them. The plan is that
they would be in $prefix/include.
So, files that need to be available after installation are
includes, wrappers, and executables (including modelgen, and an
unrelease one "ibis").
> or do you also plan to support building plug-ins
> against an installed base package?
That is a fundamental concept. Plugins will be added later,
often not tied to a distribution package. Often plugins will be
in the user space.
Eventually, it should work like this ....
--- loads it from the public place
--- I'm sure you can figure this one out, such as:
--- from current directory
pluginname means ..
-- if it exists, a file (.so or whatever)
-- if it is a writable directory, run make then load whatever is
-- if it has an extension (file.va) compile it then load it
Basic syntax of the load command is compatible with Spectre,
except that the commands "load" and "ahdl_include" are
interchangeable, to make it easier for the user.'
> It looks like a good
> subset of the files in <base-package>/src would be
> appropriately installed to $(pkgincludedir).
> A bin_SCRIPT
> like gnucap-config could direct a plug-in build to look in
> the right place for header files (I can draft such a script
> for you). Can you list for me which .cc .h files would be
> appropriate to install from the base package?
todo . urgent.
> Regarding the setenv() issue above, constructs like #ifndef
> linux are usually dubious. Would it be acceptable to just
> include <stdlib.h> or (<cstdlib> of C++ convention)? I know
> it bloats the preprocessing, but it would help to keep things
> more portable.
Dealing with spice (or any foreign) files always raises issues
I would not have anything like #ifndef linux in my code, except
possibly in md.h, and there only if I could not figure out any
other way, But, this is Spice code, where my rule is "if at all
possible, don't change it". Just hold your nose....
This strategy explains a lot of why spice-wrapper.cc is the way
it is. Remember, the intent is to use the models "as-is". I
have not been able to make it 100%, but it is close, and getting
I'm thinking that for the future it makes sense to have another
wrapper that works with slightly modified spice models for
better performance, but I decided that making a stable release
now is more important.
> Is it your intent to NOT have the users
> re-run any sort of configure step for the plug-ins?
On a per-plugin basis, there should be no configure step. If
any configuration needs to be done, it should be taken care of
by the main configuration.
I see two possibilities, which are mutually exculsive.
1. The configuration is done once, as the main package is
configured. (claimed autoconf style)
2. The configuration is done through a script that is executed
by the makefile at compile time (libtool style)
In any case, the individual Makefile is pretty basic.
> If so,
> it is possible to re-use the results of the base-package's
> configuration for plug-in complations, e.g. installing
> config.h as gnucap-config.h. This way, plug-in builds
> already look configured, so a common boilerplate Makefile
> will suffice. Or the configure phase would be trivially
> short, just setting path/prefix variables.
The existing design is a common boilerplate Makefile, with the
trivally short configure. This is the basic concept of the
"old" non-autoconf build system.
> The shared-library flag issue on Mac OS X
> ("powerpc-apple-darwin8-g++-4.0.1: unrecognized option
> '-shared'") was address in another thread, so I won't repeat
> it here. For ease of portability, I propose using libtool
> for plug-ins in the following manner:
> * From the base-package install the configured 'libtool'
> script as 'gnucap-libtool', so that plug-in builds need not
> re-run the configuration detection steps for libtool that
> were done for the base package. The new plug-in boilerplate
> Makefile will wrap all compilations through this script, much
> like the libtoolized-automake commands LTCOMPILE and
> LTCXXCOMPILE in src/Makefile.in. (I should probably write up
> such a Makefile to make it clear.) Compilation will produce
> both .o and .lo object files for the gnucap-libtool script to
> handle. The link step should produce .la and libs/*.so for
> every plug-in. The said plug-ins can be used in-place
> (uninstalled), and after installation. (The subtle
> differences due to run-paths are handled by libtool --finish,
> upon installation.)
I'm still not sure what to do with systems like MS-windows, with
MS-"Visual"-C++ or something like that .. (or maybe Borland
C++ or some other)
> I'll start by modifying the base-package to perform some of
> the above actions. (BTW, did you get a chance to test out
> last week's autotools updated patch I sent?)
It didn't work .. more info in another mail, to come.
> This may require a few tries for me to get right, but
> hopefully discussion and feedback will keep things straight.
Hopefully my bug reports won't be too annoying.
I still think it is necessary to have a developer's build system
that is not encumbered by autotools or anything like that, and
can be edited for the truly wierd systems.
Re: [Gnucap-devel] gnucap development snapshot 2009-06-11, Kevin Bowling, 2009/06/14