Bugzilla Bug 106496

Version rework-17 of ngspice was released on august 30th. Here is an ebuild for
it. Changelog compared to previous ebuild:
* revbumped to rework-17
* download location changed to sourceforge mirrors
* added sensitivity to 'debug' and 'readline' USE flags
* keyword ppc changed to ~ppc (so that it's unstable for all archictures until
it's confirmed OK)
* patch for gcc 3.4 no more needed

Created an attachment (id=68798) [edit]
ng-spice-rework-17.ebuild

*** Bug 109851 has been marked as a duplicate of this bug. ***

debug and readline USE flags now in the -17 ebuild; thanks!

(In reply to comment #3)
> debug and readline USE flags now in the -17 ebuild; thanks!
> 

Hello,

could anyone be so kind to add --enable-xspice config directive to the ebuild,
please? I suggest adding USE flag for this. The xspice is important feature in
my opinion and I believe users should be given an option whether they use
xspice or not. There was also a discusion in ng-spice mailing list about
enabling this feature as default. While many manufacturers provide only spice2
models (which use spice3-incompatible POLY() function) for their parts, the
user needs to enable this feature if he is to use these models.

I offer this modification for the existing ebuild:
--- ng-spice-rework-17.ebuild.old       2006-03-17 19:55:06.000000000 +0100
+++ ng-spice-rework-17.ebuild   2006-03-17 19:37:53.000000000 +0100
@@ -10,13 +10,14 @@
 LICENSE="BSD GPL-2"

 SLOT="0"
-IUSE="readline debug"
+IUSE="readline debug xspice"
 KEYWORDS="~amd64 ~ppc ~x86"

 DEPEND="readline? ( >=sys-libs/readline-5.0 )"

 src_compile() {
        econf \
+               $(use_enable xspice) \
                $(use_with debug) \
                $(use_with readline) || die "econf failed"
        emake || die "emake failed"

Hi Ludek,

1) Does it need a USE flag? I have tclspice just enable xspice support by
default; doesn't seem to cause problems. Does the xspice support cause
conflicts with existing spice2?

2) If so, use.local.desc needs updating, does this sound reasonable:

--- use.local.desc      17 Mar 2006 16:04:55 -0000      1.1786
+++ use.local.desc      17 Mar 2006 19:51:33 -0000
@@ -1211,6 +1211,7 @@
 sci-chemistry/caver:pymol - Install the PyMol plugin
 sci-chemistry/eden:double-precision - more precise calculations at the expense
of speed
 sci-chemistry/ghemical:mpqc - Use the MPQC package for quantum-mechanical
calculations
+sci-electronics/ng-spice-rework:xspice - Enable extended SPICE3 features for
code modelling and digital components
 sci-geosciences/gmt:gmtfull - Full resolution bathymetry database
 sci-geosciences/gmt:gmthigh - Adds high resolution bathymetry database
 sci-geosciences/gmt:gmtsuppl - Supplement functions for GMT

3) Ideally you should file a new bug or reopen, comments get lost sometimes on
resolved bugs.

(In reply to comment #5)
> 1) Does it need a USE flag? I have tclspice just enable xspice support by
> default; doesn't seem to cause problems. Does the xspice support cause
> conflicts with existing spice2?

