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 attachment 68798 [details] 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!
