kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

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>:

> 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>>:
> >
> >     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>
> >     >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >     >> Unsubscribe : https://launchpad.net/~kicad-developers
> >     <https://launchpad.net/~kicad-developers>
> >     >> More help   : https://help.launchpad.net/ListHelp
> >     <https://help.launchpad.net/ListHelp>
> >     >>
> >     >
> >     > _______________________________________________
> >     > Mailing list: https://launchpad.net/~kicad-developers
> >     <https://launchpad.net/~kicad-developers>
> >     > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >     > Unsubscribe : https://launchpad.net/~kicad-developers
> >     <https://launchpad.net/~kicad-developers>
> >     > More help   : https://help.launchpad.net/ListHelp
> >     <https://help.launchpad.net/ListHelp>
> >
> >     _______________________________________________
> >     Mailing list: https://launchpad.net/~kicad-developers
> >     <https://launchpad.net/~kicad-developers>
> >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >     Unsubscribe : https://launchpad.net/~kicad-developers
> >     <https://launchpad.net/~kicad-developers>
> >     More help   : https://help.launchpad.net/ListHelp
> >     <https://help.launchpad.net/ListHelp>
> >
> >
>