[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] gnucap development snapshot 2009-06-11

From: al davis
Subject: Re: [Gnucap-devel] gnucap development snapshot 2009-06-11
Date: Sun, 28 Jun 2009 18:44:36 -0400
User-agent: 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
> ../Gnucap/
> /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, points a translation
> unit in the base package.  Is 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. 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
> plug-ins? 

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

load pluginname
--- loads it from the public place
load path/to/pluginname
--- I'm sure you can figure this one out, such as:
load ./pluginname
--- 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 ( 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 
like this.  

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 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/ (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.)

Possibly ...

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.

Been there!

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]