Well, it doesn't need USE flag as long as it's enabled by default, but at this
moment it's not. Anyway, following the "gentoo's all about options" philosophy,
I think USE flag is ok for this. I don't know about any conflicts, but I did no
checks. Perhaps somebody else can verify it. I can't install tclspice on amd64
(emerge error)  :( and spice doesn't work for me (bug #84034 )

(In reply to comment #6)
> Well, it doesn't need USE flag as long as it's enabled by default, but at this
> moment it's not. Anyway, following the "gentoo's all about options" philosophy,

If you really want xspice, you can always activate it like this :
EXTRA_ECONF="--enable-xspice" emerge ng-spice-rework

Now, about having xpsice as a default is another story. I've had bad
experiences with it, but your mileage may (will) vary.

Hrm, I noticed enabling xspice dumps a lot of debug output when starting
ngspice, so the feature looks rather experimental...

(In reply to comment #8)
> Hrm, I noticed enabling xspice dumps a lot of debug output when starting
> ngspice, so the feature looks rather experimental...

True, plus doing a './configure --help' shows --enable-xspice as being
"officially" experimental.

Another feature that I can confirm breaks ng-spice under certain conditions is
numparam. I tried to fix it, but gave up (you should just have a look at the
code, for a good laugh). There were some allusions on the mailing list about
rewriting it totally.

Ok, you are right. The xspice feature *is* quite experimental, but doesn't the
whole package taste bit experimental? Although xspice can break things, it is
important part and feature of the ngspice package and I believe it's useful for
many people. At least for those who would like to use spice2 macromodels
released by manufacturers, as these models often contain polynomial sources. I
don't claim it should be enabled by default, but I think an USE flag is
appropriate for this. EXTRA_ECONF="--enable-xspice" does the job, but I
wouldn't call it "efficient". Aren't the USE flags designed for this? Oh come
on, it can't be that hard to add it...

--- use.local.desc      17 Mar 2006 16:04:55 -0000      1.1786
+++ use.local.desc      17 Mar 2006 19:51:33 -0000
@@ -1211,6 +1211,7 @@
 sci-chemistry/caver:pymol - Install the PyMol plugin
 sci-chemistry/eden:double-precision - more precise calculations at the expense
of speed
 sci-chemistry/ghemical:mpqc - Use the MPQC package for quantum-mechanical
calculations
+sci-electronics/ng-spice-rework:xspice - Enable extended SPICE3 features for
code modelling and digital components (bug #106496)
 sci-geosciences/gmt:gmtfull - Full resolution bathymetry database
 sci-geosciences/gmt:gmthigh - Adds high resolution bathymetry database
 sci-geosciences/gmt:gmtsuppl - Supplement functions for GMT

(In reply to comment #10)
> Ok, you are right. The xspice feature *is* quite experimental, but doesn't the
> whole package taste bit experimental? Although xspice can break things, it is
> important part and feature of the ngspice package and I believe it's useful for
> many people. At least for those who would like to use spice2 macromodels
> released by manufacturers, as these models often contain polynomial sources. I
> don't claim it should be enabled by default, but I think an USE flag is
> appropriate for this. EXTRA_ECONF="--enable-xspice" does the job, but I
> wouldn't call it "efficient". Aren't the USE flags designed for this? Oh come
> on, it can't be that hard to add it...
> 
> --- use.local.desc      17 Mar 2006 16:04:55 -0000      1.1786
> +++ use.local.desc      17 Mar 2006 19:51:33 -0000
> @@ -1211,6 +1211,7 @@
>  sci-chemistry/caver:pymol - Install the PyMol plugin
>  sci-chemistry/eden:double-precision - more precise calculations at the expense
> of speed
>  sci-chemistry/ghemical:mpqc - Use the MPQC package for quantum-mechanical
> calculations
> +sci-electronics/ng-spice-rework:xspice - Enable extended SPICE3 features for
> code modelling and digital components (bug #106496)
>  sci-geosciences/gmt:gmtfull - Full resolution bathymetry database
>  sci-geosciences/gmt:gmthigh - Adds high resolution bathymetry database
>  sci-geosciences/gmt:gmtsuppl - Supplement functions for GMT
> 

When I wrote 'experimental' about xspice above, it meant it is actually broken,
only in mild language. You can find hints of this on the ng-spice mailing
lists, and I have personnally  experienced it (and with fairly simple models,
even). So, since it is broken for at least a few of us, it means it isn't ready
for prime time yet.

However, feel free to compile it in, and report bugs upstream if you find any.

(In reply to comment #11)
> When I wrote 'experimental' about xspice above, it meant it is actually broken,
> only in mild language. You can find hints of this on the ng-spice mailing
> lists, and I have personnally  experienced it (and with fairly simple models,
> even). So, since it is broken for at least a few of us, it means it isn't ready
> for prime time yet.
> 
> However, feel free to compile it in, and report bugs upstream if you find any.
> 

Ok, no problem for me :) So this bug shell be marked WON'T or CLOSED
respectively?

Yours Ludek

(In reply to comment #12)
> Ok, no problem for me :) So this bug shell be marked WON'T or CLOSED
> respectively?

Guess so. If you think the situation has changed in future releases and it
feels stable enough please let us know. Thanks!