Patch committed in rev 6635. Thank you.
;)
On Wed, Apr 06, 2016 at 05:31:37AM +0200, Simon Richter wrote:
> Hi,
>
> On 06.04.2016 05:19, Simon Richter wrote:
>
> > This enables C++11 support, if either CMake is sufficiently new to have
> > this feature built in, or the compiler is supported
Hi,
On 06.04.2016 05:19, Simon Richter wrote:
> This enables C++11 support, if either CMake is sufficiently new to have
> this feature built in, or the compiler is supported by the workaround code
> (gcc or clang).
Meh, that patch was still in the temp dir where I stage mails before
sending. As
This enables C++11 support, if either CMake is sufficiently new to have
this feature built in, or the compiler is supported by the workaround code
(gcc or clang).
---
CMakeLists.txt | 23 +++
1 file changed, 23 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index
While I agree with you in principal, I have a feeling that we will loose
some dev branch testers by doing this. How many is hard to say but
development branch testers are a valuable resource. They tend to find
things that developers miss.
On 3/21/2016 3:38 PM, Chris Pavlina wrote:
> 16.04 LTS
Le 21/03/2016 20:38, Chris Pavlina a écrit :
16.04 LTS will be released in April. Personally I think we should be free to
stop supporting 14.04 Geriatric Giraffe already in the development branch - why
should a devel branch of kicad support non-devel branches of Ubuntu? KiCad
stable runs on
16.04 LTS will be released in April. Personally I think we should be free to
stop supporting 14.04 Geriatric Giraffe already in the development branch - why
should a devel branch of kicad support non-devel branches of Ubuntu? KiCad
stable runs on Ubuntu "stable" (LTS). But I seem to be in the
Le 21/03/2016 20:28, Chris Pavlina a écrit :
> Are we sure this isn't the issue where cmake forgets to rebuild
> pcbnewPYTHON_wrap.cxx? I've been having that issue about once every couple
> weeks for a while, just delete it and rebuild :P
>
Yes, I used a fresh build folder, and tried more than
Le 21/03/2016 20:13, Nick Østergaard a écrit :
> 2016-03-21 20:10 GMT+01:00 jp charras :
>> Le 21/03/2016 19:54, Nick Østergaard a écrit :
>>> 2016-03-21 19:52 GMT+01:00 jp charras :
Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
> Going,
Le 21/03/2016 20:11, Wayne Stambaugh a écrit :
> On 3/21/2016 3:10 PM, jp charras wrote:
>> Le 21/03/2016 19:54, Nick Østergaard a écrit :
>>> 2016-03-21 19:52 GMT+01:00 jp charras :
Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
> Going, going, gone! Since I
Are we sure this isn't the issue where cmake forgets to rebuild
pcbnewPYTHON_wrap.cxx? I've been having that issue about once every couple
weeks for a while, just delete it and rebuild :P
On Mon, Mar 21, 2016 at 08:13:48PM +0100, Nick Østergaard wrote:
> 2016-03-21 20:10 GMT+01:00 jp charras
2016-03-21 20:10 GMT+01:00 jp charras :
> Le 21/03/2016 19:54, Nick Østergaard a écrit :
>> 2016-03-21 19:52 GMT+01:00 jp charras :
>>> Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
Going, going, gone! Since I haven't gotten any objections, I
On 3/21/2016 3:10 PM, jp charras wrote:
> Le 21/03/2016 19:54, Nick Østergaard a écrit :
>> 2016-03-21 19:52 GMT+01:00 jp charras :
>>> Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
Going, going, gone! Since I haven't gotten any objections, I committed
the patch
2016-03-21 19:54 GMT+01:00 Nick Østergaard :
> 2016-03-21 19:52 GMT+01:00 jp charras :
>> Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
>>> Going, going, gone! Since I haven't gotten any objections, I committed
>>> the patch to enable C++11. Thanks
Le 21/03/2016 19:54, Nick Østergaard a écrit :
> 2016-03-21 19:52 GMT+01:00 jp charras :
>> Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
>>> Going, going, gone! Since I haven't gotten any objections, I committed
>>> the patch to enable C++11. Thanks Simon for the patch
Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
> Going, going, gone! Since I haven't gotten any objections, I committed
> the patch to enable C++11. Thanks Simon for the patch but be prepared
> for the grumbling. :)
>
On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
We should hold off on using any c++11 specific code for a while just in
case we have to remove this patch. If we make it a month without having
to pull the patch, then we can start using c++11 stuff.
On 3/21/2016 11:27 AM, Chris Pavlina wrote:
> Someone should probably ask - apologies if someone
Someone should probably ask - apologies if someone already did: Do you have a
policy in mind for using C++11 features in new patches? It may be prudent to
let the patch settle for a few days just to make sure nobody else has build
trouble before we start making it harder to back out.
On Mon, Mar
Going, going, gone! Since I haven't gotten any objections, I committed
the patch to enable C++11. Thanks Simon for the patch but be prepared
for the grumbling. :)
On 3/18/2016 3:42 PM, Wayne Stambaugh wrote:
> I tested this on my Debian testing and it seemed fine. It is 2016 after
> all so I
I tested this on my Debian testing and it seemed fine. It is 2016 after
all so I guess it's time to jump into the C++11 waters if there are no
objections. I figure we'll be good to roll out C++14 in 2019 or 2020. :).
On 3/18/2016 12:08 AM, Simon Richter wrote:
> Hi Wayne,
>
> On 17.03.2016
I tested this patch on msys1/mingw32 (gcc 4.7.2), msys2/mingw32 (gcc
5.3.0), and msys2/mingw64 (gcc 5.3.0) and kicad compiles and runs
without any issues other than a few new compiler warnings. I'm using
cmake 3.4.1 on all three platforms.
@Simon, when cmake is < 3.1 you set the -std-c++11 flag
Hi.
To jp, look at cmake properties CXX_STANDARD, CXX_STANDARD_REQUIRED,
CXX_EXTENSIONS.
[https://cmake.org/cmake/help/v3.4/manual/cmake-properties.7.html](https://lin
k.nylas.com/link/ac7n0u7eu8cj6vjow9ajimqdr/4174df36c5bf4561b73f89e228f5d608/0?
Hi Wayne,
On 17.03.2016 20:35, Wayne Stambaugh wrote:
> @Simon, when cmake is < 3.1 you set the -std-c++11 flag for gcc and
> clang instead of the -gnu-c++11. This seems to be an issue that should
> be addressed. Maybe this is what is breaking @Mark's builds. I would
> feel more comfortable
Le 10/03/2016 08:30, Simon Richter a écrit :
>
> This enables C++11 support, if either CMake is sufficiently new to have
> this feature built in, or the compiler is supported by the workaround code
> (gcc or clang).
> ---
> CMakeLists.txt | 23 +++
> 1 file changed, 23
2016-03-17 10:15 GMT+01:00 jp charras :
> Le 10/03/2016 08:30, Simon Richter a écrit :
>>
>> This enables C++11 support, if either CMake is sufficiently new to have
>> this feature built in, or the compiler is supported by the workaround code
>> (gcc or clang).
>> ---
>>
Le 17/03/2016 10:23, Nick Østergaard a écrit :
> 2016-03-17 10:15 GMT+01:00 jp charras :
>> Le 10/03/2016 08:30, Simon Richter a écrit :
>>>
>>> This enables C++11 support, if either CMake is sufficiently new to have
>>> this feature built in, or the compiler is supported by
Hi,
On 12.03.2016 18:04, Mark Roszko wrote:
> But o well, screw it, undoubtedly someone will get the issue
> eventually later but screw wasting time finding what it was.
Agreed. One thing we should look into though is actually getting Ubuntu
bug reports.
I know that there are several people
They are VMs they spawn on the fly and apt-get from ubuntu upstream. I
literally have to tell it to apt-get gcc.
But o well, screw it, undoubtedly someone will get the issue
eventually later but screw wasting time finding what it was.
___
Mailing list:
Maybe that VM was not up to date?
Den 12/03/2016 17.39 skrev "Mark Roszko" :
> The problems for me occurred when I made TravisCI build KiCadsigh
> probably some sort of difference I am forgeting but they use Ubuntu 14
> build VMs.
>
> On Fri, Mar 11, 2016 at 4:09 PM,
I just tried to build on ubuntu 14.04 with the first patch from Simon
and it built without any problems. And that is with boost 1.54 and not
python scripting enabled. This was tested in a docker container.
2016-03-11 21:52 GMT+01:00 Wayne Stambaugh :
> I would prefer a
I would prefer a solution to fix this before I commit the patch.
On 3/11/2016 1:01 PM, Mark Roszko wrote:
> The issue is with gcc 4.8 which has C++11 but funny #defines. Boost
> 1.55 only adds flags that have to be enabled manually to work around it.
> Ubuntu 14 has gcc4.8. Debian Jessie has
The issue is with gcc 4.8 which has C++11 but funny #defines. Boost
1.55 only adds flags that have to be enabled manually to work around it.
Ubuntu 14 has gcc4.8. Debian Jessie has gcc4.9.
___
Mailing list: https://launchpad.net/~kicad-developers
Post
Hi,
On 11.03.2016 17:48, Wayne Stambaugh wrote:
> It still sounds to me that boost needs to be bumped to 1.55 and possibly
> some definitions need to added to the build configuration for Boost to
> build properly.
Hm, compiling worked for me with Boost 1.55 on Debian with no further
changes.
It still sounds to me that boost needs to be bumped to 1.55 and possibly
some definitions need to added to the build configuration for Boost to
build properly. If someone can include those changes along with Simon's
original patch. I'll give it go and commit it if I don't have any
issues. If
It doesn't seem to me that enabling a config macro as well is really all that
much.
Since we're still in the heavy development phase of the cycle, I personally
think that this is the absolute _best_ time to do things like enabling C++11.
We're not making any major releases now, so we have plenty
This is why I have been reluctant to make C++11 the default. There are
just too many legacy systems around where it would cause issues. I'm OK
with bumping the boost version to 1.55 because I think the impact of
that would be minimal but if we have to do much more that that, we may
want to hold
Well, I guess it the patch is modified to use gnu++11 for gcc it
should be fine then.
2016-03-10 15:40 GMT+01:00 Mark Roszko :
> boost 1.55 only adds the the flag you now have to set to workaround.
>
>>Fixed in Git develop: I've added and documented two config macros:
>>
boost 1.55 only adds the the flag you now have to set to workaround.
>Fixed in Git develop: I've added and documented two config macros:
> BOOST_MATH_USE_FLOAT128 and BOOST_MATH_DISABLE_FLOAT128 which explicitly
> enable/disable this feature.
> Defining the latter macro should fix things for
What about bumping the boost version requirement to 1.55?
Debain stable jessie has 1.55 [1] and it seems that ubuntu 14.04
trusty also has 1.55 [2].
Given that the issue is only with boost 1.54.
[1]
https://packages.debian.org/search?keywords=libboost=names=stable=all
[2]
This enables C++11 support, if either CMake is sufficiently new to have
this feature built in, or the compiler is supported by the workaround code
(gcc or clang).
---
CMakeLists.txt | 23 +++
1 file changed, 23 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index
39 matches
Mail list logo