kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Nice work team!

On Wed, Jul 25, 2018, 1:57 PM Mark Roszko <mark.roszko@xxxxxxxxx> wrote:

> Appears Simon has handled it, the downloads are updated.
>
> I installed it and it no longer asserts.
>
> On Wed, Jul 25, 2018 at 1:20 PM Wayne Stambaugh <stambaughw@xxxxxxxxx>
> wrote:
> >
> > On 7/25/2018 12:54 PM, Mark Roszko wrote:
> > > * Simon's pull request.
> > >
> > > https://github.com/KiCad/kicad-winbuilder/pull/74
> >
> > Nick must have given me admin permissions so I merged Simon's pull
> > request.  The new release packages should be available shortly.  Do I
> > need to do anything to make sure the rebuilt packages are available on
> > the kicad download page?
> >
> > > On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh <stambaughw@xxxxxxxxx>
> wrote:
> > >>
> > >> I believe have github admin permissions at the org level.  Please post
> > >> the link to Mark's pull request and I will see if I can merge it.
> > >>
> > >> On 7/25/2018 12:29 PM, Adam Wolf wrote:
> > >>> Does anyone else have admin permissions at the org level?
> > >>>
> > >>> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh <stambaughw@xxxxxxxxx
> > >>> <mailto:stambaughw@xxxxxxxxx>> wrote:
> > >>>
> > >>>     On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > >>>     > @Wayne, The hold up on Windows was that Nick went on vacation
> > >>>     > basically the day after posting the first 5.0 build. So bad
> timing.>
> > >>>     >
> > >>>     >> I've changed it to Release for the time being (but someone
> still
> > >>>     needs to accept my pull request in GitHub)
> > >>>     >
> > >>>     > Unforunately Nick is the only one with privs on the winbuilder
> repo on
> > >>>     > github unless someone else does from the organization level
> access
> > >>>     > list.
> > >>>
> > >>>     I guess we will have to wait until Nick returns from vacation to
> get
> > >>>     this resolved.  Once he gets back, I'll ping him about having
> him assign
> > >>>     privileges to someone else as a backup so we don't get bit by
> this in
> > >>>     the future.
> > >>>
> > >>>     >
> > >>>     >> RelWithDebInfo should generate the same code as Release, and
> > >>>     after stripping debug information, the binaries should be
> identical.
> > >>>     >
> > >>>     > You know, looking at your commit, its interesting. Because
> PKGBUILD
> > >>>     > which you change from RelWithDebInfo to Release explicitly was
> always
> > >>>     > fine, the nightlies never gave that assert (I checked).
> > >>>     > But PKGBUILD-STABLE had no config specified....so perhaps it
> drifted
> > >>>     > to DEBUG somehow?
> > >>>     >
> > >>>     > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> > >>>     <Simon.Richter@xxxxxxxxxx <mailto:Simon.Richter@xxxxxxxxxx>>
> wrote:
> > >>>     >>
> > >>>     >> Hi,
> > >>>     >>
> > >>>     >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> > >>>     >>
> > >>>     >>> We should have created a release build of the stable version.
> > >>>     I'm fine
> > >>>     >>> with nightly builds having debugging information.  Stable
> releases
> > >>>     >>> should not have debug info.
> > >>>     >>
> > >>>     >> These are built as RelWithDebInfo, and the debug information
> is
> > >>>     stripped
> > >>>     >> out during installation, or rather should be (we're trying to
> > >>>     keep the
> > >>>     >> MSYS build as close to a standard Linux/BSD build as possible,
> > >>>     and they
> > >>>     >> usually archive the debug information separately before
> > >>>     stripping, which
> > >>>     >> is why this mode is useful at all).
> > >>>     >>
> > >>>     >> I've changed it to Release for the time being (but someone
> still
> > >>>     needs
> > >>>     >> to accept my pull request in GitHub), but this is indicative
> of a
> > >>>     bug in
> > >>>     >> the build scripts. RelWithDebInfo should generate the same
> code as
> > >>>     >> Release, and after stripping debug information, the binaries
> > >>>     should be
> > >>>     >> identical.
> > >>>     >>
> > >>>     >> There are two problems I see:
> > >>>     >>
> > >>>     >>  - we check explicitly if the build type is Release, which
> then
> > >>>     doesn't
> > >>>     >> match
> > >>>     >>  - we have a redundant -DDEBUG which is explicitly set —
> release
> > >>>     builds
> > >>>     >> have -DNDEBUG, which is set by CMake already, and this is
> what should
> > >>>     >> switch debugging facilities like asserts.
> > >>>     >>
> > >>>     >> I've submitted a patch to get rid of -DDEBUG two years ago, I
> > >>>     doubt it
> > >>>     >> still applies. I can make a new one if it has a chance of
> being
> > >>>     applied.
> > >>>     >>
> > >>>     >>    Simon
> > >>>     >>
> > >>>     >> _______________________________________________
> > >>>     >> Mailing list: https://launchpad.net/~kicad-developers
> > >>>     <https://launchpad.net/%7Ekicad-developers>
> > >>>     >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > >>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> > >>>     >> Unsubscribe : https://launchpad.net/~kicad-developers
> > >>>     <https://launchpad.net/%7Ekicad-developers>
> > >>>     >> More help   : https://help.launchpad.net/ListHelp
> > >>>     >
> > >>>     >
> > >>>     >
> > >>>
> > >>>     _______________________________________________
> > >>>     Mailing list: https://launchpad.net/~kicad-developers
> > >>>     <https://launchpad.net/%7Ekicad-developers>
> > >>>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > >>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> > >>>     Unsubscribe : https://launchpad.net/~kicad-developers
> > >>>     <https://launchpad.net/%7Ekicad-developers>
> > >>>     More help   : https://help.launchpad.net/ListHelp
> > >>>
> > >>
> > >> _______________________________________________
> > >> Mailing list: https://launchpad.net/~kicad-developers
> > >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > >> Unsubscribe : https://launchpad.net/~kicad-developers
> > >> More help   : https://help.launchpad.net/ListHelp
> > >
> > >
> > >
>
>
>
> --
> Mark
>