[Bf-committers] with_system_glew / gles options on linux.

[Ray Molenkamp]

Not my regular platform, but I tend to help out the odd user with linux 
building errors, and this
one comes up rather frequently

In our cmakelist.txt we have an exception for linux that sets

option(WITH_SYSTEM_GLEW "Use GLEW OpenGL wrapper library provided by the 
operating system" ON)
option(WITH_SYSTEM_GLES "Use OpenGL ES library provided by the operating 
system"   ON)

compared to all other platforms where it is off.

I couldn't find a justification for it, but why are these options (unlike all 
other
WITH_SYSTEM_* options even on linux ) ON by default? Especially glew seems to be
problematic, even more so for blender 2.8 where we can't figure out if it's 
glew 1 or 2
at compile time so there's a runtime check in the final binary that'll prevent 
code
compiled against 1.x from running.

We ship with a known good copy in our source tree, why not use it by default?

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

Re: [Bf-committers] Weekly meetings and communication channels

[Aaron Carlisle]

For a developer forum/general questions Phabricator as a feature called
Ponder https://secure.phabricator.com/ponder/

Aaron Carlisle

Picture taker | Bit cruncher | Pixel pusher | Document writer | Artist
Project administrator for the Blender 3D Documentation Project

On Thu, Aug 31, 2017 at 12:22 AM, Campbell Barton 
wrote:

> On Wed, Aug 30, 2017 at 6:31 PM, Stefan Werner  wrote:
> > Hi,
> >
> > answers are inlined:
> >
> >> On 28. Aug 2017, at 14:27, Ton Roosendaal  wrote:
> >>
> >> Proposal: alternate Monday meetings to be 10:00 and 18:00 Amsterdam
> time. Drop the Sunday meetings.
> >
> > I like the alternating time idea, that should allow people from more
> time zones to participate.
> > Picking a right day is hard though - weekdays are good paid
> contributors, weekends better for volunteers.
> >
> >> 1) Forums: (discourse)
> >> https://internals.rust-lang.org/categories <
> https://internals.rust-lang.org/categories>
> >
> > Some kind of developer focussed forum is helpful, I would think. Right
> now, we’re abusing the bug tracker
> > as forum: https://developer.blender.org/T46258 <
> https://developer.blender.org/T46258>
>
> This looks like proper tracker use to me, focused design tasks for
> planning is fine.
>
> There are a few times I've seen people try and use tracker more like a
> forum for asking questions or submitting a patch which is really a
> question about code. I don't think its much of a problem.
>
> Even so, could be nice to try out a forum for developers.
>
> > Discussions like this don’t work at all on IRC and not very well in
> mailing lists.
> >
> >> 2) Weekly activity log
> >> https://this-week-in-rust.org/ 
> >
> > Helpful, we should do that.
>
> While it would be nice, are people interested to write/manage this?
>
> Maybe best to do a trial-run for ~5 weeks or so, continue if it's working
> out.
>
> >> 4) No mailing lists!
> >> https://mail.mozilla.org/pipermail/rust-dev/2015-January/011558.html
> >>
> >> Now I don't think we need to drop mailing lists, but the forums and
> activity log sound great.
> >> Discourse also might help making our onboarding process better.
> >
> > If we use a web based forum, please let’s pick one that works well on
> mobile devices
> > (including the ones that are not the latest and greatest) and sends
> server-side generated
> > static HTML. Responding to email on a smartphone is quick and easy and
> works even when
> > you have a terrible connection. “Modern” HTML pages sometimes require
> several MB
> > just to display essentially a couple of paragraphs of text.
> >
> > For example, one of the forums I visit sometimes runs on nodeBB. Just
> the forum start page
> > comes in at 1.17MB. That’s ridiculous and I pretty much never read it on
> my phone. BA, even
> > with the features images, is only half as big, simple phpBB sites come
> in at 300kB. Plain text
> > contents of these pages is just a few kB, the rest is mostly decoration
> and oh-so-useful features
> > nobody uses.
> >
> > I know, we need to have fast connections to begin with (wouldn’t want to
> git clone over GPRS)
> > but I like to make my time on the road useful too. From here to BConf is
> roughly 7 hours on a train
> > that promises WIFI but doesn’t always deliver. Don’t want to let that
> time go to waste.
> >
>
> Did you look into https://try.discourse.org ?
>
> > -Stefan
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell
> ___
> 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] CMake version bump for blender2.8

