Re: [Bf-committers] Proposal to switch both master and blender2.8 to c++11 be default.

[Sergey Sharybin]

S o just follow up after discussion in private IM with Martijn.

There is no real urge to change anything in master in this context. So
better just to leave things as is for now. Saves frustration of folks who
will start getting compilation error and will save our time looking into
those issues.

What we think is reasonable to do is to have new C++11 builds in the
"Experimental" section of buildbot. This will let us to test such builds
early on without affecting possible releases and builds of master before we
release 2.80. Being in "Experimental" section should also be clear for
users who goes to builder.b.o and who will likely have question which ABI
to download.

To make "Experimental" section more clear we can promote MSVC 2015 builds
as official and retire 2013 builds.

Not sure yet whether new buildbot builds better be master of 2.9 branch tho.

Guess that makes all parties happy here?

On Sun, Nov 20, 2016 at 10:17 PM, Martijn Berger 
wrote:

> This cost is a one time thing we will incur anyway.
>
> Users should not really experience anything except maybe having blenders
> choices line up with the python official version better.
>
> The main benefit it having one environment in which to build 2.8 and if we
> ever have to do a 2.7 we can do it in that environment as well.
>
> C++11 / C11 have been the default mode for our main compilers for some
> time. Apple actively warns with each invocation of the compiler that uses
> libstdc++.
> And even Debian is transitioning.
>
> I get that there are always arguments for being conservative, but for the
> MacOS platform i think it is better to switch and also reap the benefits of
> better rebuild-able libraries.
> For all platforms i think it would be to be consistent. We default to C++11
> in the case of gcc 6 and above ( likely due to that compiler defaulting to
> c+11 ) But for clang 3.6 and above this is not done. For any MSVC 2012 or
> better this argument would also hold.
>
>
> On Sun, Nov 20, 2016 at 9:58 PM, Sergey Sharybin 
> wrote:
>
> > So is it all for the locally-compiled Blender (meaning, both releases and
> > buildbots stays the same as is)?
> >
> > Keep in mind, while it might be fine on Windows/OSX you'll have some
> major
> > problems on Linux (users will lat least need to re-compile all
> > dependencies). And sure enough they'll run into weird compilation /
> linking
> > errors (shall i here note that the guy who proposes to bump something
> must
> > become responsive for the users communication and figuring out their
> > problems caused by the bump? ;)
> >
> > Still either i'm missing something, or so far the motivation behind such
> a
> > change is because we can do it. What are the benefits for users? What is
> > the problem you're solving here? Why to rush such a thing?
> >
> >
> > On Sun, Nov 20, 2016 at 9:44 PM, Martijn Berger <
> martijn.ber...@gmail.com>
> > wrote:
> >
> > > On Sun, Nov 20, 2016 at 9:00 PM, Mike Erwin  >
> > > wrote:
> > >
> > > > On Sun, Nov 20, 2016 at 8:45 AM, Martijn Berger <
> > > martijn.ber...@gmail.com>
> > > > wrote:
> > > > >
> > > > >
> > > > > The only mayor downside i see is that we would effectively drop OS
> X
> > > 10.8
> > > > > and earlier.
> > > > >
> > > >
> > > > Eek, dropping 10.6, 10.7 and 10.8 was not on our Blender 2.7x
> roadmap.
> > > This
> > > > would prevent 2.79 from running on lots of Macs that could handle it
> > (GL
> > > > 2.1 capable GPUs). Those same Macs are stuck with older GPUs so
> > deciding
> > > to
> > > > drop them for Blender 2.8 was easier.
> > > >
> > > We never roadmapped dropping WIndows XP. That still has more users then
> > > 10.7 and 10.8 combined judging form our google analytics.
> > > 10.9 will soon be dropped from the official support roster by Apple.
> > >
> > > >
> > > > Most people are running latest OS & Xcode and it is annoying to not
> be
> > > able
> > > > to type "make full" and run. By default I agree this should work. No
> > > hoops!
> > > >
> > > It is not just about that. Most compilers and other packages are
> > defaulting
> > > to it. Compiling binary python stuff for use with the official blender
> > > makes you jump through more hoops then most people can. Not many people
> > > have a version of python compiled with msvc 2013 on windows when it is
> > > officially deprecated and the official python release is with 2015. A
> > > similar argument can be made for almost any package for python that
> > > contains native code on MacOS they all use libc++ as that is the
> default.
> > >
> > > >
> > > > Can we keep the ability to build for 10.6 thru 10.8 using an *older*
> > > > Xcode/SDK? I keep a drive with 10.9 & older Xcode, but am not a build
> > > > system guru.
> > > >
> > > Sure. release is not build on a machine that is kept up to date. It is
> > > build on OS X 10.9 with code 6.3 and a clang version compiled by Jens.
> > >
> > > >
> > > > For our next release we 

