I think it's fine for macOS!
On Fri, Mar 19, 2021, 7:04 AM Wayne Stambaugh wrote:
> It seems as though we are heading towards a consensus that making the
> simulator build mandatory unless there is some strenuous objection to
> doing so by one of our package developers. I still want to give
>
It seems as though we are heading towards a consensus that making the
simulator build mandatory unless there is some strenuous objection to
doing so by one of our package developers. I still want to give
everyone a chance to reply before I make the change. In the mean time,
I think I'm going to
I would be fine with permanently enabling the ngspice integration. It has
historically not been that complicated to support, I mean build wise, and I
don't think it makes a lot of difference for rebuilds, which is where it
could be nice to disable some things, like scripting sometimes.
Speaking
I agree with Seth. The longer a feature is part of KiCad, the more people
will refer to it in forum posts, tutorials, etc. This feature has now
existed for plenty long enough for people to expect it. If there are no
packaging reasons to do otherwise, I support it being included in all
builds.
I agree that this is one area where we can improve the user experience.
By first-class, I mean only that it is an integral part of KiCad that we
develop and support. We are no longer in the testing phase where it would
make sense to have a conditional compilation.
-Seth
On Thu, Mar 18, 2021 at
You say it's first class but the spice gui needs alot of loving. The tool
framework is also ducktaped poorly into it.
On Thu, Mar 18, 2021 at 7:14 PM Seth Hillbrand wrote:
> Do we still need spice as a build option? It would be nice to bring down
> the number of permutations out there and the
That's an equally valid solution. Any of our package devs object to
this on the grounds that some platform doesn't support ngspice?
On 3/18/21 7:13 PM, Seth Hillbrand wrote:
> Do we still need spice as a build option? It would be nice to bring
> down the number of permutations out there and the
That was the option I meant but it would mean orphaned project file
settings when the spice simulator isn't built.
On 3/18/21 7:03 PM, Jon Evans wrote:
> Saving in the project file is fine, I just mean if you split out
> NGSPICE_SIMULATOR_SETTINGS to a different file (not sim/ngspice.h) with
> no
Do we still need spice as a build option? It would be nice to bring down
the number of permutations out there and the SPICE simulator is really a
first-class KiCad citizen nowadays.
-S
On Thu, Mar 18, 2021 at 4:04 PM Jon Evans wrote:
> Saving in the project file is fine, I just mean if you
Saving in the project file is fine, I just mean if you split out
NGSPICE_SIMULATOR_SETTINGS to a different file (not sim/ngspice.h) with no
dependencies on ngspice itself, the settings class can be built without
ngspice.
On Thu, Mar 18, 2021 at 6:57 PM Wayne Stambaugh
wrote:
> I thought about
I thought about that but in what context does a simulation make sense
out side of a schematic or a netlist generated from a schematic? I
saved the ngspice simulator settings in the project file because that is
the proper scope of the setting. I really don't see a more logical
place to save the
Wayne, I haven't checked this code carefully but I'd recommend building the
settings always, and moving the #ifdef to a different level (i.e. make the
settings not depend on ngspice)
That way if the same settings files are shared between a build with ngspice
and a build without, they won't get
My bad. I forgot the simulator was a build option so I will have to
#ifdef the offending settings code.
- Wayne
On 3/18/21 6:02 PM, Eeli Kaikkonen wrote:
> I have disabled ngspice in cmake settings but in a recent commit by
> Wayne #include , which in turn includes
> ngspice/sharedspice.h, was
I have disabled ngspice in cmake settings but in a recent commit by
Wayne #include , which in turn includes
ngspice/sharedspice.h, was added to schematic.cpp which makes
compilation fail apparently because I don't have ngspice at all.
Eeli Kaikkonen
14 matches
Mail list logo
