kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
>