Re: [Bf-committers] Proposal to switch both master and blender2.8 to c++11 be default.

[Martijn Berger]

This cost is a one time thing we will incur anyway.

Users should not really experience anything except maybe having blenders
choices line up with the python official version better.

The main benefit it having one environment in which to build 2.8 and if we
ever have to do a 2.7 we can do it in that environment as well.

C++11 / C11 have been the default mode for our main compilers for some
time. Apple actively warns with each invocation of the compiler that uses
libstdc++.
And even Debian is transitioning.

I get that there are always arguments for being conservative, but for the
MacOS platform i think it is better to switch and also reap the benefits of
better rebuild-able libraries.
For all platforms i think it would be to be consistent. We default to C++11
in the case of gcc 6 and above ( likely due to that compiler defaulting to
c+11 ) But for clang 3.6 and above this is not done. For any MSVC 2012 or
better this argument would also hold.


On Sun, Nov 20, 2016 at 9:58 PM, Sergey Sharybin 
wrote:

> So is it all for the locally-compiled Blender (meaning, both releases and
> buildbots stays the same as is)?
>
> Keep in mind, while it might be fine on Windows/OSX you'll have some major
> problems on Linux (users will lat least need to re-compile all
> dependencies). And sure enough they'll run into weird compilation / linking
> errors (shall i here note that the guy who proposes to bump something must
> become responsive for the users communication and figuring out their
> problems caused by the bump? ;)
>
> Still either i'm missing something, or so far the motivation behind such a
> change is because we can do it. What are the benefits for users? What is
> the problem you're solving here? Why to rush such a thing?
>
>
> On Sun, Nov 20, 2016 at 9:44 PM, Martijn Berger 
> wrote:
>
> > On Sun, Nov 20, 2016 at 9:00 PM, Mike Erwin 
> > wrote:
> >
> > > On Sun, Nov 20, 2016 at 8:45 AM, Martijn Berger <
> > martijn.ber...@gmail.com>
> > > wrote:
> > > >
> > > >
> > > > The only mayor downside i see is that we would effectively drop OS X
> > 10.8
> > > > and earlier.
> > > >
> > >
> > > Eek, dropping 10.6, 10.7 and 10.8 was not on our Blender 2.7x roadmap.
> > This
> > > would prevent 2.79 from running on lots of Macs that could handle it
> (GL
> > > 2.1 capable GPUs). Those same Macs are stuck with older GPUs so
> deciding
> > to
> > > drop them for Blender 2.8 was easier.
> > >
> > We never roadmapped dropping WIndows XP. That still has more users then
> > 10.7 and 10.8 combined judging form our google analytics.
> > 10.9 will soon be dropped from the official support roster by Apple.
> >
> > >
> > > Most people are running latest OS & Xcode and it is annoying to not be
> > able
> > > to type "make full" and run. By default I agree this should work. No
> > hoops!
> > >
> > It is not just about that. Most compilers and other packages are
> defaulting
> > to it. Compiling binary python stuff for use with the official blender
> > makes you jump through more hoops then most people can. Not many people
> > have a version of python compiled with msvc 2013 on windows when it is
> > officially deprecated and the official python release is with 2015. A
> > similar argument can be made for almost any package for python that
> > contains native code on MacOS they all use libc++ as that is the default.
> >
> > >
> > > Can we keep the ability to build for 10.6 thru 10.8 using an *older*
> > > Xcode/SDK? I keep a drive with 10.9 & older Xcode, but am not a build
> > > system guru.
> > >
> > Sure. release is not build on a machine that is kept up to date. It is
> > build on OS X 10.9 with code 6.3 and a clang version compiled by Jens.
> >
> > >
> > > For our next release we could have [Mac OS 10.6, 10.7, 10.8] and [Mac
> OS
> > > 10.9 & newer] downloads. That gives us a rough count how many people
> > > actually use the older system.
> >
> > Yes, we can also have windows XP and windows ME, 98 support. it is just a
> > question of adding some extra hands. If we care about user numbers we
> might
> > want to port to android soon.
> >
> >
> > >
> > > Mike Erwin
> > > musician, naturalist, pixel pusher, hacker extraordinaire
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> With best regards, Sergey Sharybin
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal to switch both master and blender2.8 to c++11 be default.