[Campbell Barton]

On Thu, Aug 31, 2017 at 8:56 PM, Dalai Felinto  wrote:
> A small update here, to build cmake is really straightforward. I got
> Blender 2.8 to build in 14.04 with no further complications.
> So if we rule this Ubuntu as an too-old to maintain OS, it's all good,
> and my original email can just be ignored.

Their per-compiled binaries worked well too last I checked.

>> Switching to CMake 3.x would be nice since (...)
>
> Blender 2.8 switched for it already.

Right, I should have said switched *master* - changing lib linking
touches nearly all cmake files, I'd rather not cause unnecessary
conflicts.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] CMake version bump for blender2.8

[Dalai Felinto]

A small update here, to build cmake is really straightforward. I got
Blender 2.8 to build in 14.04 with no further complications.
So if we rule this Ubuntu as an too-old to maintain OS, it's all good,
and my original email can just be ignored.

> Switching to CMake 3.x would be nice since (...)

Blender 2.8 switched for it already.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] CMake version bump for blender2.8

[Campbell Barton]

From memory, rule of thumb for Linux support has been to compile on
latest releases of major (top ~5 so) Linux distors.
Supporting the latest Ubuntu LTS is nice too.

Switching to CMake 3.x would be nice since it allows us to remove the
dreaded "BLENDER_SORTED_LIBS".

On Thu, Aug 31, 2017 at 6:38 PM, Dalai Felinto  wrote:
> Hi,
>
> Ubuntu 14.04 is "stuck" with CMake 2.8. It's a LTS so they won't
> upgrade their CMake. And it's still quite inside our 5 year support
> goal.
> What exactly do we need from CMake 3.x? If we really need CMake 3.0,
> can we at least update install_deps.sh to handle cmake as well?
>
> Regards,
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
>
>
> 2017-08-20 17:02 GMT+02:00 Jörg Müller :
>> Hi everyone,
>>
>> a discussion about our cmake version has started after I merged audaspace
>> into blender2.8. Audaspace requires cmake 3.0 as opposed to blender's main
>> cmake file which so far requires cmake 2.8.
>>
>> Now since a version bump has been in discussion already a year ago according
>> to Campbell, we think this is a good time to actually do it. Last time it
>> was postponed because Debian was not ready. So now I had a look at the
>> current versions of cmake in the major distributions [1]:
>>
>> ubuntu (17.04) - 3.7.2
>> ubuntu LTS (16.04) - 3.5.1
>> debian (stable) - 3.7.2
>> opensuse (42.3) - 3.5.2
>> fedora (F26) - 3.8.2
>> pclinuxos - 3.7.2
>> centos (6) - 2.8.12 (3.6.1 in EPEL)
>> arch - 3.8.2
>> mageia (6) - 3.7.2
>> slackware (14.2) - 3.5.2
>> gentoo - 3.7.2
>>
>> According to this list, pretty much everyone should be able to get at least
>> cmake 3.5 running. Therefore, I bumped the cmake version to 3.5 which allows
>> us to use newer cmake features now.
>>
>> Cheers,
>> Jörg
>>
>> [1] https://pkgs.org/download/cmake
>>
>> ___
>> 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



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

Re: [Bf-committers] CMake version bump for blender2.8

[Bastien Montagne]

Hi,

I don’t see why we'd make install_deps also handle custom installation 
of cmake! This is turning a bit (a lot) ridiculous.


CMake 3.0 is **three** years old alreay! I remember we were switching to 
recent versions of CMake much, much more quickly back in the days of 
CMake 2.8 area, as soon as we needed the update, never has been an issue 
then.


And am pretty sure our 5 years old support is meant for hardware, not 
software - especially not compiling/building software! Because 
otherwise, you'd also might ask our current code to support 5 years old 
libraries… this is going pretty much nowhere. Software changes at least 
twice quicker than hardware.


