← Back to team overview

kicad-developers team mailing list archive

Re: Windows Builds

 

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


Follow ups

References