[Sergey Sharybin]

So is it all for the locally-compiled Blender (meaning, both releases and
buildbots stays the same as is)?

Keep in mind, while it might be fine on Windows/OSX you'll have some major
problems on Linux (users will lat least need to re-compile all
dependencies). And sure enough they'll run into weird compilation / linking
errors (shall i here note that the guy who proposes to bump something must
become responsive for the users communication and figuring out their
problems caused by the bump? ;)

Still either i'm missing something, or so far the motivation behind such a
change is because we can do it. What are the benefits for users? What is
the problem you're solving here? Why to rush such a thing?


On Sun, Nov 20, 2016 at 9:44 PM, Martijn Berger 
wrote:

> On Sun, Nov 20, 2016 at 9:00 PM, Mike Erwin 
> wrote:
>
> > On Sun, Nov 20, 2016 at 8:45 AM, Martijn Berger <
> martijn.ber...@gmail.com>
> > wrote:
> > >
> > >
> > > The only mayor downside i see is that we would effectively drop OS X
> 10.8
> > > and earlier.
> > >
> >
> > Eek, dropping 10.6, 10.7 and 10.8 was not on our Blender 2.7x roadmap.
> This
> > would prevent 2.79 from running on lots of Macs that could handle it (GL
> > 2.1 capable GPUs). Those same Macs are stuck with older GPUs so deciding
> to
> > drop them for Blender 2.8 was easier.
> >
> We never roadmapped dropping WIndows XP. That still has more users then
> 10.7 and 10.8 combined judging form our google analytics.
> 10.9 will soon be dropped from the official support roster by Apple.
>
> >
> > Most people are running latest OS & Xcode and it is annoying to not be
> able
> > to type "make full" and run. By default I agree this should work. No
> hoops!
> >
> It is not just about that. Most compilers and other packages are defaulting
> to it. Compiling binary python stuff for use with the official blender
> makes you jump through more hoops then most people can. Not many people
> have a version of python compiled with msvc 2013 on windows when it is
> officially deprecated and the official python release is with 2015. A
> similar argument can be made for almost any package for python that
> contains native code on MacOS they all use libc++ as that is the default.
>
> >
> > Can we keep the ability to build for 10.6 thru 10.8 using an *older*
> > Xcode/SDK? I keep a drive with 10.9 & older Xcode, but am not a build
> > system guru.
> >
> Sure. release is not build on a machine that is kept up to date. It is
> build on OS X 10.9 with code 6.3 and a clang version compiled by Jens.
>
> >
> > For our next release we could have [Mac OS 10.6, 10.7, 10.8] and [Mac OS
> > 10.9 & newer] downloads. That gives us a rough count how many people
> > actually use the older system.
>
> Yes, we can also have windows XP and windows ME, 98 support. it is just a
> question of adding some extra hands. If we care about user numbers we might
> want to port to android soon.
>
>
> >
> > Mike Erwin
> > musician, naturalist, pixel pusher, hacker extraordinaire
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal to switch both master and blender2.8 to c++11 be default.