Further more, this is purely a *building* dependency, not a running one. 
Am starting to be a bit tired of getting stuck to years old tools, or 
having to handle their installation ourself (and maintain stupid script 
for way too much distros). Doing that for libraries is already a pain. 
If you do not have the basic minimal knowledge of compiling, to the 
point you are not even able to install modern building tools on the 
purposedly deprecated OS you are using, then by all means, download our 
builds from the buildbot! Sergey spends a lot of time ensuring those 
binaries work on any distro, even rather old ones. Let’s not spend more 
time trying to pretend building a program can be as easy as installing a 
binary package.


So to summarize: I do not understand the issue here.

Cheers,
Bastien

Le 31/08/2017 à 10:38, Dalai Felinto a écrit :

Hi,

Ubuntu 14.04 is "stuck" with CMake 2.8. It's a LTS so they won't
upgrade their CMake. And it's still quite inside our 5 year support
goal.
What exactly do we need from CMake 3.x? If we really need CMake 3.0,
can we at least update install_deps.sh to handle cmake as well?

Regards,
Dalai
--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com


2017-08-20 17:02 GMT+02:00 Jörg Müller :

Hi everyone,

a discussion about our cmake version has started after I merged audaspace
into blender2.8. Audaspace requires cmake 3.0 as opposed to blender's main
cmake file which so far requires cmake 2.8.

Now since a version bump has been in discussion already a year ago according
to Campbell, we think this is a good time to actually do it. Last time it
was postponed because Debian was not ready. So now I had a look at the
current versions of cmake in the major distributions [1]:

ubuntu (17.04) - 3.7.2
ubuntu LTS (16.04) - 3.5.1
debian (stable) - 3.7.2
opensuse (42.3) - 3.5.2
fedora (F26) - 3.8.2
pclinuxos - 3.7.2
centos (6) - 2.8.12 (3.6.1 in EPEL)
arch - 3.8.2
mageia (6) - 3.7.2
slackware (14.2) - 3.5.2
gentoo - 3.7.2

According to this list, pretty much everyone should be able to get at least
cmake 3.5 running. Therefore, I bumped the cmake version to 3.5 which allows
us to use newer cmake features now.

Cheers,
Jörg

[1] https://pkgs.org/download/cmake

___
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


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

Re: [Bf-committers] CMake version bump for blender2.8

[Dalai Felinto]

Hi,

Ubuntu 14.04 is "stuck" with CMake 2.8. It's a LTS so they won't
upgrade their CMake. And it's still quite inside our 5 year support
goal.
What exactly do we need from CMake 3.x? If we really need CMake 3.0,
can we at least update install_deps.sh to handle cmake as well?

Regards,
Dalai
--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com


2017-08-20 17:02 GMT+02:00 Jörg Müller :
> Hi everyone,
>
> a discussion about our cmake version has started after I merged audaspace
> into blender2.8. Audaspace requires cmake 3.0 as opposed to blender's main
> cmake file which so far requires cmake 2.8.
>
> Now since a version bump has been in discussion already a year ago according
> to Campbell, we think this is a good time to actually do it. Last time it
> was postponed because Debian was not ready. So now I had a look at the
> current versions of cmake in the major distributions [1]:
>
> ubuntu (17.04) - 3.7.2
> ubuntu LTS (16.04) - 3.5.1
> debian (stable) - 3.7.2
> opensuse (42.3) - 3.5.2
> fedora (F26) - 3.8.2
> pclinuxos - 3.7.2
> centos (6) - 2.8.12 (3.6.1 in EPEL)
> arch - 3.8.2
> mageia (6) - 3.7.2
> slackware (14.2) - 3.5.2
> gentoo - 3.7.2
>
> According to this list, pretty much everyone should be able to get at least
> cmake 3.5 running. Therefore, I bumped the cmake version to 3.5 which allows
> us to use newer cmake features now.
>
> Cheers,
> Jörg
>
> [1] https://pkgs.org/download/cmake
>
> ___
> 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] Failing addons/module load tests

[Campbell Barton]

Here's a proposal on how this can be handled:

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