← Back to team overview

kicad-developers team mailing list archive

Re: C++14 (redux)

 

Hi Wayne-

Sounds good. I've removed the libglm hold. This will make building on Buster easier going forward.

-Seth

On 2019-08-06 16:28, Wayne Stambaugh wrote:
Ian,

We have had our own make_unique implementation for quite some time (see
include/make_unique.h) so even without c++14, you can use make_unique.
This includes the 5.1 branch.  The master branch is c++14 where the 5.1
branch is c++11 so as long as you are not fixing anything that would
need cherry picked to the 5.1 branch, then c++14 is acceptable.

Cheers,

Wayne

On 8/6/19 4:21 PM, Ian McInerney wrote:
Is the master branch now open for C++14-based code submissions, or are
we still waiting some before allowing them? (I have a change that would benefit greatly from make_unique, but I can hold off on it until we are
open).

-Ian

On Fri, Jul 12, 2019 at 4:16 PM Nick Østergaard <oe.nick@xxxxxxxxx
<mailto:oe.nick@xxxxxxxxx>> wrote:

    Yes, using gnu+14 on windows

    fre. 12. jul. 2019 15.34 skrev Seth Hillbrand <seth@xxxxxxxxxxxxx
    <mailto:seth@xxxxxxxxxxxxx>>:

        Thanks Nick!  I pushed the patch to the master branch on
        Wednesday. 
Ubunutu, Mac and Windows all appear to have built their nightlies without problem.  I was going to check in on Fedora this weekend
        but
        this seems like a quiet transition so far.  :)

        -Seth

        On 2019-07-12 05:00, Nick Østergaard wrote:
        > Just for the record, I did build test it on msys2/mingw on
        windows, I
        > added these args to cmake.
        >
        > -DCMAKE_CXX_STANDARD=14 \
        > -DCMAKE_CXX_STANDARD_REQUIRED=ON \
        > -DCMAKE_CXX_EXTENSIONS=OFF \
        > -DCMAKE_CXX_FLAGS=-U__STRICT_ANSI__ \
        >
> The __STRICT_ANSI__ is required because of using wx 3.0 as far
        as I
        > understand it, Simon shared below patch to me.
        >
        > http://psi5.com/~geier/extensions.diff
        >
        > I did not runtime test it, but it built just fine for x86_64
        at least.
        >
        > On Wed, 10 Jul 2019 at 21:03, Wayne Stambaugh
        <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
        > wrote:
        >>
        >> Seth,
        >>
>> That's fine but we might want to give it more than a week or
        two.  I
        >> was
        >> thinking more like a month or two.
        >>
        >> Wayne
        >>
        >> On 7/10/19 2:06 PM, Seth Hillbrand wrote:
        >> > Hi Wayne-
        >> >
        >> > No worries!
        >> >
        >> > How about this:  We bump the C++ version in cmake but not
        put any C++14
        >> > code into the codebase for a week or two to see if there
        are any issues
        >> > with supported platform packagers.  If there are issues
        with supported
        >> > platforms, we revert and wait for v7.  If not, we start
        allow C++14 code.
        >> >
        >> > -Seth
        >> >
        >> >
        >> > On 2019-07-10 13:00, Wayne Stambaugh wrote:
        >> >> Hey Seth,
        >> >>
        >> >> Sorry for the delayed response, this got lost in my
        inbox.  I'm on the
        >> >> fence about this.  My gut says push it v7 development
        given the amount
>> >> of work we have to do for v6 but I'm not opposed to it as
        long as we can
        >> >> build it on all of our supported platforms.
        >> >>
        >> >> Cheers,
        >> >>
        >> >> Wayne
        >> >>
        >> >> On 7/5/19 3:52 PM, Seth Hillbrand wrote:
        >> >>> Hi Wayne-
        >> >>>
        >> >>> This shouldn't affect users, only developers.  Once the
        binary is built,
>> >>> there are no differences in requirements for running KiCad.
        >> >>>
        >> >>> I would only push this to master and not 5.1, so that
        5.1.3+ bug fixes
>> >>> will still build for 14.04 (which was supported when 5.1
        was released).
        >> >>>
        >> >>> -Seth
        >> >>>
        >> >>>
        >> >>> On 2019-07-05 14:30, Wayne Stambaugh wrote:
        >> >>>> Hey Seth,
        >> >>>>
        >> >>>> Sorry about the delay.  I've been wrestling (and
        loosing) with
        >> >>>> restoring
>> >>>> a broken boot manager on my desktop after a bios update
        stepped all
        >> >>>> over
>> >>>> my uefi boot configuration (thank you HP).  I would like
        to hold off on
>> >>>> C++14 for a while.  I suspect there are users who prefer
        running older
        >> >>>> linux distros for stability purposes.  I would rather
        not throw those
        >> >>>> users under a bus just yet unless we have enough
        credible evidence that
        >> >>>> it wont be an issue.  I suppose we could always put it
        out there and
        >> >>>> see
        >> >>>> who screams and undo the changes as needed.
        >> >>>>
        >> >>>> Cheers,
        >> >>>>
        >> >>>> Wayne
        >> >>>>
        >> >>>> On 7/1/19 7:20 PM, Seth Hillbrand wrote:
        >> >>>>> Hi Devs-
        >> >>>>>
        >> >>>>> Now that Ubuntu 14.04LTS support has ended, are we
        building any
        >> >>>>> platforms that do not support C++14 (gcc prior to
        version 5)?
        >> >>>>>
        >> >>>>> If not, can we bump our compiler language support to
        C++14?  This
        >> >>>>> would
        >> >>>>> allow us to drop the ban on certain version of GLM as
        well as our
        >> >>>>> custom-rolled std::make_unique.  There are a few
        language features
        >> >>>>> (generalized lambda captures!) that would tighten up
        quite a bit of
        >> >>>>> code
        >> >>>>> if available.
        >> >>>>>
        >> >>>>> Obviously if we are still supporting a C++11 only
        system, this
        >> >>>>> should be
        >> >>>>> delayed.
        >> >>>>>
        >> >>>>> Best-
        >> >>>>> Seth
        >> >>>>>
        >> >>>>> _______________________________________________
        >> >>>>> Mailing list: https://launchpad.net/~kicad-developers
        >> >>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
        <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
        >> >>>>> Unsubscribe : https://launchpad.net/~kicad-developers
        >> >>>>> More help   : https://help.launchpad.net/ListHelp
        >> >>>>
        >> >>>> _______________________________________________
        >> >>>> Mailing list: https://launchpad.net/~kicad-developers
        >> >>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
        <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
        >> >>>> Unsubscribe : https://launchpad.net/~kicad-developers
        >> >>>> More help   : https://help.launchpad.net/ListHelp
        >>
        >> _______________________________________________
        >> Mailing list: https://launchpad.net/~kicad-developers
        >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
        <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
        >> Unsubscribe : https://launchpad.net/~kicad-developers
        >> More help   : https://help.launchpad.net/ListHelp

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


_______________________________________________
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


References