gnucap-devel
[Top][All Lists]
Advanced

[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/spice-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 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
> 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 
there.
-- 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). 

Headers.

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

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

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]