kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #32687
Re: Simulator towards 5.0
I just pushed the updated build config with all of the options enabled
except KICAD_SCRIPTING_ACTION_MENU. We shall see how this plays out.
On 12/28/2017 07:09 PM, Nick Østergaard wrote:
> I think the original patch on the 5th of dec from Christoffer is useful.
> This enables the mentioned options. This is without the spice message
> thing, which I think is redundant and not pretty if we include Maciej's
> patch to print the build config, 7th of dec patch.
>
> Nick
>
> 2017-12-27 23:49 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>>:
>
> All of your arguments are valid. For me personally, I'm fine with
> enabling everything that's ready for release since I build from source
> and it's not an issue on any of the platforms I use for development. If
> that is the consensus, then I will enable them. I'm just trying to be
> fair to our package devs.
>
> On 12/27/2017 05:42 PM, Nick Østergaard wrote:
> > 2017-12-27 23:04 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
> > <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>:
> >
> > Here are my thoughts on the current options that are disable
> be default.
> > Nothing is experimental except USE_WX_GRAPHICS_CONTEXT which
> really
> > shouldn't be used and the WX_OVERLAY which is macos specific.
> >
> > KICAD_SCRIPTING, I'm fine with setting this to ON now that we
> have a
> > sane solution for Python scripting on windows. All other
> platforms
> > should have python 2 support for the foreseeable future.
> >
> > KICAD_SCRIPTING_MODULES, this can be enabled as well sense it
> goes hand
> > in hand with KICAD_SCRIPTING.
> >
> > KICAD_SCRIPTING_WXPYTHON, this is not as clear cut as it would
> seem.
> > Sometimes the wxPython build gets out of sync with the
> wxWidgets builds
> > on certain platforms which is known to cause issues. Enabling
> this
> > could cause issues for package devs.
> >
> >
> > It will also if they enable it explicitly... On multiple platforms
> this
> > ABI check between wx and wxpython is not marked as fatal and only
> > servers as a hint that you should poke the maintainers to rebuild
> > wxpython. For some reason they seems to remember to rebuild wx
> when the
> > compiler gets updated but not wxpython. But they should really do it,
> > there is no reason no to.
> >
> >
> >
> > KICAD_SCRIPTING_ACTION_MENU AFAIK depends on
> KICAD_SCRIPTING_WXPYTHON so
> > enabling this will dependent upon enabling
> KICAD_SCRIPTING_WXPYTHON.
> >
> >
> > And then what? The packager can still disable those options if he
> needs
> > to. IMHO it is better that the packager does not need to explicitly
> > enable any options to get a kicad build configuration that we
> advertise
> > as working features. All those features do work on all the three major
> > platforms. Linux, windows and macos.
> >
> >
> >
> > KICAD_USE_OCE, I'm not so comfortable enabling this by default
> due to
> > issues between version of OCE. It might be best if this is
> left up to
> > the package devs.
> >
> >
> > What issues are we talking about here? If we never enable it we
> will not
> > discover the issue as quickly as we could. We are not removing control
> > from the packager here. He can still disable the option if it
> causes him
> > any isses.
> >
> >
> >
> > KICAD_USE_SPICE, I'm not comfortable enabling this due to the
> fact that
> > some linux packages of ngspice do not build with --libngspice
> enabled
> > which will cause build config issues. I would to default to
> the package
> > devs to enable this as necessary.
> >
> >
> > This is the issue of the packager on that system. If he is lazy he can
> > start by disabling this option untill he gets time to fix his
> platforms
> > ngspice package. It should be good now that a release of ngspice have
> > been made that has our required fixes. If the ngspice people did not
> > make that release I would be okay with having it off by default.
> >
> >
> >
> > On 12/09/2017 11:46 AM, Kristoffer Ödmark wrote:
> > > I think that this message is important, and I feel a
> decision on this
> > > matter features has to be done by the project manager, basically
> > give a
> > > pointer to what should be used to as far extent as possible.
> > >
> > > Wayne, this is a package dev that wants to know this and while I
> > do not
> > > know who are package devs, the only package dev has expressed a
> > need for
> > > this decision. Please dont just ignore it.
> > >
> > > And yes, the coming patch submissions is dependent on what
> > features are
> > > deemed "standard"
> > >
> > > -Kristoffer
> > >
> > > On 12/07/2017 08:58 PM, Simon Richter wrote:
> > >> Hi,
> > >>
> > >> On 07.12.2017 19:08, Wayne Stambaugh wrote:
> > >>
> > >>> Yes, that is exactly what I'm saying. it is possible kicad
> > could have
> > >>> different feature sets depending on the availability of
> > dependencies on
> > >>> the target platform. The kicad project has no control over
> > this. If a
> > >>> platform doesn't have dependency support for spice, they
> can still
> > >>> provide a kicad package without spice support. That's better
> > than no
> > >>> kicad.
> > >>
> > >> Right, but we still need to give some guidance on the status of
> > >> features. As it is now, new features are introduced as
> default-off
> > >> "experimental" stuff that is only to be used by a select
> few, then at
> > >> some point we enable it for nightlies, mostly driven by
> > availability of
> > >> dependencies and a vague feeling that features should be
> tested,
> > and at
> > >> some point the feature has become something that should
> have been
> > >> enabled by default a long time ago (but nobody can tell the
> exact
> > date
> > >> when).
> > >>
> > >> We need a bit of a process here to promote feature status, e.g.
> > >>
> > >> experimental new stuff, not for general use
> > >> optional => add to nightlies
> > >> standard => enable by default
> > >> required => remove option
> > >>
> > >> I think all the new features for v5 have reached "optional"
> > status, and
> > >> they have been enabled in nightlies as far as possible. The
> next
> > >> question is whether they are "standard" and should be part
> of the
> > stable
> > >> release, including questions by users and a commitment to file
> > >> compatibility. Probably yes, but this is a project management
> > decision
> > >> that will affect requirements for patch submissions in the next
> > release
> > >> cycle, so it needs to be an explicit decision.
> > >>
> > >> Simon
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> > <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> > >> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> > <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
> > >> Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> > <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> > >> More help : https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>
> > <https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>>
> > >>
> > >
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> > <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> > > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> > <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> > <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> > > More help : https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>
> > <https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>>
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> > <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> > <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
> > Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> > <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> > More help : https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>
> > <https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>>
> >
> >
>
>
Follow ups
References
-
Simulator towards 5.0
From: Kristoffer Ödmark, 2017-12-04
-
Re: Simulator towards 5.0
From: Nick Østergaard, 2017-12-05
-
Re: Simulator towards 5.0
From: Maciej Sumiński, 2017-12-05
-
Re: Simulator towards 5.0
From: Nick Østergaard, 2017-12-05
-
Re: Simulator towards 5.0
From: Maciej Sumiński, 2017-12-05
-
Re: Simulator towards 5.0
From: Simon Richter, 2017-12-05
-
Re: Simulator towards 5.0
From: Kristoffer Ödmark, 2017-12-06
-
Re: Simulator towards 5.0
From: Simon Richter, 2017-12-06
-
Re: Simulator towards 5.0
From: Kristoffer Ödmark, 2017-12-06
-
Re: Simulator towards 5.0
From: Wayne Stambaugh, 2017-12-07
-
Re: Simulator towards 5.0
From: kristoffer Ödmark, 2017-12-07
-
Re: Simulator towards 5.0
From: Wayne Stambaugh, 2017-12-07
-
Re: Simulator towards 5.0
From: Simon Richter, 2017-12-07
-
Re: Simulator towards 5.0
From: Kristoffer Ödmark, 2017-12-09
-
Re: Simulator towards 5.0
From: Wayne Stambaugh, 2017-12-27
-
Re: Simulator towards 5.0
From: Nick Østergaard, 2017-12-27
-
Re: Simulator towards 5.0
From: Wayne Stambaugh, 2017-12-27
-
Re: Simulator towards 5.0
From: Nick Østergaard, 2017-12-29