[Martijn Berger]

On Sun, Nov 20, 2016 at 9:00 PM, Mike Erwin 
wrote:

> On Sun, Nov 20, 2016 at 8:45 AM, Martijn Berger 
> wrote:
> >
> >
> > The only mayor downside i see is that we would effectively drop OS X 10.8
> > and earlier.
> >
>
> Eek, dropping 10.6, 10.7 and 10.8 was not on our Blender 2.7x roadmap. This
> would prevent 2.79 from running on lots of Macs that could handle it (GL
> 2.1 capable GPUs). Those same Macs are stuck with older GPUs so deciding to
> drop them for Blender 2.8 was easier.
>
We never roadmapped dropping WIndows XP. That still has more users then
10.7 and 10.8 combined judging form our google analytics.
10.9 will soon be dropped from the official support roster by Apple.

>
> Most people are running latest OS & Xcode and it is annoying to not be able
> to type "make full" and run. By default I agree this should work. No hoops!
>
It is not just about that. Most compilers and other packages are defaulting
to it. Compiling binary python stuff for use with the official blender
makes you jump through more hoops then most people can. Not many people
have a version of python compiled with msvc 2013 on windows when it is
officially deprecated and the official python release is with 2015. A
similar argument can be made for almost any package for python that
contains native code on MacOS they all use libc++ as that is the default.

>
> Can we keep the ability to build for 10.6 thru 10.8 using an *older*
> Xcode/SDK? I keep a drive with 10.9 & older Xcode, but am not a build
> system guru.
>
Sure. release is not build on a machine that is kept up to date. It is
build on OS X 10.9 with code 6.3 and a clang version compiled by Jens.

>
> For our next release we could have [Mac OS 10.6, 10.7, 10.8] and [Mac OS
> 10.9 & newer] downloads. That gives us a rough count how many people
> actually use the older system.

Yes, we can also have windows XP and windows ME, 98 support. it is just a
question of adding some extra hands. If we care about user numbers we might
want to port to android soon.


>
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal to switch both master and blender2.8 to c++11 be default.

[Mike Erwin]

On Sun, Nov 20, 2016 at 8:45 AM, Martijn Berger 
wrote:
>
>
> The only mayor downside i see is that we would effectively drop OS X 10.8
> and earlier.
>

Eek, dropping 10.6, 10.7 and 10.8 was not on our Blender 2.7x roadmap. This
would prevent 2.79 from running on lots of Macs that could handle it (GL
2.1 capable GPUs). Those same Macs are stuck with older GPUs so deciding to
drop them for Blender 2.8 was easier.

Most people are running latest OS & Xcode and it is annoying to not be able
to type "make full" and run. By default I agree this should work. No hoops!

Can we keep the ability to build for 10.6 thru 10.8 using an *older*
Xcode/SDK? I keep a drive with 10.9 & older Xcode, but am not a build
system guru.

For our next release we could have [Mac OS 10.6, 10.7, 10.8] and [Mac OS
10.9 & newer] downloads. That gives us a rough count how many people
actually use the older system.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal to switch both master and blender2.8 to c++11 be default.

[Jens Verwiebe]

Can tell you from experience: in some cases vs. boost-usage it can even 
be a speed regression ;)

Should be really done carefully.


Jens


Am 20.11.2016 um 20:01 schrieb Sergey Sharybin:
> Hi,
>
> The original discussion came to conclusion that we'll switch to C++11 in
> the 2.8 branch and keep master as is.
>
> What are the user-measurable improvements from such a bump in master?
>
> On Sun, Nov 20, 2016 at 2:45 PM, Martijn Berger
> wrote:
>
>> >Hi everyone,
>> >
>> >We have had a discussion about c++11 for at least 2 years. We have decided
>> >to allow c++11 features in 2.8, and this implies compiling in c++11 mode
>> >with a supporting compiler. This email is not about that.

-- 

Jens Verwiebe
Allerskehre 44 - 22309 Hamburg

Tel.: +49 40 68 78 50
mobile: +49 172 400 49 07
mailto: i...@jensverwiebe.de
web: http://www.jensverwiebe.de

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal to switch both master and blender2.8 to c++11 be default.

[Sergey Sharybin]

Hi,

The original discussion came to conclusion that we'll switch to C++11 in
the 2.8 branch and keep master as is.

What are the user-measurable improvements from such a bump in master?

On Sun, Nov 20, 2016 at 2:45 PM, Martijn Berger 
wrote:

> Hi everyone,
>
> We have had a discussion about c++11 for at least 2 years. We have decided
> to allow c++11 features in 2.8, and this implies compiling in c++11 mode
> with a supporting compiler. This email is not about that.
>
> What i want to propose is to build master ( 2.7x ) in c++11 mode against
> libraries that are in c++11 ABI ( on platforms that make this distinction.
> That does not imply allowing c++11 only features or dropping the
> possibility of being able to compile in c++03 mode.
>
> Why would we want to do that ?
>
> 1) we are already sort of doing it on windows. MSVC does not really allow
> you to disable its c++11 support.
>
> 2) Modern systems are defaulting to it. this should have nothing to do with
> us except that it does. We have users trying to use python extensions with
> blender that we ourselves do not ship. On MacOS the compiler and thus
> things like homebrew compile against libc++ for some time now people who
> try to compile extensions need to jump through a lot of hoops in order for
> things to work.
>
> 3) It fits very well with preparing our build-system and libraries for the
> future / Blender 2.8. We decided to go that way and while i agree we should
> not make 2.7x depend on c++11 i think building it by default as c++11 does
> not contradict that decision.
>
> 4) We could start to use llvm versions greater then 3.4 for release builds
> as those need a c++11 compiler
>
> I would like to move to msvc2015 for Windows and darwin/libc++/c++11 for
> MacOS for 2.7x. and 2.8
>
> The only mayor downside i see is that we would effectively drop OS X 10.8
> and earlier.
>
>
>
> Martijn
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Proposal to switch both master and blender2.8 to c++11 be default.

[Martijn Berger]

Hi everyone,

We have had a discussion about c++11 for at least 2 years. We have decided
to allow c++11 features in 2.8, and this implies compiling in c++11 mode
with a supporting compiler. This email is not about that.

What i want to propose is to build master ( 2.7x ) in c++11 mode against
libraries that are in c++11 ABI ( on platforms that make this distinction.
That does not imply allowing c++11 only features or dropping the
possibility of being able to compile in c++03 mode.

Why would we want to do that ?

1) we are already sort of doing it on windows. MSVC does not really allow
you to disable its c++11 support.

2) Modern systems are defaulting to it. this should have nothing to do with
us except that it does. We have users trying to use python extensions with
blender that we ourselves do not ship. On MacOS the compiler and thus
things like homebrew compile against libc++ for some time now people who
try to compile extensions need to jump through a lot of hoops in order for
things to work.

3) It fits very well with preparing our build-system and libraries for the
future / Blender 2.8. We decided to go that way and while i agree we should
not make 2.7x depend on c++11 i think building it by default as c++11 does
not contradict that decision.

4) We could start to use llvm versions greater then 3.4 for release builds
as those need a c++11 compiler

I would like to move to msvc2015 for Windows and darwin/libc++/c++11 for
MacOS for 2.7x. and 2.8

The only mayor downside i see is that we would effectively drop OS X 10.8
and earlier.



Martijn
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers