[Bf-committers] CMake cleanup

[Ray Molenkamp via Bf-committers]

All,

As some of you have possibly noticed, I have been making some
changes/cleanups to our build system, some new and foreign
concepts to some may have shown up.

I was planning to send an update about this once the work
was completed, but several community members have reached
with various levels of confusion and/or venom, so I’ll
just go ahead and send an update now.

As it is quite a read and may cause some Q you can find
the full text on devtalk over at:

https://devtalk.blender.org/t/cmake-cleanup/30260

If you have questions/comments/suggestions, please reach
out on devtalk, or if you'd rather not reach out publicly
feel free to reach to me out on blender.chat

Greetings,
Ray
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Handling of user data.

[Ray Molenkamp via Bf-committers]

Ton,

It's been nearly a year and we're seemingly still hurting people [1] you're a 
clever one!
you only said it deserved priority, not that it would actually get priority, i 
fell for that one!

I don't see this realistically happening for 3.6, but please I beg you, make it 
a prio for 4.0
this really has got to stop.

Greetings,
Ray

[1] 
https://www.reddit.com/r/blender/comments/12f8nh9/omg_spent_hours_texture_painting_and_its_gone_any/

On 2022-05-13 7:09 a.m., Ton Roosendaal via Bf-committers wrote:
> Hi Ray,
>
>> deleting the users data without their consent
>> isn't OK, has never been OK, will never be OK,
>
> Fully agree with that.
>
> The list of critical issues is way too long. But this deserves top priority 
> for fixing.
>
> -Ton-
>
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, CEO Blender Institute / Studio
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> On 12/05/2022 22:17, Ray Molenkamp via Bf-committers wrote:
>> I don't think there's any disagreement between me and bastien
>> we both agree it's a problem that just isn't getting the
>> attention it deserves. The disagreement is with the people who
>> set the priorities.
>>
>> Most of the priories are seemingly set by the needs of the
>> blender studio, they have learned a long long time ago, how
>> to "not lose data" to the point it has seemingly become a
>> out of sight out of heart style problem.
>>
>> My somewhat cheeky prod on the mailing list was meant as
>> a reminder, deleting the users data without their consent
>> isn't OK, has never been OK, will never be OK, and we should
>> be fixing it rather than waving it away going "it's fiiine,
>> work on this instead" it's very much not "fine"
>>
>> --Ray
>>
>>
>>
>> On 2022-05-10 2:12 p.m., Zack Brown via Bf-committers wrote:
>>> Hi,
>>>
>>> I'm also curious about this issue. It seems like Ray is giving one side of
>>> the argument, but I'm not clear on the other side. This can't simply be a
>>> debate between one group that is in favor of destroying user data, and
>>> another group that opposes it.
>>>
>>> Looking at the developer task, it seems like one concern is that any
>>> solution to the problem would need to take account of workflow issues, so
>>> that production workflows won't be slowed down. I'd like to hear an example
>>> of a production workflow that relies on blender's current behavior, and how
>>> it might be slowed down if the data were simply not deleted instead.
>>>
>>> There definitely seems to be something to what Ray says, about saving users
>>> from a data-loss baptism of fire. And there also seems to be something to
>>> what Bastien says, about various big projects that currently have a higher
>>> priority than fixing a standard blender behavior that has always been this
>>> way. I know there are a lot of features I eagerly look forward to, more
>>> than fixes for some of the known misfeatures. But I also know that I got
>>> bit by the inexplicable data-loss issue myself at first, and it was a pain
>>> in the butt.
>>>
>>> Could someone take a stab at explaining what this debate really is about,
>>> in such a way that both sides would feel fairly represented? All I know
>>> right now is that there's a disagreement about something that currently
>>> feels over my head.
>>>
>>> Be well,
>>> Zack
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 10, 2022 at 9:05 PM Ray Molenkamp via Bf-committers <
>>> bf-committers@blender.org> wrote:
>>>
>>>> That task is over 3 years old though, it mostly reconfirms
>>>> the notion that the people who set the priorities just
>>>> don't see silently destroying end user data being a problem.
>>>>
>>>> I hope this short thread serves as a wake-up call and this
>>>> and the other core improvements you mentioned will be made
>>>> more of a priority and time will actually be allocated for
>>>> it in the next release cycle.
>>>>
>>>> But I'm not getting my hopes up here.
>>>>
>>>> --Ray
>>>> On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote:
>>>>> Hi Ray,
>>>>>
>>>>> We already have a task to address this issue:
>>>>>
>>>>>

Re: [Bf-committers] Bump MacOS minimum requirements to 10.15 for Blender 3.5

[Ray Molenkamp via Bf-committers]

I have to admit, I don't have a whole lot of experience with macs,
I have honestly no idea of the real-world impact of a version
bump. However, given we committed to follow the VFX platform for
2023/2024 which targets 11.0 for 2023 shouldn't we either :

a) Follow the VFX platform and Target 11.0

b) Have some rationale documented somewhere why we are deviating
from the VFX platform by targeting 10.13 or 10.15.

Following the VFX platform for just the things we liked (ie we follow
it!. but not for the python version) hasn't worked out overly well for us
in the past, and I’d rather not repeat that phase of our commitment
to the VFX platform, so my naive grasp of the situation has me leaning
towards option a.

--Ray



On 2023-01-05 8:26 a.m., Brecht Van Lommel via Bf-committers wrote:
> I think it's reasonable to do the bump now, instead of 3 months from now
> when we definitely have to do it. And doing it together with the VFX
> platform updates and new Linux minimum requirements makes some sense.
>
> It's always unfortunate to leave behind hardware, but even macOS 10.15 is
> already EOL and no longer receiving updates.
>
> On Thu, Jan 5, 2023 at 4:10 PM Jeroen Bakker via Bf-committers <
> bf-committers@blender.org> wrote:
>
>> Hello all,
>>
>> A few weeks ago we enabled the Metal back-end for the viewport. By default
>> Blender will start using OpenGL, but in the User preferences the Metal
>> backend can be enabled. The first responses and test are very positive and
>> currently it is very likely that Metal will be released as a secondary
>> backend in Blender 3.5.
>>
>> Currently Master is only able to build on MacOS 10.15 and above due this
>> change. The current minimum requirement is MacOS 10.13.
>>
>> So there are some options to consider here.
>> * Do we release blender 3.5 with Metal Backend?
>> * Do we bump the minimum version from 10.13 to 10.15 for Blender 3.5?
>> * Add logic in many places to make sure that 10.15 code-paths aren't used
>> when run in 10.13?
>>
>> Sergey mentioned that there are already ideas to bump the version to 10.15
>> for Blender 3.6. So this proposal is to do this one release earlier.
>>
>> My proposal would be to do the version bump for Blender 3.5 due to these
>> reasons.
>> Would like to have some feedback if this is acceptable.
>>
>> Jeroen.
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> List details, subscription details or unsubscribe:
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] move prebuilt libs from svn to git?

[Ray Molenkamp via Bf-committers]

Except for you just now i don't think anyone is
questioning the need for version control on the
3rd party dependencies. This tree was there long
before i joined the blender project so can't give
any insights on any controversy in creating it.

However whenever this subject (why svn) comes up,
it tends to be one or both of these scenario's

1) svn is giving people a hard time, calling it
"quirky" would be generous,  it doesn't recover
nicely whenever it runs into trouble, and with
the large size of the libraries and the slow
download speeds for some people it's just bound
to run into trouble. And these people rightfully
question "Why is it like this?"

2) SVN is old, everything uses git these days
it's the hip and trendy new kid on the block.
they never have these kinds of issues with git!
why is blender being so silly, just use git!

on the other hand, no-one is using pure git to manage
a large collection of binaries since it is just not
designed for this job, in much the same way the
hand basket at your local hardware store is not
designed to pick up that 25kg bag of cement.

git-lfs is one of the proposed solutions, but
also not free of problems [1] (written by the
maintainer of an different version control
system, be aware of "some" bias there)

Yet another alternative is to go, 3rd party
dependencies are no concern of us, developers
can go obtain/build these on their own. This is
the stance taken by the majority of opensource
projects. And I'll admit, as one of the people
responsible for the contents of this repository
I can't help feeling some envy there, maintaining
the libs and guaranteeing a smooth experience for
developers is *VERY* time consuming. However seeing
new people join the blender project going "building
blender was much easier than I expected, I finished
my small first patch fixing something that had been
bothering me in under a day" negates those feelings
and makes me realize as a project the blender project
is better for everyone by having these libs available.

SVN is what we have and it's mostly working for us
there's alternatives but there's a lot more nuance
to it than "just use X I never have problems with X"

[1] https://gregoryszorc.com/blog/2021/05/12/why-you-shouldn%27t-use-git-lfs/
 

On 2022-06-18 11:24 a.m., Zack Brown wrote:
> Thanks, I appreciate the explanation. It still seems weird. I'm sure the 
> original conversation that led to this particular svn tree must have involved 
> some amount of controversy.
>
> But at this point in the project's history there's definitely something to be 
> said for "if it ain't broke, don't fix it." Especially with so many amazing 
> blender features in rapid development.
>
> Be well,
> Zack
>
>
> On Sat, Jun 18, 2022 at 6:45 PM Ray Molenkamp  wrote:
>
> libraries change over time, sometimes they have large api changes
> where we have to do reintegration work into blender.
>
> Which then leads to, if we have a single folder with libs, what
> do the 2 concurrent LTS releases use? that same lib folder? they
> need major rework to use them, we can't land rework in an lts release
> brand new bugs will likely come with it.  option b: well we'll give
> every release their own folder on that shared drive so they won't have
> issues when the libs change.
>
> wait a minute... we've just reinvented version control :)
>
> --Ray
>
> On 2022-06-18 1:04 a.m., Zack Brown wrote:
>> Hi everyone,
>>
>> It's fascinating to see this discussion. It never occurred to me that 
>> anyone might continue to prefer svn once git came into existence, and yet 
>> here is a sample case, right under my nose! I guess svn is still relevant 
>> even after all these years!
>>
>> But actually I'd be curious to know why revision control is used at all 
>> in this particular case. We're talking about precompiled binaries, right? 
>> That's sort of the poster child for situations where revision control is 
>> *not* what one wants, exactly for the reason why git would be a bad choice.
>>
>> Please, could someone explain why the blender project doesn't simply use 
>> a dev-accessible shared folder somewhere? I love revision control, but it's 
>> only useful if it's useful.
>>
>> Be well,
>> Zack
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] move prebuilt libs from svn to git?

[Ray Molenkamp via Bf-committers]

Just an update with some new numbers, dan's changes
brought down the time for a full clone from my home
connection down to 5m48s (down from 27m39s previously)

well done dan!

--Ray

On 2022-06-17 3:45 p.m., Dan McGrath wrote:
> Just a heads-up that Ray and I took a packet capture on both ends for me.
>
> Thanks to his capture, I noticed that the SVN server host was not sending TCP 
> window scale or SACK options. Ultimately this turned out to be due to that 
> host using the PF firewall "synproxy" state option, which apparently was 
> causing the TCP header options to be removed, which limited the window size 
> to 64k.
>
> I have corrected this change to match the www host, and we did observe some 
> improvements that were hidden from me before due to my and the studio IPs 
> special treatment that bypassed this feature.
>
> While it should help, I also tuned a few sysctl settings for send and receive 
> buffers. In addition, I noticed that the SVN server is also not sending 
> gzip/deflate accept headers for the files. No doubt this is going to be a 
> factor. However, there was a note from 2016 from myself explaining that 
> Brecht asked for the SVN compression to be disabled due to some client 
> problems. So, this will require some research, perhaps next week.
>
> Anyway, hopefully it helps a bit until I can review some more settings.
>
> Enjoy your weekend everyone!
>
>
> Dan
>
> On Fri, Jun 17, 2022, 2:22 PM Ray Molenkamp via Bf-committers 
>  wrote:
>
> =8<==[Editors note]=8<==
> I'll be honest I'm 100% convinced mailinator will ruin
> the little formatting I have done, I put a copy of this
> email on https://developer.blender.org/P3014.
> =8<8<8<8<==
>
> How much as I like the sentiment of "lets move to git will it
> solve all these problems" lets be honest here, git.blender.org 
> <http://git.blender.org>'s
> speed is nothing to write home about either it may or may not be
> as glitchy as svn, but it still wouldn't be fast.
>
> from my 300mbit connection in western Canada
>
> Receiving objects:   6% (135931/2078159), 33.34 MiB | 458.00 KiB/s
>
> total time for a clone off git.blender.org <http://git.blender.org> 27m39s
>
> Cloning off https://github.com/blender/blender.git however
>
> total time for a clone off github.com <http://github.com> 1m 52s
>
> Now amount of finger pointing to client settings will convince me
> it's a client setting at this point, but I'll be honest, I am all
> the way in western Canada and that could definitely be a factor.
>
> so, lets investigate!
>
> Let’s spin up an AWS EC2 instance in London, I'd say that be close
> enough to Amsterdam, and let’s rule out any other CPU or Bandwidth
> related factors as well, I threw a few dollars at it and got a
> cn5.18xlarge instance (72 CPU’s 192gb memory, 100gbit ethernet)
> overkill to do a git/svn test? yes.. yes indeed
>
> first to rule out the blender.org <http://blender.org> servers lets grab 
> a ubuntu iso
> off an .nl mirror ( 
> https://mirror.nl.datapacket.com/ubuntu-releases/22.04/ )
>
> 2022-06-17 17:13:21 (232 MB/s) - ‘ubuntu-22.04-desktop-amd64.iso’ saved 
> [3654957056/3654957056]
>
> all right bandwidth is NOT going to be an issue on this box!
>
> On to blender stuff:
>
> cloning from git.blender.org <http://git.blender.org>  2m32.895s
> svn checkout of lib/win64_vc15 2m56.388s (iftop said 65Mbit peak rate)
>
> yowza!
>
> All right, so in London, safe to say all is well
>
> lets move closer to my location, us-east-2 Ohio (same instance type and 
> os)
>
> grabbing ubuntu from that same mirror
>
> 2022-06-17 17:31:00 (29.5 MB/s) - ‘ubuntu-22.04-desktop-amd64.iso’ saved 
> [3654957056/3654957056]
>
> all right, that has lost quite a bit of steam, but it's
> still nothing to sneeze at, just to be sure lets grab
> an iso off the Princeton university mirror 120MB/s ok..
> good enough...
>
> onto cloning blender
>
> Receiving objects:   5% (104235/2078173), 25.44 MiB | 692.00 KiB/s
>
> well... that's not looking promising... lets wait it out
>
> cloning from git.blender.org <http://git.blender.org>  17m23.449s
>
> sadface... lets try svn next, i lost patience and did not let
> it finish.. iftop reported a top RX of 5.59Mbit though..
>
> To summarize:
>
> Ubuntu iso from mirror.nl.datapacket.com 
> <http://mirror.nl.datapacket.com> (Speed taken from wget)
> My home - western Canada - 1.3  MB/s
> 

Re: [Bf-committers] move prebuilt libs from svn to git?

[Ray Molenkamp via Bf-committers]

=8<==[Editors note]=8<==
I'll be honest I'm 100% convinced mailinator will ruin
the little formatting I have done, I put a copy of this
email on https://developer.blender.org/P3014.
=8<8<8<8<==

How much as I like the sentiment of "lets move to git will it
solve all these problems" lets be honest here, git.blender.org's
speed is nothing to write home about either it may or may not be
as glitchy as svn, but it still wouldn't be fast.

from my 300mbit connection in western Canada

Receiving objects:   6% (135931/2078159), 33.34 MiB | 458.00 KiB/s

total time for a clone off git.blender.org 27m39s

Cloning off https://github.com/blender/blender.git however

total time for a clone off github.com 1m 52s

Now amount of finger pointing to client settings will convince me
it's a client setting at this point, but I'll be honest, I am all
the way in western Canada and that could definitely be a factor.

so, lets investigate!

Let’s spin up an AWS EC2 instance in London, I'd say that be close
enough to Amsterdam, and let’s rule out any other CPU or Bandwidth
related factors as well, I threw a few dollars at it and got a
cn5.18xlarge instance (72 CPU’s 192gb memory, 100gbit ethernet)
overkill to do a git/svn test? yes.. yes indeed

first to rule out the blender.org servers lets grab a ubuntu iso
off an .nl mirror ( https://mirror.nl.datapacket.com/ubuntu-releases/22.04/ )

2022-06-17 17:13:21 (232 MB/s) - ‘ubuntu-22.04-desktop-amd64.iso’ saved 
[3654957056/3654957056]

all right bandwidth is NOT going to be an issue on this box!

On to blender stuff:

cloning from git.blender.org  2m32.895s
svn checkout of lib/win64_vc15 2m56.388s (iftop said 65Mbit peak rate)

yowza!

All right, so in London, safe to say all is well

lets move closer to my location, us-east-2 Ohio (same instance type and os)

grabbing ubuntu from that same mirror

2022-06-17 17:31:00 (29.5 MB/s) - ‘ubuntu-22.04-desktop-amd64.iso’ saved 
[3654957056/3654957056]

all right, that has lost quite a bit of steam, but it's
still nothing to sneeze at, just to be sure lets grab
an iso off the Princeton university mirror 120MB/s ok..
good enough...

onto cloning blender

Receiving objects:   5% (104235/2078173), 25.44 MiB | 692.00 KiB/s

well... that's not looking promising... lets wait it out

cloning from git.blender.org  17m23.449s

sadface... lets try svn next, i lost patience and did not let
it finish.. iftop reported a top RX of 5.59Mbit though..

To summarize:

Ubuntu iso from mirror.nl.datapacket.com (Speed taken from wget)
My home - western Canada - 1.3  MB/s
AWS - London - 232  MB/S
AWS - Ohio   - 29.5 MB/s

Clone of git.blender.org (time taken from linux time command)
My home - western Canada - 27m39
AWS - London -  2m32
AWS - Ohio   - 17m23

SVN Clone: (peak RX bitrate taken from iftop)
My home - western Canada -  1.5 Mbit/s
AWS - London -   64 Mbit/s
AWS - Ohio   - 5.59 Mbit/s

Think the only thing we really can conclude is
that being further from the server is leading
to an "unhappy" time for the developer. Given
the fact the EC2 instances were 100% identical
between London and Ohio, it's unlikely to be a
client configuration issue.

--Ray

On 2022-06-17 10:10 a.m., Dan McGrath via Bf-committers wrote:
> Hi,
>
> Really, I would need to see a capture from both sides to dig into it. I
> need to see what is being sent, and what is received on each side. There
> could be some weird firewall stuff happening that is causing fragmentation
> or blocking TCP options, or window scaling issues, etc.
>
> As for the default settings for tortoisesvn, the connection stuff I was
> referring to was about TCP/IP behaviour, rather than an application
> setting. Either way, I need to see what is actually happening. The fact
> that I can pull 5-8MB/sec (~40mbit) from Canada and not have a single
> interruption is telling. Granted, the host only has around 100 or 200mbit
> allocated, iirc. Multiply that by a few dozen people and you have a problem.
>
> For a simpler test, maybe try a large svn check, perhaps some old FreeBSD
> ports svn repo if you can find one, something also in .NL, and see how it
> goes, just to help eliminate your PC/firewall. Worst case scenario, you can
> also poke me in chat and we can try some server side and client side
> captures.
>
> TBH though, 1gig uplink just isn't a whole lot to serve our user base ;)
>
> On Fri, Jun 17, 2022 at 11:45 AM Tom M  wrote:
>
>> On Fri, Jun 17, 2022 at 5:20 AM Dan McGrath 
>> wrote:
>>> Hi Tom,
>>>
>>> Long time no see :)
>>>
>>> I did some tests from home and found that, aside from slow speeds, I was
>> able to checkout at least 5 or 6 gig of the bf-blender repo without error
>> or having to retransmit.
>>
>> Yeah, looks like I was mistaking really slow download of the larger
>> (.7 GB) libraries as freezing.  I was averaging about .3 MB/s.  I used
>> a different SVN client and saw that it was indeed downloading (the
>> 

Re: [Bf-committers] Handling of user data.

[Ray Molenkamp via Bf-committers]

The core team has bought blender to where it is today,
they seem to have a pretty good handle on things.

I'm not sure design by committee on bf-c is what
this problem was lacking.

Just give 'm time, guys, they got this.

--Ray

On 2022-05-17 6:19 p.m., Harley Acheson via Bf-committers wrote:
>> The Idea being to put all of the unlinked stuff into some trash can of
> sorts...
>
> That is what we would have if we would simply just save everything, with
> your "trash can"
> just being the items that have zero users. Then you can choose, at any
> time, to remove
> those items.
>
> These two approaches to data - only save things that are in use except for
> items the user
> has explicitly marked, versus saving all user data and allowing them to
> delete what they
> want - are not symmetrical.  The former creates an emergency at the point
> of exit that we
> will not be able to fix with warnings.  The latter removes that emergency
> and allows the user
> to deal with it at leisure.
>
> I have heard the argument that "OMG, this will make our files bloat".  But
> you can turn such
> a "bloated file" into one without saved orphans with the currently existing
> "purge orphans"
> operator. You can run this all the time, make it an option to run on save,
> or never run it. But
> it leaves this to you to deal with when you want, not done *for *you.
>
> With the thought of (slowly) moving toward saving orphan data, the
> following experimental
> patch replaces the current File / Clean Up menu of items with a single
> "Clean Up" dialog
> that can be used remove orphans, set all orphans to fake user, or to bring
> up a window
> with Outliner set to "Orphan Data" mode so you can manage them granularly.
>
> https://developer.blender.org/D14030
>
> Harley
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Handling of user data.

[Ray Molenkamp via Bf-committers]

I don't think there's any disagreement between me and bastien
we both agree it's a problem that just isn't getting the
attention it deserves. The disagreement is with the people who
set the priorities.

Most of the priories are seemingly set by the needs of the
blender studio, they have learned a long long time ago, how
to "not lose data" to the point it has seemingly become a
out of sight out of heart style problem.

My somewhat cheeky prod on the mailing list was meant as
a reminder, deleting the users data without their consent
isn't OK, has never been OK, will never be OK, and we should
be fixing it rather than waving it away going "it's fiiine,
work on this instead" it's very much not "fine"  

--Ray



On 2022-05-10 2:12 p.m., Zack Brown via Bf-committers wrote:
> Hi,
>
> I'm also curious about this issue. It seems like Ray is giving one side of
> the argument, but I'm not clear on the other side. This can't simply be a
> debate between one group that is in favor of destroying user data, and
> another group that opposes it.
>
> Looking at the developer task, it seems like one concern is that any
> solution to the problem would need to take account of workflow issues, so
> that production workflows won't be slowed down. I'd like to hear an example
> of a production workflow that relies on blender's current behavior, and how
> it might be slowed down if the data were simply not deleted instead.
>
> There definitely seems to be something to what Ray says, about saving users
> from a data-loss baptism of fire. And there also seems to be something to
> what Bastien says, about various big projects that currently have a higher
> priority than fixing a standard blender behavior that has always been this
> way. I know there are a lot of features I eagerly look forward to, more
> than fixes for some of the known misfeatures. But I also know that I got
> bit by the inexplicable data-loss issue myself at first, and it was a pain
> in the butt.
>
> Could someone take a stab at explaining what this debate really is about,
> in such a way that both sides would feel fairly represented? All I know
> right now is that there's a disagreement about something that currently
> feels over my head.
>
> Be well,
> Zack
>
>
>
>
>
> On Tue, May 10, 2022 at 9:05 PM Ray Molenkamp via Bf-committers <
> bf-committers@blender.org> wrote:
>
>> That task is over 3 years old though, it mostly reconfirms
>> the notion that the people who set the priorities just
>> don't see silently destroying end user data being a problem.
>>
>> I hope this short thread serves as a wake-up call and this
>> and the other core improvements you mentioned will be made
>> more of a priority and time will actually be allocated for
>> it in the next release cycle.
>>
>> But I'm not getting my hopes up here.
>>
>> --Ray
>> On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote:
>>> Hi Ray,
>>>
>>> We already have a task to address this issue:
>>>
>>> https://developer.blender.org/T61209
>>>
>>> But this needs time to be properly handled, and these days we spend
>> everything besides regular maintenance on 'big projects', so... this one
>> and several other relatively small core improvements and fixes keep being
>> delayed from one release to the other.
>>> -- Bastien
>>>
>>> On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote:
>>>> All,
>>>>
>>>> It's been years [1] (2018) since I last was rather
>>>> vocal on this subject, but how is this [2] still
>>>> happening? "Yes, blender deleted your data (and silently
>>>> at that), that means it's working correctly!" cannot
>>>> possibly be the best we can do, is it?
>>>>
>>>> While I'm excited with all the directions blender
>>>> development is currently going, it's utterly depressing that
>>>> users are still losing data on a daily basis because
>>>> we can't quite get the basics right like "do not delete the
>>>> users data without their consent".
>>>>
>>>> These are *NOT* isolated incidents [3]. Losing your
>>>> data and learning about "the fake user" shouldn't be
>>>> a right of passage to become "a real blender user".
>>>> Users shouldn't be silently *losing* data in an operation
>>>> ironically called *saving*. That's crazy, no other
>>>> application behaves like this!
>>>>
>>>> Yes, I know this is how we have always done it. No,
>>>> this is not OK, n

Re: [Bf-committers] Handling of user data.

[Ray Molenkamp via Bf-committers]

That task is over 3 years old though, it mostly reconfirms
the notion that the people who set the priorities just
don't see silently destroying end user data being a problem.

I hope this short thread serves as a wake-up call and this
and the other core improvements you mentioned will be made
more of a priority and time will actually be allocated for
it in the next release cycle.

But I'm not getting my hopes up here.

--Ray
On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote:
> Hi Ray,
>
> We already have a task to address this issue:
>
> https://developer.blender.org/T61209
>
> But this needs time to be properly handled, and these days we spend 
> everything besides regular maintenance on 'big projects', so... this one and 
> several other relatively small core improvements and fixes keep being delayed 
> from one release to the other.
>
> -- Bastien
>
> On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote:
>> All,
>>
>> It's been years [1] (2018) since I last was rather
>> vocal on this subject, but how is this [2] still
>> happening? "Yes, blender deleted your data (and silently
>> at that), that means it's working correctly!" cannot
>> possibly be the best we can do, is it?
>>
>> While I'm excited with all the directions blender
>> development is currently going, it's utterly depressing that
>> users are still losing data on a daily basis because
>> we can't quite get the basics right like "do not delete the
>> users data without their consent".
>>
>> These are *NOT* isolated incidents [3]. Losing your
>> data and learning about "the fake user" shouldn't be
>> a right of passage to become "a real blender user".
>> Users shouldn't be silently *losing* data in an operation
>> ironically called *saving*. That's crazy, no other
>> application behaves like this!
>>
>> Yes, I know this is how we have always done it. No,
>> this is not OK, never was.
>>   Ton: Please make protecting the user’s data a
>> priority, as it doesn’t seem this will happen otherwise.
>>
>> --Ray
>>
>>
>> [1] https://devtalk.blender.org/t/oh-no/505/2
>> [2] https://developer.blender.org/T97968
>> [3] https://devtalk.blender.org/t/more/22715
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> List details, subscription details or unsubscribe:
>> https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Handling of user data.

[Ray Molenkamp via Bf-committers]

All,

It's been years [1] (2018) since I last was rather
vocal on this subject, but how is this [2] still
happening? "Yes, blender deleted your data (and silently
at that), that means it's working correctly!" cannot
possibly be the best we can do, is it?

While I'm excited with all the directions blender
development is currently going, it's utterly depressing that
users are still losing data on a daily basis because
we can't quite get the basics right like "do not delete the
users data without their consent".

These are *NOT* isolated incidents [3]. Losing your
data and learning about "the fake user" shouldn't be
a right of passage to become "a real blender user".
Users shouldn't be silently *losing* data in an operation
ironically called *saving*. That's crazy, no other
application behaves like this!

Yes, I know this is how we have always done it. No,
this is not OK, never was.
 
Ton: Please make protecting the user’s data a
priority, as it doesn’t seem this will happen otherwise.

--Ray


[1] https://devtalk.blender.org/t/oh-no/505/2
[2] https://developer.blender.org/T97968
[3] https://devtalk.blender.org/t/more/22715

___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Retiring MSVC 2017 Support

[Ray Molenkamp via Bf-committers]

All, After years of loyal service we will be retiring support for MSVC 2017, 
making the new requirement at least MSVC 2019 16.9.16. The build scripts and 
wiki will be updated in the coming days to remove VS2017 support. If you have 
updated your VS 2019 installation in the last year you will likely have no 
issues, otherwise it is best to do so before these changes land. Any version of 
VS2022 will also work. Greetings, Ray
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support

[Ray Molenkamp via Bf-committers]

I don't think any of the major vendors (nor us) will build openvdb
with a wonky blosc version that will give compatibility issues, point
is neither the danger of using a "wrong" blosc version nor any other
mention of file compatibility is in the platform (but it is in the
openvdb documentation) So my argument was about not referring to
the platform as an authority on file compatibility, since they aren't.
The choice to follow the platform or not is a completely separate
choice.

I'm desperately trying to get us to a point where rather than an
uncommitted, "we follow some things, not others, kinda depends on our
mood, and if we like to make a random exception or not, also here are
some arbitrary commitments to things that platform doesn't even seem to
do" to a crystal clear:

-These are the things we do
-These are the things we don't

I'd rather give users like you solid hard disappointment you can
count on, than comforting false hope that will disappoint. Guaranteed
platform adherence would have been acceptable as well, but that does
not appear to be the direction we are appear to be leaning.

My objective is to minimize/eliminate the "gray zone" blender has
been in for the last few years regarding the platform, VFX Platform in or
out, I'm cool either way, but we have to pick a team and communicate it
clearly to our users.

--Ray

On 2022-01-20 12:40 p.m., Scott Wilson wrote:
> I'm sort of out of the loop, but has there been communications with the VFX 
> Reference Platform recently? I think that some of the issues brought up such 
> as build flags for OpenVDB could be resolved. I know that as a pipeline TD in 
> a studio, having all of the vendors on the same page about all attributes of 
> the build environment makes my life much easier. So, I throw what little say 
> I have into getting Blender and the platform aligned.
>
> On Thu, Jan 20, 2022, 11:22 AM Ray Molenkamp via Bf-committers 
>  wrote:
>
> While I do not mind the practical nuts and bolts of this
> proposal at all, I do mind the language, referring to the
> VFX Platform as something worth looking at regarding file
> or platform compatibility is unfortunate.
>
> The Platform as is makes no attempt to manage file compatibility
> throughout the pipeline, the big-ticket items in this space such
> as USD and/or MaterialX aren't even in the platform, the things
> that are in the platform, such as OpenVDB that have _severe_
> file compat issues if build incorrectly do not even have a footnote
> about it. The only logical conclusion here is, the VFX Platform
> is a not authority to appeal to regarding file compatibility, so
> best not to.
>
> As for platform compatibility, the messaging in the VFX Platform
> is confusing, for linux it declares a glibc version, for macOS it
> declares a deployment target, so far so good, but then for windows
> it does none of these things, and just recommends a compiler and SDK of
> which neither determine the OS versions the resulting code can
> run on, the inclusion of python 3.9 indirectly implies windows 8.1
> is their minimum windows deployment target, but honestly I'm unsure
> if even they are aware of this implication.
>
> I'd like to see the proposal move more into concrete direction:
>
> > Blender does NOT follow the VFX platform.
> >
> > - Blender aims be compatible with operating systems VFX Platform 
> compatible software will be able run on.
> > - blender aims not to break file compatibility for 3rd party formats 
> such as EXR, VDB, Alembic: files exported from Blender should be usable in 
> other software used in the pipeline, and vice-versa.
>
> The last item
>
> > - Not to break external render engines
>
> Is just not something I think we can we can practically commit to,
> these are generally linked directly to the python shared libs,
> and bumping python versions will definitely break most if not all
> of them.
>
> To put an end to having to have this conversation every year, I'd
> like to break the loop with the following text:
>
> > Major blender releases will ship with the latest major python version 
> available during BCON1 in its development.
>
> My proposal
>
> - Clarifies our stance on the VFX Platform
> - Doesn't appeal to an authority the VFX Platform clearly lacks regarding 
> file compat.
> - Somewhat commits to running on the same platforms as the VFX platform 
> (as much as it can be deduced from the platform, they are vague about it, 
> hard to make any solid commitments here).
> - Makes the python version blender will ship with predictable.
>
> Note that personally, I may or

Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support

[Ray Molenkamp via Bf-committers]

While I do not mind the practical nuts and bolts of this
proposal at all, I do mind the language, referring to the
VFX Platform as something worth looking at regarding file
or platform compatibility is unfortunate.

The Platform as is makes no attempt to manage file compatibility
throughout the pipeline, the big-ticket items in this space such
as USD and/or MaterialX aren't even in the platform, the things
that are in the platform, such as OpenVDB that have _severe_
file compat issues if build incorrectly do not even have a footnote
about it. The only logical conclusion here is, the VFX Platform
is a not authority to appeal to regarding file compatibility, so
best not to.

As for platform compatibility, the messaging in the VFX Platform
is confusing, for linux it declares a glibc version, for macOS it
declares a deployment target, so far so good, but then for windows
it does none of these things, and just recommends a compiler and SDK of
which neither determine the OS versions the resulting code can
run on, the inclusion of python 3.9 indirectly implies windows 8.1
is their minimum windows deployment target, but honestly I'm unsure
if even they are aware of this implication.

I'd like to see the proposal move more into concrete direction:

> Blender does NOT follow the VFX platform.
>
> - Blender aims be compatible with operating systems VFX Platform compatible 
> software will be able run on.
> - blender aims not to break file compatibility for 3rd party formats such as 
> EXR, VDB, Alembic: files exported from Blender should be usable in other 
> software used in the pipeline, and vice-versa.

The last item

> - Not to break external render engines

Is just not something I think we can we can practically commit to,
these are generally linked directly to the python shared libs,
and bumping python versions will definitely break most if not all
of them.

To put an end to having to have this conversation every year, I'd
like to break the loop with the following text:

> Major blender releases will ship with the latest major python version 
> available during BCON1 in its development.

My proposal

- Clarifies our stance on the VFX Platform
- Doesn't appeal to an authority the VFX Platform clearly lacks regarding file 
compat.
- Somewhat commits to running on the same platforms as the VFX platform (as 
much as it can be deduced from the platform, they are vague about it, hard to 
make any solid commitments here).
- Makes the python version blender will ship with predictable.

Note that personally, I may or may not approve of the direction being
taken here, but judging from your internal discussions this seems to be
the way we want to go as a project, in which case clear language is
undoubtedly better than vague commitments that sound nice but may
set unrealistic expectations.

--Ray
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support

[Ray Molenkamp via Bf-committers]

The reason that is, most of the people involved are in the
discussion are not in a position to make this decision
(and that includes me) We can have good arguments on either
side of following or not following, but none of us can
decide.

This is something that will have to be decided at the top.
It's essentially between Ton and the project admins, decide
what what the position is of the blender project, VFX Platform
are we in or are we out?

The stance we had for the last few years, "We're in, this
year, since it kinda aligns, next year? maybe not? there's
exceptions... if we feel like it.." isn't working, the
sooner we realize that the better.

If we again do not take a solid stance, I guarantee you
we will have the same song and dance in between 6 and 12
months from now.

I'm not overly interested in deciding on the
python upgrade right now (even though that personally
puts me in a rough spot with bcon3 this close) I'd
rather see this through and have HQ sort it out once
and for all.

--Ray

On 2022-01-19 8:34 p.m., Campbell Barton via Bf-committers wrote:
> This discussion seems to suffer the same fate as other VFX platform
> threads...  fizzle out with no conclusion.
>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support

[Ray Molenkamp via Bf-committers]

You may feel like you're alone in this, however you may
have an ally in me, and I may even go further than you.

If you read my previous emails in this thread carefully
you'll notice I have personally made no call regarding
the python version, I Don't feel it's my place to make
that call, I'm not on the python team, nor am I a project
admin, and as platform dev, building python 3.9.10 or
3.10.2, I'll be honest it's all the same to me.

I did make the case that if we don't follow python, there's
no point to follow any other recommendations, no-one is going
to care about our TBB or OpenVDB versions if we're out of
line on python, so let’s not make any commitments that benefit
no-one.

However, *IF* we decide to follow it for python, I'd say
we follow the whole thing, actually we ought to go even
further than what we did previously,and ship the python
bindings for components that support it, ship most libraries
shared rather than static (at-least on windows, unsure how
much of a pain-point this is on the *nix based platforms),
and make sure QT/Pyside integrate nicely, perhaps even go
as far as shipping QT. Since once you clear the python
version hurdle, that be the next most common issues that
these sorts of pipeline tools will run into.

You could say I'm an either all in, or all out kind of guy,
picking the bits that we like of the VFX Platform that happen
to align, and have that change between years, isn't a
position I think we should be in, since it's effectively an
"all out" position, with more (Rightfully so) complaining users
due to ambiguity on whether we are in or out for any given
blender release.

--Ray

On 2022-01-17 8:39 a.m., Brecht Van Lommel via Bf-committers wrote:
> For reference there is more discussion about this in the two tasks:
> 2021: https://developer.blender.org/T83246
> 2020: https://developer.blender.org/T68774
>
> My preference is still to track the full VFX platform, including the Python
> version. However I know I'm in the minority on this, and I'm not expecting
> that to change.
>
> I don't think it's practical to support multiple Python versions. For
> add-ons and particularly those with binaries, supporting both Python
> versions would be more work. Likely many of the add-ons would just not be
> tested and not work with the older Python version.
>
> I think other libraries do matter. We still wanted to switch to OpenColorIO
> 2 around the same time as other apps for example, regardless if file
> compatibility is a goal of the VFX platform. It should be a goal for us.
> Further some of these libraries have Python APIs that we'd like to expose,
> like pyopenvdb.
>
> In my opinion we should stick to the VFX platform by default and make
> exceptions as needed. We don't need to retread the Python discussion every
> year, the situation is still the same and it's reasonable to assume we
> continue being incompatible there. For other libraries, if it's not causing
> incompatibility I don't even see that as deviating from the VFX platform.
> If it does lead to incompatibility, I think we should take that into
> consideration.
>
> On Mon, Jan 17, 2022, 15:16 Ray Molenkamp via Bf-committers <
> bf-committers@blender.org> wrote:
>
>>> I don't really feel great about Python
>>> being the only exception allowed to be digressed
>>> from the platform.
>> I think you're misunderstanding the VFX Platform goals,
>> it has nothing to do with asset compatibility throughout
>> the pipeline. Otherwise, it would specify what formats
>> would have to be supported in OIIO, or what version
>> of blosc should be used for OpenVDB since using the
>> "wrong" blosc version will cause files to be unreadable
>> by older versions. It does none of these things.
>>
>> No, what it sets out to do is define a tightly controlled binary
>> runtime environment, if I link my binary addon to the library
>> versions in the platform, I will be able to load it into the host
>> applications that follow the platform without issues.
>>
>> If we break on python, none of the other things in the platform
>> matter, With the only notable exception being the glibc version
>> I suppose.
>>
>> Any commitments we may make to the platform while simultaneously
>> breaking on python are pointless, so no, that case I make is not
>> "Only python is/should be the exception", the case is, "If we
>> break on python there's no need to commit to anything else, so
>> best not to make any commitments."
>>
>> --Ray
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> List details, subscription details or unsubscribe:
>> https://lists.blender.or

Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support

[Ray Molenkamp via Bf-committers]

> I don't really feel great about Python
> being the only exception allowed to be digressed
> from the platform.

I think you're misunderstanding the VFX Platform goals,
it has nothing to do with asset compatibility throughout
the pipeline. Otherwise, it would specify what formats
would have to be supported in OIIO, or what version
of blosc should be used for OpenVDB since using the
"wrong" blosc version will cause files to be unreadable
by older versions. It does none of these things.

No, what it sets out to do is define a tightly controlled binary
runtime environment, if I link my binary addon to the library
versions in the platform, I will be able to load it into the host
applications that follow the platform without issues.

If we break on python, none of the other things in the platform
matter, With the only notable exception being the glibc version
I suppose.

Any commitments we may make to the platform while simultaneously
breaking on python are pointless, so no, that case I make is not
"Only python is/should be the exception", the case is, "If we
break on python there's no need to commit to anything else, so
best not to make any commitments."

--Ray

___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support

[Ray Molenkamp via Bf-committers]

All right, looks like we're tiptoeing around
the elephant in the room, time to rip that
Band-Aid off (feels like this metaphor kinda
got away from me, but I'm sticking with it!)

Let’s not beat around the bush, no-one has
ever complained about our OIIO, Boost, VDB or
TBB versions. People get ..passionate..
about python, anytime someone brings up the
VFX Platform it's python, It's never anything
else, it's python, the rest of the VFX platform
may as well not exist. The issue is, and will
always be python.

The real question is, are we going to follow
the platform in regards to python or not.

The way the python [1] and VFX Platforms [2]
are released those most we'll ever have is a
5-month window where the two will overlap and
there will actually be active bug fix support
on python the python version of the VFX Platform.
Are we OK with that?

People get upse..uhh passionate when we "suddenly"
change our python version. What is needed is a
clear and decisive message regarding how we pick
our python versions.

Are we following:

A) The python release schedule
B) The VFX platform schedule
C) Well, you know maybe, VFX kind of works out
this year so why not, next year maybe not so
much, we'll see, oh hey this years python has ….
[check notes]..better….. error.. messages? we got
to upgrade!
D) Other

We have been doing C, and I don't think anyone
is super thrilled about how this is working out.

I mostly don’t even care what we pick (not C!!)
pick something, write it down somewhere, so people
can rely on it.

--Ray

[1] https://www.python.org/dev/peps/pep-0602/
[2] https://vfxplatform.com/about/

___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Let's Encrypt SSL certificates incident on the blender.org servers

[Ray Molenkamp via Bf-committers]

For people having ssl issues with arcanist, the easiest solution is

1) grab the latest cacert.pem from https://curl.se/docs/caextract.html
2) copy it to [arcanist_installation_folder]/resources/ssl/custom.pem

Pay attention to the slightly different filename it *NEEDS* to be
custom.pem the original filename cacert.pem will not work.

This should do the trick on all platforms (but it's only been tested
on Linux and Windows).

--Ray
On 2021-09-30 1:06 p.m., Sergey Sharybin via Bf-committers wrote:
> Hi,
>
> Just a quick memo about the issue of expired Let's Encrypt certificates. It
> might be useful for developers who experience issues with HTTPS connection
> to our servers.
>
> One of the root Let's Encrypt certificates did expire today which affected
> parts of our development infrastructure. In all cases it doesn't seem to be
> an issue with the server configuration but is caused by quirks on the
> client side. We are only aware of issues on Windows.
>
> The Subversion clients did not trust the SSL certificate of
> https://svn.blender.org/. The work-around we did for the builder.blender.org
> was to install the Let’s Encrypt R3 intermediate certificate [1]. This
> "worked (tm)", although ideally intermediate certificates shouldn't need to
> be installed and the system should go by the root CA certificates from the
> Windows Certificates Store.
>
> The Arcanist uses the CURL extension of PHP, and it does not use the
> Windows Certificates Store. The way it was fixed on the buildbot workers
> was by creating a cacert.pem with the "ISRG Root X1" certificate which was
> exported from the Store (and matched the one from Let's Encrypt information
> page [1]).
>
> Our server administrator Danny McGrath also took the liberty of disabling
> TLSv1.0 and TLSv1.1 on some of the sites during tests. Provided that this
> doesn't make matters worse, the changes are likely to be kept.
>
> [1] https://letsencrypt.org/certificates/
>
> Best regards,
> - Your Engineering Team Danny and Sergey -
> 
> Sergey Sharybin - ser...@blender.org - www.blender.org
> Principal Software Engineer, Blender
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] JSON/YAML parsing in CPP

[Ray Molenkamp via Bf-committers]

My official position is : The platform module is
not in the business of making library recommendations,
or deciding what library does or doesn't go into blender.

As long as the admins are willing to sign off on it,
we'll build any library you want, with whatever options
you require. When the render module goes "hey we need
the vulkan SDK" it's really not our place to go "lol
no! Go write a DX12 or Metal back-end instead". A module
has a need and it's the platform modules job to
support that need to ensure their success.

Once a decision to gain an additional dependency has been
made, we'll go out of our way to ensure a smooth landing
in the blender Eco-system, no need to concern your self
with platforms, compiler flags, linkers or build systems,
we got this! Once we're done the module should just be able
to #include "libfoo.h" and be on their way.

In short, the platform module is essentially a service
module to empower the other modules to do their work
with the least amount of distractions from the platform
side of things. However your needs are your needs, building
libfoo vs building libbar it's honestly all the same to us.
 
So with that said and hopefully clarified that my personal
opinion on this subject should hold no more value than
any other blender contributor.

"I need a Yaml, or Json library" from the tone of
your email you don't really seem to care what format
one or another, would you accept XML? we already have
and ship pugixml, opinions may be divided here but I'd
rate XML human readable. We could bump it from optional
to required with virtually no work.

T91430 seems to hint that you'd like a C++ API, if that's
the case nlohmann's library [1] is by far the most pleasant
library I've used. rapidjon or simdjson (read-only) may have
the performance edge, but there's something to be said for good looking
maintainable code especially if we're not going to end up parsing
gigabytes of json.

Whatever you decide on doing, I understand time is of
the essence, and I will make myself available to make
whatever option you chose available to you as quickly
as possible.

--Ray

[1] https://github.com/nlohmann/json

On 2021-09-15 3:22 a.m., Jeroen Bakker via Bf-committers wrote:
> Hi All,
>
> For the asset browser we would like to store an index per asset file
> (.blend file inside an asset library) to reduce the overhead of showing
> assets in the asset browser.
>
> The high level solution we are thinking of is to store an index file next
> to the asset file that can be read quickly to find out what assets are
> inside the file. The challenge I want to address is the used data format of
> that file. We prefer these supporting files to be human readable, but the
> structure can be complex. From this point of view we are looking for
> YAML/JSON.
>
> Currently we don't have a YAML/JSON parsing library in our core. As we want
> to add indexing still as part of Blender 3.0 we might have a timing issue.
>
> In https://developer.blender.org/T91430 2 valid options are desribed.
> - use a header only JSON parser.
> - use cpp-yaml that is already used by OCIO/OIIO and make it a hard
> dependency.
>
> T91430 also mentions an abstration to switch implementations if needed.
>
> We would like to have discussion/feedback from the platform maintainers to
> see what would be a valid option for inclusion of asset indexing in Blender
> 3.0.
>
> Jeroen
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Nightly builds on Steam and Snap stores

[Ray Molenkamp via Bf-committers]

Is the developer wiki is the ideal place to
communicate with end-users?

There's no denying these are pretty good looking
docs with plenty of screenshots, the top of the
page is clearly aimed at developers and will
just scare off most end users that do manage to
find it. (end users are unlikely to visit the
dev wiki)

Even if they do find it, and make it past the first page
there's following progression:

- Pipeline talk - end-user: Eek!
- Downloading from the website! - end-user: Yay
- Scary looking 10 line regex - end-user: Eek!
- Using steam! - end-user: Yay

This page just seems to have no idea who its
audience is and it makes for a somewhat
incoherent experience for all parties involved.

--Ray

On 2021-07-16 9:40 a.m., James Monteath via Bf-committers wrote:
> Hi all,
>
> Nightly builds are now available on Steam (BETA) test branches and Snap
> channels.
>
> **Steam**
> The automated delivery of *2.93 / 2.83 LTS - Candidates*
> and *3.0 - Alpha* builds are now accessible via Steam (BETA) Test branches.
> Blender nightly builds are available for all supported platforms on Steam.
>
> Using Steam Test Branches:
> https://wiki.blender.org/wiki/Infrastructure/BuildBot#Using_Steam_Test_Branches
>
> **Snap**
> For Linux systems with Snap support, *2.93 / 2.83 LTS - Candidates*
> and *3.0 - Alpha *builds can be refreshed using channels.
>
> Using Snap Test Channels:
> https://wiki.blender.org/wiki/Infrastructure/BuildBot#Using_Snap_Test_Channels
>
> Cheers !
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developer week notes - 2021.07.12

[Ray Molenkamp via Bf-committers]

Dalai,

Think some small clarification is in order here
Jesse is a very capable and diverse developer [1]

Now he did have a few patches in my module (as he did
in many others), and while I will happily commit
contributors patches, there is a point where you go
"wait? why am I still committing patches for this dev?
He's a capable dev, submitted many patches, and has
been around for quite a bit now, he ought to be
trusted to commit his own work!"

So while I did lobby to get him commit rights, this was
in no way, shape, or form an attempt to "claim" Jesse for
my own module.

He's doing great work all over the place, best not to
constrain wonderful developers like that.

If you go, every dev needs a home module, I would happily
give him one in the platform module, but afaik that's
not how we currently operate.

--Ray

[1] https://developer.blender.org/people/revisions/126877/

On 2021-07-13 1:47 a.m., Dalai Felinto via Bf-committers wrote:
> Hi all,
>
> Here are the compiled notes for this week's development. For the complete
> report with modules and projects updates, links and images read it on:
> https://devtalk.blender.org/t/12-july-2021/19521
>
> Welcomes
> 
> * Jesse Yurkovich (deadpin) joins the "Platforms, Builds, Tests & Devices"
> module.
>
> Announcements
> =
> * Google Summer of Code 1st evaluation deadline is Friday 16/July 20:00
> CEST.
> * New performance testing framework [1] in master.
> ** Used for Cycles now, but developers are encouraged to use it for testing
> and tracking performance of more Blender features.
>
> Geometry Nodes
> =
>  * Nodes workshop June 2021 write up [2]
>
> [1] - https://wiki.blender.org/wiki/Tools/Tests/Performance
> [2] - https://code.blender.org/2021/07/nodes-workshop-june-2021/
>
> -Dalai-
> 
> Dalai Felinto - da...@blender.org - www.blender.org
> Blender Development Coordinator
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Buildbot Update - June 14, 2021

[Ray Molenkamp via Bf-committers]

May I suggest moving the change log to the bottom of
the page (or even better its own page) ?

While I absolutely love having the change log, having
users/devs scroll though it before they can learn
how to use the build infra structure seems less than
ideal, given the change log is not going to get any
shorter over time they may even bail out thinking
they are on the wrong page.

--Ray

On 2021-06-14 10:17 a.m., James Monteath via Bf-committers wrote:
> Hi all,
>
> Buildbot has been updated.
> https://builder.blender.org/admin/#/builders
>
> Notable changes on the Wiki.
> https://wiki.blender.org/wiki/Infrastructure/BuildBot#Notable_Changes
>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Simple steps to get an harmonious collaboration

[Ray Molenkamp via Bf-committers]

I'm somewhat confused on the goal some of the (proposed?) rules.
But I'll just pick on the "Patch description should match the
commit message."-rule for now not to make this longer than it
needs to be. 

Most people are much more verbose in their patch description,
some have visual aids (images/clips), benchmark results, and
perhaps test files attached to them. Rich content is possible
and often used.

While commit messages are a much more somber endeavor, no rich
content and strict requirements on the formatting (50 chars
for the first line ie)

The guidance we offer for what should be in a patch [1]
and what should be in a commit message [2] also paint two
rather different pictures.

Personally, I welcome justifications in a diff on al the ways the
problem could have been solved, but were ultimately not chosen for
reason X, Y or  Z. While in commit messages I honestly only care for
"what does it do, how does it do it" when I'm bisecting I have
no interest whatsoever in learning about all the ways a certain
commit doesn't solve the issue.

Patch descriptions and commit messages just seem fundamentally
different things, and I struggle a bit on seeing why unifying
the two would be a "good thing"

I have similar concerns with many of the other rules on this list,
most seem perfectly fine rules on first sight, but without a clear
justification on how they contribute to.. [check notes] .. "harmonious
collaboration in the code review platform", its just a list of
seemingly oddball rules, I could add a "keyboard layout must be
set to dvorak while typing patch description" rule and it wouldn't
even look out of place.

--Ray

[1] 
https://wiki.blender.org/wiki/Process/Contributing_Code#Ingredients_of_a_Patch
[2] https://wiki.blender.org/wiki/Style_Guide/Commit_Messages


On 2021-06-01 5:05 a.m., Sergey Sharybin via Bf-committers wrote:
> Hi,
>
> Just a quick note. The bf-admin team worked on several process related
> documents to ensure a pleasant and efficient development process.
>
> Today we've updated wiki with the patch review process:
> https://wiki.blender.org/wiki/Process/Patch_Review
>
> Feedback is welcome.
>
> Best regards,
> - Sergey -
> 
> Sergey Sharybin - ser...@blender.org - www.blender.org
> Principal Software Engineer, Blender
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> ___
> 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] VFX reference platform 2022 draft

[Ray Molenkamp via Bf-committers]

imho 3.9 is the only version they could have picked, the
proposed release date for 3.10 is 2021-10-04 [1]. While
the VFX platform aims to finalize in august [2]. I was
rather vocal last year for them putting versions on that
had not been released yet (some of which got delayed well
into 2021) I'm happy to see for 2022 a more conservative
stance has been taken.

With bugfix support for 3.9 ending on 2022-05-02 [3] that
does put them in an odd situation, they'll either have
to recommend a version that may not be released on time,
or recommend a version that will not see bug fixes for most
of the year. There seemingly is no winning solution here
since the problem appears to be the somewhat short
support window for python releases.

As much as I picked on them last year for making very
strange recommendations, I feel they struck a good balance
for 2022.

--Ray

[1] https://www.python.org/dev/peps/pep-0619/
[2] https://vfxplatform.com/about/
[3] https://www.python.org/dev/peps/pep-0596/

On 2021-05-18 2:47 a.m., Sybren A. Stüvel via Bf-committers wrote:
> Hello,
>
> On Mon, 17 May 2021 at 19:54, Brecht Van Lommel via Bf-committers <
> bf-committers@blender.org> wrote:
>
>> There is a draft for the next VFX reference platform up now. Since we had
>> some issues with the last one, it would be good to give feedback if
>> necessary.
>>
> Good call.
>
>
>> Python was upgraded to 3.9, which will still trail behind 3.10 that will be
>> released this year. So the question about diverging or not will remain.
>>
> My preference would be to, for non-LTS releases at least, stick to versions
> of Python that still receive bugfixes. In the past we've had crashes of
> Blender that were due to a bug in Python. The only way to solve that was to
> upgrade Python itself. This in itself is rare, but I don't remember having
> such issues at all until we stuck to the old py3.7 to adhere to the VFX
> Platform.
>
> Is there anything known about the policy of the VFX Platform when it comes
> to picking which Python version to stick to? Is it always going to be
> "whatever version was released a year earlier"? Or is there still an
> acceleration happening after sticking to py2.7 so long, and will they
> eventually be targeting the latest versions? If it's the latter I'd be fine
> with following the VFX Platform and sticking to py3.9 for a while longer.
> If sticking to the platform means that for a significant amount of time
> we'll be on versions of Python that don't receive bugfixes any more, I'm
> less positive.
>
> Sybren
> ___
> 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] C -> C++ Conversions / Failing build

[Ray Molenkamp via Bf-committers]

All,

More and more code is getting converted to C++
and honestly couldn't be happier about that.

What I'm less thrilled about is the way this is
being done, devs work with GCC, don't test on
windows, violate the standard (use of designated
initializers in c++ breaks the build every...single
..time...) and skip code review all together and just
commit the work.

then build bots start failing, and if you're lucky
the dev is still around to fix issues, if not someone
else will have to janitor behind them.

This is not how things are supposed to go, we run
into the same issues over and over and over, enough
is enough, go trough review!

Things I am unhappy about is this [1] commit specifically

- Converted a bunch of code from C->C++ in master since he was doing "an 
experiment"
- Did no go through review
- Did not clean up the use of designated initializers (C++20 feature)
- Did not test on other platforms/compilers
- Did not check if work that "usually" breaks the build, broke the bots
- I was forced to spend a couple of hours on an issue that should not have
been an issue if the review process was used, time i did not have really

Hans Goudey kindly fixed the initalizers, but sadly there was more
trouble hiding in this commit, the core issue is the 
`WM_msg_subscribe_rna_anon_prop`
macro called in `info_header_region_message_subscribe` has this little nugget

    _WM_MESSAGE_EXTERN_BEGIN; \
    extern PropertyRNA rna_##type_##_##prop_; \
    _WM_MESSAGE_EXTERN_END; \

given it's C++ a decorated symbol was generated, which naturally can't be
found at link time. And before you go just `extern "C"` it, that is only
allowed at global scope, it appears, this macro is in its current form
is just not compatible with C++.

What I'd like to see in the future

- USE THE REVIEW PROCESS, C->C++ conversions have issues... every... single.. 
time...

What I'm going to do

I prodded the dev in chat before starting this email, if i have gotten no 
response
by the time I hit send , I will revert this commit, we can't have master 
failing for this long.

[1] https://developer.blender.org/rB9cce18a5858cb93da626f5f0fd7e09cd66637e05


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

[Bf-committers] ASAN now supported on windows

[Ray Molenkamp via Bf-committers]

All,

Normally I don't do notify bf-c on platform changes I do
but this one seemed note worthy.

I landed ASAN support (D7794) for windows a few
minutes ago, it requires the latest VS update (16.9)
but beyond that it functions the same way as it does
on Linux,  just toggle `WITH_COMPILER_ASAN` ON in cmake,
rebuild and you should be good to go.

If anyone has issues using it, feel free to come bug me

Greetings,
Ray


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

Re: [Bf-committers] 2.93 modules roadmap confirmation 15/Mar 11 CET

[Ray Molenkamp via Bf-committers]

It felt somewhat strange to me for the modules
to present their targets 2 days before the bcon1
deadline, I mean at this point all work should
be done/in already, seems a little late to determine
their feasibility.

Perhaps it's better to do add a similar style
meeting earlier in the process to solidify the
targets and perhaps make any priority
changes?

Greetings,
Ray

On 2021-03-15 8:27 a.m., Dalai Felinto via Bf-committers wrote:
> Hi,
>
> These are the modules targets / meeting notes:
> https://devtalk.blender.org/t/2021-03-15-blender-2-93-targets/17902
>
> Thanks everyone for joining. The meeting was long (2 hours + some time to
> wrap up VFX later). But I think it was useful, with a lot of participation
> and to the point. If anyone has any feedback on how we can do these release
> meetings in the future let me know.
>
> Best regards,
> -Dalai-
> 
> Dalai Felinto - da...@blender.org - www.blender.org
> Blender Development Coordinator
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> Op ma 8 mrt. 2021 om 21:35 schreef Dalai Felinto :
>
>> Hi,
>>
>> I would like to propose a meeting on blender.chat next Monday (15/Mar) at
>> 11:00 CET for the modules to present their 2.93 targets.
>>
>> The modules can prepare a list of the planned new features, and their
>> current state ahead of time. I created a placeholder to help with that.
>> During the meeting I will move this to hackmd so we can edit it at the same
>> time.
>>
>> https://devtalk.blender.org/t/2021-03-15-blender-2-93-targets/17902
>>
>> At the meeting we then go over them in order and confirm the targets and
>> their feasibility.
>>
>> Let me know what you think of this idea,
>> -Dalai-
>> 
>> Dalai Felinto - da...@blender.org - www.blender.org
>> Blender Development Coordinator
>> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>>
> ___
> 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] Blender developer week notes - 2021.02.15

[Ray Molenkamp via Bf-committers]

>* 2.93 bcon2 on 17 February.

This is listed on developer.blender.org as march 17 
on both the front page [1] and the 2.93 schedule [2]

Did this change, or is it a typo?

--Ray


[1] https://developer.blender.org/
[2] https://developer.blender.org/project/view/125/

On 2021-02-15 11:19 a.m., Dalai Felinto via Bf-committers wrote:

> Hi all,
>
> Here are the compiled notes for this week's development. For the complete
> report with modules and projects updates, links and images read it on:
>
> https://devtalk.blender.org/t/15-february-2021/17475
>
> Announcements
> =
> * Google Summer of Code Ideas page is still mostly with old ideas, deadline
> is February 19th (Friday).
> * Bulidbots will be on maintenance 16 February, Tuesday.
> * 2.92 bcon4 on 17 February.
>   - We will go back to using release_candidate tags.
>   - High frequency tablet input will be removed since it introduced many
> problems for old drivers, but will come back in 2.93.
> * 2.93 bcon2 on 17 February.
> * Python 3.9 support has landed for 2.93 alpha.
>   - This has ended Blender support for Windows 7 and 8.
>   - The new minimum requirement is Windows 8.1.
>
> Have a great week everyone,
> -Dalai-
> 
> Dalai Felinto - da...@blender.org - www.blender.org
> Blender Development Coordinator
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> ___
> 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] No Monday or Tuesday meetings for the time being

[Ray Molenkamp via Bf-committers]

Apologies, my weakness for "snappy" responses got the better
of me rather than taking a deep breath and discussing the
issue at hand.

The decision has been unilaterally made, which is your
prerogative, however when questioned why this decision
was made I do not think "why don't you explain why not?"
is a satisfying answer.

The Monday meetings have been a stable of blender development
for as long as i have been involved with blender, having them
canceled without even a mention it was being considered is
strange and some explanation how this came out of nowhere
would be appreciated

--Ray



On 2021-02-09 9:14 a.m., Ray Molenkamp via Bf-committers wrote:
> i hear the Tuesday meetings are a joy
>
> --Ray
>
> On 2021-02-09 8:59 a.m., Dalai Felinto wrote:
>> Hi Ray,
>>
>> Which reasons do you see to keep the meeting(s)?
>>
>> Thanks,
>> Dalai
>>
>> Op ma 8 feb. 2021 om 17:46 schreef Ray Molenkamp via Bf-committers 
>> mailto:bf-committers@blender.org>>:
>>
>> That seems somewhat strange and out of the blue (at least for me), the 
>> lack of reasoning for putting them on hold especially for the Tuesday ones 
>> you seem fond of is concerning, what am i missing here?
>>
>> --Ray
>>
>> On 2021-02-08 9:33 a.m., Dalai Felinto via Bf-committers wrote:
>> > Hi,
>> > The Monday (developers) and the Tuesday (modules) meetings are 
>> currently on
>> > hold. The Monday one has very little quorum and is rarely useful.
>> >
>> > The Tuesday talks (module meetings) are quite a joy actually and I will
>> > miss talking to the modules owners 1:1. But they have always being more
>> > like a  healthy check then a permanent solution. What we need instead 
>> is to
>> > make sure the modules are properly structured and can operate 
>> autonomously.
>> > But this is a separate topic.
>> >
>> > I have a new idea on how to do the weekly communication of the ongoing
>> > module and projects:
>> >
>> > * We keep the weekly online page in devtalk for the weekly notes [1].
>> > * Developers keep adding their weekly reports there.
>> > * Everyone adds relevant announcements there
>> > * [new] Modules and projects then add their notes there as well,
>> > asynchronously.
>> > * [new] At the end of Mondays I do a final pass in the page and post it
>> > here.
>> >
>> > [1] - https://devtalk.blender.org/t/15-february-2021-upcoming/17475 
>> <https://devtalk.blender.org/t/15-february-2021-upcoming/17475>.
>> >
>> > Any feedback is welcome.
>> >
>> > Best regards,
>> > -Dalai-
>> > 
>> > Dalai Felinto - da...@blender.org <mailto:da...@blender.org> - 
>> www.blender.org <http://www.blender.org>
>> > Blender Development Coordinator
>> > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>> > ___
>> > Bf-committers mailing list
>> > Bf-committers@blender.org <mailto:Bf-committers@blender.org>
>> > https://lists.blender.org/mailman/listinfo/bf-committers 
>> <https://lists.blender.org/mailman/listinfo/bf-committers>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org <mailto:Bf-committers@blender.org>
>> https://lists.blender.org/mailman/listinfo/bf-committers 
>> <https://lists.blender.org/mailman/listinfo/bf-committers>
>>
>>
>>
>> -- 
>>
>> -Dalai-
>> 
>> Dalai Felinto - da...@blender.org <mailto:da...@blender.org> - 
>> www.blender.org <http://www.blender.org>
>> Blender Development Coordinator
>> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> ___
> 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] No Monday or Tuesday meetings for the time being

[Ray Molenkamp via Bf-committers]

i hear the Tuesday meetings are a joy

--Ray

On 2021-02-09 8:59 a.m., Dalai Felinto wrote:
> Hi Ray,
>
> Which reasons do you see to keep the meeting(s)?
>
> Thanks,
> Dalai
>
> Op ma 8 feb. 2021 om 17:46 schreef Ray Molenkamp via Bf-committers 
> mailto:bf-committers@blender.org>>:
>
> That seems somewhat strange and out of the blue (at least for me), the 
> lack of reasoning for putting them on hold especially for the Tuesday ones 
> you seem fond of is concerning, what am i missing here?
>
> --Ray
>
> On 2021-02-08 9:33 a.m., Dalai Felinto via Bf-committers wrote:
> > Hi,
> > The Monday (developers) and the Tuesday (modules) meetings are 
> currently on
> > hold. The Monday one has very little quorum and is rarely useful.
> >
> > The Tuesday talks (module meetings) are quite a joy actually and I will
> > miss talking to the modules owners 1:1. But they have always being more
> > like a  healthy check then a permanent solution. What we need instead 
> is to
> > make sure the modules are properly structured and can operate 
> autonomously.
> > But this is a separate topic.
> >
> > I have a new idea on how to do the weekly communication of the ongoing
> > module and projects:
> >
> > * We keep the weekly online page in devtalk for the weekly notes [1].
> > * Developers keep adding their weekly reports there.
> > * Everyone adds relevant announcements there
> > * [new] Modules and projects then add their notes there as well,
> > asynchronously.
> > * [new] At the end of Mondays I do a final pass in the page and post it
> > here.
> >
> > [1] - https://devtalk.blender.org/t/15-february-2021-upcoming/17475 
> <https://devtalk.blender.org/t/15-february-2021-upcoming/17475>.
> >
> > Any feedback is welcome.
> >
> > Best regards,
> > -Dalai-
> > 
> > Dalai Felinto - da...@blender.org <mailto:da...@blender.org> - 
> www.blender.org <http://www.blender.org>
> > Blender Development Coordinator
> > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org <mailto:Bf-committers@blender.org>
> > https://lists.blender.org/mailman/listinfo/bf-committers 
> <https://lists.blender.org/mailman/listinfo/bf-committers>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org <mailto:Bf-committers@blender.org>
> https://lists.blender.org/mailman/listinfo/bf-committers 
> <https://lists.blender.org/mailman/listinfo/bf-committers>
>
>
>
> -- 
>
> -Dalai-
> 
> Dalai Felinto - da...@blender.org <mailto:da...@blender.org> - 
> www.blender.org <http://www.blender.org>
> Blender Development Coordinator
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] No Monday or Tuesday meetings for the time being

[Ray Molenkamp via Bf-committers]

That seems somewhat strange and out of the blue (at least for me), the lack of 
reasoning for putting them on hold especially for the Tuesday ones you seem 
fond of is concerning, what am i missing here?

--Ray

On 2021-02-08 9:33 a.m., Dalai Felinto via Bf-committers wrote:
> Hi,
> The Monday (developers) and the Tuesday (modules) meetings are currently on
> hold. The Monday one has very little quorum and is rarely useful.
>
> The Tuesday talks (module meetings) are quite a joy actually and I will
> miss talking to the modules owners 1:1. But they have always being more
> like a  healthy check then a permanent solution. What we need instead is to
> make sure the modules are properly structured and can operate autonomously.
> But this is a separate topic.
>
> I have a new idea on how to do the weekly communication of the ongoing
> module and projects:
>
> * We keep the weekly online page in devtalk for the weekly notes [1].
> * Developers keep adding their weekly reports there.
> * Everyone adds relevant announcements there
> * [new] Modules and projects then add their notes there as well,
> asynchronously.
> * [new] At the end of Mondays I do a final pass in the page and post it
> here.
>
> [1] - https://devtalk.blender.org/t/15-february-2021-upcoming/17475.
>
> Any feedback is welcome.
>
> Best regards,
> -Dalai-
> 
> Dalai Felinto - da...@blender.org - www.blender.org
> Blender Development Coordinator
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> ___
> 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] .git-blame-ignore-revs entries.

[Ray Molenkamp via Bf-committers]

I'd prefer if we excluded small commits completely, but willing to
settle on clarifying that the "smaller" commits still ought to be
the result of automated tools, If there is no clear indication a
cleanup was automated the commit should not be added. ie a commit
"Cleanup: clang-tidy some-check" could still very much be a manual
cleanup of the warns exposed by clang-tidy and suspect to unintentional
functional changes.
 
--Ray

On 2020-12-28 5:01 p.m., Brecht Van Lommel via Bf-committers wrote:
> Hi Ankit,
>
> Please go through code review for all commits, unless you are a module
> owner or admin that is the policy.
>
> Note that there are guidelines in the file itself. We could document it in
> the wiki too, but I'm not sure it's needed. Perhaps the wording can be
> clarified? Suggestions are welcome. The text is as follows:
>
> # Changes that belong here:
> # - Massive comment, doxy-sections, or spelling corrections.
> # - Clang-format, PEP8 or other automated changes which are *strictly* "no
> functional change".
> # - Several smaller commits should be added to this list at once, because
> adding
> #   one extra commit (to edit this file) after every small cleanup is noisy.
>
> Note that only massive or automated changes are mentioned as belonging
> here, nothing else. And commits like these have functional changes:
>
> # Fix T82520: error building freestyle with Python3.8
> # Build-system: Force C linkage for all DNA type headers
> # Cleanup: use preprocessor version check for PyTypeObject declaration
>
> So as far as I can tell this is just not following the documented
> guidelines.
>
> Thanks,
> Brecht.
>
>
>
> On Mon, Dec 28, 2020 at 8:48 PM Ankit via Bf-committers <
> bf-committers@blender.org> wrote:
>
>> Hello
>> I'm getting used to it.
>> I'll remove several commits soon, now that I have received the
>> feedback on the last commit, and will use stricter conditions in the
>> future.
>>
>> My premise
>> - for being lenient was that it saves other people from committing to
>>   the file which keeps the noise in git log low.
>> - for renames was that a refactoring tool was used
>>   with as little human intervention as possible.
>> - for clang-tidy being the auto-fixes feature that clang-tidy gives.
>>
>>> All,
>> That's a new way of raising concerns on commits.
>>
>>> but I really
>>> would still like to see smaller and clearly manual cleanups
>>> in git blame.
>> If I see "cleanup" in the title, the onus is on the committer to make
>> sure that it really is a cleanup. If that promise is kept, I don't see
>> why a cleanup commit interests you.
>>
>>> Changes in this file don't even seem to go through code review.
>> I thought it keeps the overhead of keeping a utility file low.
>>
>> Ankit
>>
>>
>>> On 29-Dec-2020, at 00:40, Ray Molenkamp via Bf-committers <
>> bf-committers@blender.org> wrote:
>>> All,
>>>
>>> What's going in with this file? there's 50+ commits in there
>>> and I disagree with virtually every single hash I sampled
>>> from it.
>>>
>>> If we want to hide large changes made by automated tools like
>>> the big clang-format [1] change, yeah awesome, but I really
>>> would still like to see smaller and clearly manual cleanups
>>> in git blame.
>>>
>>> Changes in this file don't even seem to go through code review.
>>> In the original review [2] both Brecht and Campbell mention
>>> that it be "OK for larger changes" but that is not what appears to
>>> be happening.
>>>
>>> This is not how this is supposed to work, is it?
>>>
>>> --Ray
>>>
>>> [1]
>> https://developer.blender.org/rBe12c08e8d170b7ca40f204a5b0423c23a9fbc2c1
>>> [2] https://developer.blender.org/D9234
>>> ___
>>> 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
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] .git-blame-ignore-revs entries.

[Ray Molenkamp via Bf-committers]

On 2020-12-28 12:47 p.m., Ankit wrote:
> Hello
> I'm getting used to it.
> I'll remove several commits soon, now that I have received the
> feedback on the last commit, and will use stricter conditions in the future.

I'd like to replace "stricter conditions" with "well defined/documented 
conditions" hence the prod to bf-c

>> All,
> That's a new way of raising concerns on commits.

I don't have a concern with "a commit", I have a concern with "The process of 
how we manage this file", for which bf-committers is an appropriate place.  

> If I see "cleanup" in the title, the onus is on the committer to make
> sure that it really is a cleanup. If that promise is kept.

Developers make mistakes and changes can have unforeseen consequences 
sometimes, as much as we'd all like to write 100% bug free code, guaranteeing 
it is quite something else. Small changes in structure can sometimes trigger 
optimizer bugs in compilers, it can be very relevant knowing if even a 
relatively safe, 100% correct cleanup commit happened to a piece of code.

> I don't see why a cleanup commit interests you.

A cleanup commit is a commit like any other which can potentially introduce 
bugs and should be treated as such, hiding it from git blame is counter 
productive.

Now having large quantity of all code blame to a single commit (like 
e12c08e8d170) yeah that's clearly annoying, and should be remedied but anything 
beyond that I do not see the benefits of hiding such changes. 

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

[Bf-committers] .git-blame-ignore-revs entries.

[Ray Molenkamp via Bf-committers]

All,

What's going in with this file? there's 50+ commits in there
and I disagree with virtually every single hash I sampled
from it.

If we want to hide large changes made by automated tools like
the big clang-format [1] change, yeah awesome, but I really
would still like to see smaller and clearly manual cleanups
in git blame.

Changes in this file don't even seem to go through code review.
In the original review [2] both Brecht and Campbell mention
that it be "OK for larger changes" but that is not what appears to
be happening.

This is not how this is supposed to work, is it?

--Ray

[1] https://developer.blender.org/rBe12c08e8d170b7ca40f204a5b0423c23a9fbc2c1
[2] https://developer.blender.org/D9234
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GPencil I/O Project: Request to integrate libharu lib to export PDF format

[Ray Molenkamp via Bf-committers]

Soo.. this thread has a good run, lots of good feedback, but it
still seems decision-less, I'll happily do the work to make this happen,

but who makes the final call here?

--Ray

On 2020-12-15 9:19 p.m., Campbell Barton via Bf-committers wrote:
> To follow up on previous messages:
>
> - On my system the stripped library is ~830kb,
>   over half of the libraries file-size is binary data for fonts and
> character encoding tables,
>   if we wanted we could remove these - bringing the size down to ~350kb.
>
> - This library is available on mainstream Linux distributions,
>   so even if this isn't maintained by the author, it's not exactly
> abandon-ware either.
>   From checking suse [0] & debian's [1] repository, their patches
> aren't likely to be useful to us
>   since they're only tweaks for building & header guards.
>
> - I ran some (admittedly basic) tests with valgrind & ASAN
>   which didn't show up any issues that would be cause for concern.
>
> So while I'm still not so keen to depend on unmaintained code.
> +1 to include this as an optional library.
>
> [0] https://build.opensuse.org/package/show/openSUSE:Factory/libharu
> [1] https://packages.debian.org/stable/source/libharu
>
> On Tue, Dec 15, 2020 at 1:17 AM Sybren A. Stüvel via Bf-committers
>  wrote:
>> On Fri, 11 Dec 2020 at 18:55, Brecht Van Lommel via Bf-committers
>>  wrote:
>>> Adding an abstraction layer so theoretically the library can be switched
>>> out for another is probably not very helpful. If we were using this in many
>>> places maybe, but in my experience, these kinds of abstraction layers get
>>> in the way more than they help.
>> I agree. IMO such an abstraction layer is generally only really worth
>> it if you already have two different libraries to support, and you
>> know enough about the differences in architecture that you can
>> actually create the proper abstractions.
>>
>>> libharu seems like the most reasonable solution.
>> I agree, although the "not maintained since 2013" is a bit scary. The
>> fact that we won't be using the known-buggy parts of the code helps,
>> but I do think this should then be documented properly somewhere. If
>> the inclusion of the library is done under the assumption that no
>> images will be read, and no PDF will be imported, because these are
>> buggy code paths, this should be clear to future contributors as well.
>> Without such warnings in place, people are bound to be looking at the
>> library to create some PDF-to-GP importer.
>>
>> Sybren
>> ___
>> 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] Libraries source code

[Ray Molenkamp via Bf-committers]

see inline replies

On 2020-12-14 4:21 a.m., Dalai Felinto via Bf-committers wrote:
> Hi Ray,
> Thanks for your reply.
>
> The "it is scattered all over the place, and is fragile" is my personal 
> opinion, and what motivated me to write the email.
>
> The propose to self-host was indeed from Ton. But I didn't want to add the 
> weight of his opinion on something that could first use some clarification.
Still feels like you had a political issue and came up with some bogus reason 
to justify it, but let the past be the past, perhaps we should have a new years 
resolution of calling a spade a spade for 2021.
>
> My proposal to move forward is for the Building module to write down in the 
> wiki the current rules for:
>
> * When is a library hosted in `//extern`

I'm not aware of any hard rules, /extern existed before I joined, what I 
understood over the years it's a collection of libraries that fall in one or 
more of the following groups:

1) Are hard to find in the average linux package repo
2) we have significant patches on
3) We are maintaining since they have no other home (anymore?)

Sergey may have a more accurate definition.

personal opinion:

I not a huge fan of /extern, it is code that seemingly seldom changes and some 
of it contributes to a fair chunk of the total blender build time (looking at 
you, libmv) however previous attempts to evict some libs from there were met 
with fierce resistance, so it is what is, not a hornets nest I'm particularly 
looking forward to kicking.

> * When is a library maintained in `svn lib`
logically following the last question: when it's not in /extern and we still 
need it to build blender
> * When should the libraries be updated
I'm not aware of any hard rules there either, however personal opinion :

Ideal situation: Every lib is owned by one or more of the module teams, they 
ask for updates in bcon1,  occasionally newer versions are required for 
platform support, this can be discussed with the module(s) that own the 
dependency.

Actual situation: essentially no-one cares, i did a complete lib version bump a 
few versions ago, and i will literally never do it again, rarely have i seen 
that much indecisive apathy on something.  The question wasn't even hard, "hey 
your module depends on lib X,  would you like an update?" they didn't even have 
to do the work!

> * The differences between `make deps` and `install_deps.sh` and why we 
> maintain both

As per my last email, "make deps" is for the platform devs to maintain the SVN 
libs, target audience +- 3 people, it covers all platforms we support and only 
those.

`install_deps.sh` is a linux only script that will get the libs from a distro's 
repo is possible and build from source other wise, this used to be the way the 
linux developers got the libs before we had SVN libs for that platform, we 
still maintain it since it has a passionate maintainer willing to do the work.

> * The current reasoning to not self-host the svn libraries sources
There has never been any reason to, In the last 5 yeas I maintained this script 
the "it's a bit fragile" has not once caused any issues, so I question the 
validity of that argument, I'm not sure we need to document the reasoning for 
not doing it any more than we need to document why not every developer on the 
animations team owns a cat named sparkles. They are just question that don't 
come up a whole lot.
>
> Having this clear would have also helped the recent "VFX Reference Platform" 
> discussion.

I do not see how any of this discussion has any merit on "do we follow the VFX 
Reference Platform versions or not" given that once more is a political 
discussion, not a technical or organizational one. The choice to stay on python 
3.7.x or update to 3.9.x is not depending on if the pyhon libs live in svn or 
/extern , why install_deps.sh exists or the reasoning why we don't keep the 
source of deps in svn, even who gets to ask for updates is irrelevant if we 
politically decide to stick with 3.7.x.

This is not a discussion for the platform team, this is between the python team 
and whomever makes the political calls, we (the platform team) have no horse in 
this race, building python 3.7.x is about as much work as building python 
3.9.x, it really doesn't matter from a platform perspective.

> I can gladly help out with the writing if no else from the "Platforms, Builds 
> & Tests" module can pick that up.

I don't think the lack of documentation is due to lack of people wanting to 
document it, but as you probably noticed by now getting a decisions out of 
people on these matters is like herding cats.

--Ray


> On 13-12-2020 18:49, Ray Molenkamp via Bf-committers wrote:
>> Seems like the reason has moved from "it's scattered all
>> over the place, that's a bit fragile" (technical r

Re: [Bf-committers] Libraries source code

[Ray Molenkamp via Bf-committers]

Seems like the reason has moved from "it's scattered all
over the place, that's a bit fragile" (technical reason,
which I will happily share/defend my views on) to
"because I want it for political reasons" (where not a
single technical argument will change your mind)

In the future it's probably best to be upfront where a
desire comes from rather than having it masquerade  as a
technical issue and hope no-one calls you on it.

--Ray

On 2020-12-13 9:29 a.m., Ton Roosendaal via Bf-committers wrote:
> Hi,
>
> The reason is to protect software freedom in general. I don't like it that 
> for building Blender you are forced to use commercial sites offering code. It 
> would be different if we use established GNU approved platforms.
>
> https://www.gnu.org/software/repo-criteria-evaluation.html
>
> https://www.gnu.org/software/repo-criteria.en.html
>
> I would find it really a positive statement if we copy all external bundles 
> to blender.org and build from there.
>
> Nothing urgent though, it's politics :)
>
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> On 10/12/2020 16:02, Ray Molenkamp via Bf-committers wrote:
>> I'm unsure what this would achieve beyond making the lib update process more 
>> frustrating than it already is?
>>
>> The deps builder we have its singe purpose is to facilitate the building of 
>> our SVN libs nothing more nothing less, its target audience is essentially 3 
>> people (the mac/linux/windows platform maintainers) we share the script with 
>> the world since that's the spirit of opensource, but we offer very little 
>> (if any) support on it. Developers are advised to use the SVN libs and most 
>> distro's have their own build infrastructure for dependencies already. If 
>> you want to build all deps using our script on your own, good on you, we 
>> certainly won't stop you, but the script is aimed at a very narrow build 
>> environment (ours) with a very narrow use-case (our svn libs) it *cannot* be 
>> and *will not* be the end all and be all build script for all possible 
>> environments and all possible distributions.
>>
>> Having the source to all deps on our server would bring very little 
>> (actually just an extra burden) to the party, keeping that context in mind, 
>> what is the problem you are trying to solve?
>>
>> --Ray
>> On 2020-12-09 8:14 a.m., Dalai Felinto via Bf-committers wrote:
>>> Hi,
>>>
>>> At the moment the source code to build the libraries required by Blender is 
>>> scattered everywhere:
>>>
>>> * github
>>> * sourceforge
>>> * own projects sites
>>> * archived pages on the web (e.g., http.debian.net for the bzip)
>>>
>>> For the complete list see: 
>>> `build_files/build_environment/cmake/versions.cmake`
>>>
>>>
>>> Is there a reason for Blender to not host a copy of the compressed source 
>>> files? Given that we depend on almost 40 different libraries, it seems a 
>>> bit fragile to count on them be online forever.
>>>
>>>
>>> The zip/tar.gz, ... packages could be stored in: 
>>> https://svn.blender.org/svnroot/bf-blender/trunk/lib/source
>>>
>>>
>>> Thanks,
>>>
>>> -Dalai-
>>> 
>>> Dalai Felinto - da...@blender.org - www.blender.org
>>> Blender Development Coordinator
>>> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>>>
>>> ___
>>> 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
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GPencil I/O Project: Request to integrate libharu lib to export PDF format

[Ray Molenkamp via Bf-committers]

Seems reasonable (and I agree) however playing devils advocate:

if we're going to need cairo down the road anyhow we may
as well rip that band-aid off now and deal with the pain
of building it rather than building libharu now and cairo later.

--Ray


On 2020-12-11 10:47 a.m., Brecht Van Lommel via Bf-committers wrote:
> So weighing the options, to me libharu seems like the most reasonable
> solution.
>
>
>
> On Fri, Dec 11, 2020 at 1:51 AM Campbell Barton via Bf-committers <
> bf-committers@blender.org> wrote:
>
>> By this logic we could blindly accept any patch that's had some production
>> testing, without considering long term maintenance.
>>
>> It's possible alternative solutions that call out to existing well
>> maintained
>> converters would have been fine in production too.
>> It's not that I'm pushing back against including this entirely,
>> I'm just not a fan of this "it worked in a production test - so lets
>> include it" -- attitude.
>>
>> Over the years I believe we've spent significant time investigating
>> issues with 3rd party libraries (resource leaks, conflicting symbols,
>> linking problems, platform specific errors etc).
>> If there is a good chance we can avoid this entirely, it could be
>> worth looking into.
>>
>> If we do include libharu, how would this be included?  in extern/ or
>> would we bundle it in SVN's lib?
>>
>> On 12/10/20 8:26 PM, Dalai Felinto wrote:
>>> Hi,
>>>
>>> My suggestion would be the following:
>>>
>>> * Stick to libharu since it was proven that works for the intended use
>>> case.
>>> * Make sure libharu integration in the code goes via a layer of
>>> abstraction.
>>>
>>> So instead of trying now to solve an non-existent problem, we use
>>> development time to make sure the existing solution is robust enough to
>>> be replaced if needs be.
>>>
>>> Regards,
>>> Dalai
>>>
>>> On 09-12-2020 23:34, Campbell Barton via Bf-committers wrote:
 rsvg-convert (which uses cairo), is a utility that converts SVG to
 PDF, it can create multi-page PDF's from many SVG's too.

 If for some reason we need more control then a command line utility
 provides, there are Python multiple options regarding bindings for
 cairo & svg conversion.
  From what I can tell they can convert SVG to PDF quite easily.

 Regarding bundling the conversion tools, if this it's only a few
 studios with specific requirements, we don't _necessarily_ need to
 include the conversion utilities with Blender, although this is a
 decision we could easily change.

 I'm not pushing for this as the final solution, just checking if it
 might be a simpler option compared to taking on a PDF library that
 isn't maintained anymore.
 ___
 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
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Libraries source code

[Ray Molenkamp via Bf-committers]

I'm unsure what this would achieve beyond making the lib update process more 
frustrating than it already is?

The deps builder we have its singe purpose is to facilitate the building of our 
SVN libs nothing more nothing less, its target audience is essentially 3 people 
(the mac/linux/windows platform maintainers) we share the script with the world 
since that's the spirit of opensource, but we offer very little (if any) 
support on it. Developers are advised to use the SVN libs and most distro's 
have their own build infrastructure for dependencies already. If you want to 
build all deps using our script on your own, good on you, we certainly won't 
stop you, but the script is aimed at a very narrow build environment (ours) 
with a very narrow use-case (our svn libs) it *cannot* be and *will not* be the 
end all and be all build script for all possible environments and all possible 
distributions.

Having the source to all deps on our server would bring very little (actually 
just an extra burden) to the party, keeping that context in mind, what is the 
problem you are trying to solve?

--Ray
On 2020-12-09 8:14 a.m., Dalai Felinto via Bf-committers wrote:
> Hi,
>
> At the moment the source code to build the libraries required by Blender is 
> scattered everywhere:
>
> * github
> * sourceforge
> * own projects sites
> * archived pages on the web (e.g., http.debian.net for the bzip)
>
> For the complete list see: 
> `build_files/build_environment/cmake/versions.cmake`
>
>
> Is there a reason for Blender to not host a copy of the compressed source 
> files? Given that we depend on almost 40 different libraries, it seems a bit 
> fragile to count on them be online forever.
>
>
> The zip/tar.gz, ... packages could be stored in: 
> https://svn.blender.org/svnroot/bf-blender/trunk/lib/source
>
>
> Thanks,
>
> -Dalai-
> 
> Dalai Felinto - da...@blender.org - www.blender.org
> Blender Development Coordinator
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
> ___
> 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] GPencil I/O Project: Request to integrate libharu lib to export PDF format

[Ray Molenkamp via Bf-committers]

I can't say I'm super thrilled to build cairo on windows,
but if that's the direction we want to go, so be it.

--Ray


On 2020-12-09 11:19 a.m., Brecht Van Lommel via Bf-committers wrote:
> I'm not sure there exists a simple utility to convert SVG to PDF that we
> could include, if we want to go that way?
>
> Inkscape uses Cairo for PDF writing, that could be a more actively
> maintained alternative.
> https://www.cairographics.org/
>
> It has also been proposed to be added to handle Wayland window decorations
> in D7989, so it would let us solve both problems with one library.
>
>
> On Wed, Dec 9, 2020 at 11:46 AM Antonio Vazquez via Bf-committers <
> bf-committers@blender.org> wrote:
>
>> There are several reasons why I decided to use libharu.
>>
>> * The PDF format is very stable and does not change substantially, so we
>> are not at great risk due to format changes.
>> * I already know that this library is not maintained, but since the PDF
>> format does not change, it does not require much maintenance.
>> * This library is widely used in other software to generate PDF, so it is
>> well proven.
>>
>> Regarding the bugs you comment, I have seen that several have a patch to
>> solve them, but in any case, the use I make of the library does not include
>> using images, only a very simple use. I do not expect, in the short or
>> medium term, to use anything related to appending images, so these bugs do
>> not affect us at all. Attaching images to a PDF does not make much sense in
>> our case.
>>
>> Including a converter from SVG could work, but the problem is that in PDF
>> we can generate a document with several pages and in SVG I have not seen
>> that this is supported. Imagine that we want to generate a storyboard with
>> 100 frames ... we would need to export 100 SVG and join them later ... now
>> that is very simple. We would also have to assess the speed of the
>> conversion, since now it is all C / C ++ and it is very fast.
>>
>> The other option I have been considering is to fork libharu and create a
>> tiny version with the functions we need and remove any appended image
>> support.
>>
>> Antonio
>>
>> El mié, 9 dic 2020 a las 0:46, Campbell Barton via Bf-committers (<
>> bf-committers@blender.org>) escribió:
>>
>>> Hi Antonion,
>>>
>>> From what I can tell libharu hasn't been very active since 2013, their
>>> site states they're looking for a new maintainer.
>>> Would we become the defacto maintainers of this library?
>>>
>>> I checked their issue tracker, while many reports are support requests
>>> and build issues, there are some more serious looking issues too, eg:
>>>
>>> https://github.com/libharu/libharu/issues/73
>>> https://github.com/libharu/libharu/issues/71
>>> https://github.com/libharu/libharu/issues/63
>>>
>>> Is there a significant advantage in integrating a library compared
>>> with bundling a utility that converts SVG to PDF?
>>> In this case it could be an optional dependency, or we bundle the
>>> conversion tool in official releases so PDF support is still
>>> integrated from a user perspective.
>>>
>>> On Wed, Dec 9, 2020 at 6:31 AM Antonio Vazquez via Bf-committers
>>>  wrote:
 Hi All,



 As some of you may already know, for version 2.92 we want to focus on
>> the
 Import and Export processes of Grease Pencil (T83190).



 Currently, the grease pencil is in some way an "island" in the studios
 pipeline and we need to add tools to integrate it. Part of these
 integration processes were the work we did to make image traces (2.91)
>>> and
 shortly, video traces (2.92).



 During the contacts that the members of grease pencil team usually have
 with 2D studios, they have detected that some commercial software very
 important in the studios pipeline does not support the import of SVG,
>> but
 of PDF. In addition, the PDF format allows working in many softwares
>> and
>>> is
 very useful for generating storyboards and work in comics.



 Past weeks, I have been working on a new I/O module for grease pencil
>> in
>>> C
 ++ and I already have the SVG Importer (T79875) and the SVG Exporter
 (T83191) and PDF Exporter (T83192) working. All work has been done on a
 private branch on my PC.



 You can see a PDF exporter video here: https://youtu.be/BMm0KeMJsI4



 To export to PDF I have used an open source library (libharu
 http://libharu.org/) and would need to integrate that library into
>>> Blender.
 This library is very simple (<1.6 MB on Windows) and allows export to
>> PDF
 easily.



 Finally, exporting to PDF opens up a world of possibilities and
>>> especially
 when the new LineArt module will be integrated into Blender.



 If we agree to integrate libharu, I can prepare the patch for review
>> the
 I/O code I did.



 I would like to hear your opinions.

Re: [Bf-committers] Code Quality Day - 4/Dec

[Ray Molenkamp via Bf-committers]

For the windows folks,

I have enabled clang-tidy for windows so you can now join in
on the fun, but there are some caveats that are important to
be aware of.

1- It will only be configured if WITH_CLANG_TIDY is on in cmake.

2- Only supported in the IDE, no ninja or command line support at
   this moment in time.
 
3- Disabled on build by default, it is really slow running the
   compiler twice, and it emits still a fair number of errors on
   bad code inside windows specific ifdefs. For those reasons
   you have to manually run it from the analyze sub menu.
 
If you run into issues using it feel free to prod me on chat

have fun tomorrow!

--Ray
On 2020-12-03 8:38 a.m., Sergey Sharybin via Bf-committers wrote:
> Hi,
>
> This Friday we have December's code quality day [1].
>
> The full list of approved projects for the quality day is combined in a
> dedicated task [2].
>
> Last day we finished what one might consider essential Clang-Tidy
> integration warnings. There are now modernize category warnings enabled,
> which helps us bring code to 2020 standards [3].
>
> From the last day there is still [4]. It was partially tackled, but there
> are still some ideas which can end up in a nice quality improvement.
>
> There are again some ideas I have in mind of improving the build process.
> Let's talk about it tomorrow!
>
> I would also encourage every module to come with ideas (and solutions ;) to
> what they consider a quality/technical-depth improvement!
>
> Everyone is welcome to help!
>
> For feedback on what to do, code review, and everything else we should use
> #blender-coders in blender.chat.
>
> [1] - https://wiki.blender.org/wiki/Style_Guide/Code_Quality_Day
> [2] - https://developer.blender.org/T73586
> [3] - https://developer.blender.org/T78535
> [4] - https://developer.blender.org/P1756
>
> Have fun tomorrow,
> -Sergey-
> 
> Sergey Sharybin - ser...@blender.org - www.blender.org
> Principal Software Engineer, Blender
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> ___
> 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] Support for 32-bit architectures

[Ray Molenkamp via Bf-committers]

I've always understood our position to be

- We do not plan to break or remove 32 bit support.
- Given we don't CI on 32 bit anymore, breakage can sometimes happen without us 
knowing.
- If external parties supply patches to fix such breakage and they pass code 
review, we merge them. Even if they are for platforms we ourselves do not ship. 
D2860 (haiku OS) is a nice example there.

I'm not sure if that is the official position, but that's my current 
understanding of it.

--Ray

On 2020-11-16 8:36 a.m., Sybren A. Stüvel via Bf-committers wrote:
> Hello list,
>
> Blender 2.80 was the last version of Blender for which 32-bit builds
> were officially supported. This was announced by Brecht in [1].
> That announcement was a bit unclear to me, which I let pass because it
> wasn't that relevant for my position back then. However, now that I'm
> the Linux platform maintainer, I wouldn't mind if the situation was
> clarified.
>
> In that announcement, Brecht writes:
>> Blender 2.80 was the last release where we officially support 32 bit Windows 
>> and Linux builds. [...]
>> We will continue to support it to the level that we do for example ARM. That 
>> is we keep the Blender code working independent of the processor 
>> architecture, particularly for Linux packages. But we don't actively test 
>> them or release our own builds.
> This sounds like an impossibility to me: the promise that we keep
> things working, but without building, or testing. Apparently there is
> also a distinction between "official support" and "support to some
> level".
>
> The Blender requirements page [2] does list 64-bit as a requirement.
> But, there is no "last version that supported 32-bit" in the "Previous
> Versions" section of that page. Also there is no mention of dropping
> official support for 32-bit architectures in the 2.81 release notes
> [3].
>
> I found out about this unclear situation when looking at a patch that
> ought to fix an issue on 32-bit platforms [4]. In the discussion on
> that patch, Brecht writes:
>> When writing or reviewing code, you ensure that there is always a processor 
>> architecture independent code path. And if you get a report and it turns out 
>> such a code path is missing or broken, you fix it. It's the same for x86, 
>> mips, sparc, etc.
> This looks like a statement that these platforms are still supported.
>
> Personally I would summarize the above as:
> - Blender Foundation does not provide buildbots for 32-bit platforms.
> - Developers have to ensure these platforms keep working.
> - Testing such fixes is unnecessary.
>
> I think I'm misunderstanding the situation here, and I wouldn't mind
> if this was clarified.
>
> Sybren
>
> [1]: https://lists.blender.org/pipermail/bf-committers/2019-August/050124.html
> [2]: https://www.blender.org/download/requirements/
> [3]: https://wiki.blender.org/wiki/Reference/Release_Notes/2.81
> [4]: https://developer.blender.org/D9577
> ___
> 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] Policies about patches modifying third-parties libraries.

[Ray Molenkamp via Bf-committers]

While i agree with "you should be able to build blender even with stock/system 
libraries"

I however do not think that the bar for "oh we'll just add it to /extern" 
should be as low as it appears to be. I'd be very much in favor of *NOT* adding 
a behemoth like USD to `/extern` (~75 megs, twice the size `/extern` currently, 
more than all the code in `/source` combined!) and ballooning an already high 
blender build time just to support a single IO format. 

Surely this can be worked out with upstream USD?

--Ray

On 2020-08-25 1:05 p.m., Bastien Montagne via Bf-committers wrote:
> Hi,
>
> Under build_files/build_environment/patches we have a bunch of small patches 
> for the libraries we build using make deps. Most of them are about fixing 
> builds for some platform or architecture, which is a bit annoying but 
> acceptable imho.
>
> However, today I discovered that Blender cannot be built with vanilla USD 
> library, at all. The patch used on this library adds some new function to its 
> API, which (hack over hack) is not even declared in its headers, but in 
> Blender code itself.
>
> I would very much like to propose to strictly forbid such dirty practices, 
> which violate completely the very idea of libraries, especially on OSs like 
> linux, where distributions try very hard to only use dynamically linked 
> shared libraries.
>
> Any library that would need that kind of modifications should be put in 
> extern/, and explicitly built as part of Blender itself. Or at the very 
> least, we should explicitly maintain our own 'fork' of it, with requests to 
> the main repo/maintainers to integrate our changes or otherwise propose a 
> solution to the problem.
>
> But I do hope there are ways to avoid such ugly changes anyway?
>
> Cheers,
> Bastien
>
>
> ___
> 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] Future Releases with VR?

[Ray Molenkamp via Bf-committers]

UPBGE is a blender fork we do not maintain, so any questions
you have on UPBGE you'll have to sort out with the people who
work on it.

Their community page [1] has several options of contacting them.

Greetings,
Ray

[1] https://upbge.org/community.html
 

On 2020-04-10 12:58 a.m., Armani Bless via Bf-committers wrote:
> Hello I know UPBGE is fairly new but I want to start a new game with a
> python game engine. Will UPBGE be looking forward in developing in VR?
> Maybe sometime in the next few years? I will be creating a hybrid game of a
> VR and a real-time war strategy game. First I will developed the war
> strategy game(ETA 1-2 years) then implement the VR spectrum.
> I will love to hear your thoughts of the future of the company?
>
> Also how can I donate ? I want to donate a little every month.
> ___
> 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] Embree library update to 3.8.0

[Ray Molenkamp]

Windows is done!

Tracking ticket in : https://developer.blender.org/T73819

--Ray

On 2020-02-14 11:19 a.m., Stefan Werner wrote:
> Hello platform maintainers,
>
> I updated the Embree version for `make deps` and install_deps.sh to 3.8.0.
> Please update the binaries when you get a chance.
>
> Currently, there is no code in Blender that requires this new version yet. 
> Once updated binaries for all the platforms are available, I will check in 
> features that require the newer Embree library (D6575).
>
> -Stefan
> ___
> 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] Dev Fund - Communication guidelines

[Ray Molenkamp]

Yeah I think the confusion comes from how phab organizes groups which it has 
given the unfortunate name 'projects'

for instance the moderators project : 
https://developer.blender.org/project/members/1/

It be 'real bad' to publish the personal information of these people without 
their consent, hence the ask for clarification.

Good to see it was just a misunderstanding!

Greetings,
Ray

On 2020-02-13 2:03 a.m., Ton Roosendaal wrote:
> Hi,
>
> I mean with project members the people with commit access. It's not 
> publishing everyone's email address, it's about being able to verify 
> someone's identity.
>
> If you prefer to separate your Blender work from your private work, create a 
> dedicated email address for communication with the Blender project, but the 
> default is to be approachable and visible.
>
> Same rule applies here in Mailman btw! If you email the list, the address you 
> receive replies with is visible here.
>
> Exceptions can apply, we can check on that individually. But being visible 
> and open as contributor to Blender is important to gain trust levels for 
> future contributors who work for studios/companies. I prefer them to be 
> visible in that role as well.
>
> This (or other guidelines) can be put in a future CLA as well. Another 
> discussion for later.
>
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> On 12/02/2020 20:06, Ray Molenkamp wrote:
>> Could you clarify this a tiny bit? Cause it kinda sounds like are want to 
>> publish the email addresses of anyone in d.b.o project ?
>>
>> the 300+ volunteers in the moderators project may not take kindly on that
>>
>> --Ray
>>
>> On 2020-02-12 10:34 a.m., Ton Roosendaal wrote:
>>> Hi everyone,
>>>
>>> 3. For the future (Phabricator/Git)
>>>
>>> - Show email addresses from project members (to visitors who are logged in)
>>>
>>>
>>> Thanks,
>>>
>>> -Ton-
>>> --
>>> Ton Roosendaal - t...@blender.org - www.blender.org
>>> Chairman Blender Foundation, Director Blender Institute
>>> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>>>
>>>
>>> ___
>>> 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
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Dev Fund - Communication guidelines

[Ray Molenkamp]

Could you clarify this a tiny bit? Cause it kinda sounds like are want to 
publish the email addresses of anyone in d.b.o project ?

the 300+ volunteers in the moderators project may not take kindly on that

--Ray

On 2020-02-12 10:34 a.m., Ton Roosendaal wrote:
> Hi everyone,
>
> 3. For the future (Phabricator/Git)
>
> - Show email addresses from project members (to visitors who are logged in)
>
>
> Thanks,
>
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> ___
> 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] OSL / LLVM / Freetype library updates.

[Ray Molenkamp]

Fellow Platform devs,

Due to various issues in several of the dependencies some of them
have been bumped to new versions.

OSL 1.10.9 / LLVM 9.0.1 - D6744
FreeType 2.10.1 - D6645

Please update these libraries for *Master only*, 2.82 will ship
with the old versions!

You may see SVN commits from me for other dependencies (oidn, libxml)
these are just windows build fixes in the current versions, no versions
are changed, no action is required for the linux/mac platforms.

Greetings,
Ray

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

Re: [Bf-committers] Library upgrades for VFX reference platform 2020 / Windows Lib update

[Ray Molenkamp]

Windows SVN libs have been updated for the 2.82 tag
and the changes in the platform_win32 file in the
2.82 release branch have been done as well. 2.82
is in a good spot, however...

Due to boost being included the upload has taken
most of my night so I'm not even going to dare
to start the merge to trunk at this point.

This does mean that if someone merges 2.82 to
master (which they will likely do), the master
windows build will be broken until someone does
the svn libs merge. If that happens I apologize
and if you need to get things done, please edit
the BOOST_POSTFIX variable in platform_win32.cmake
temporarily back to 1_68. Sorry about that...

Brecht, mind taking it from here ?

Greetings
-Ray


On 2020-01-20 4:59 a.m., Brecht Van Lommel wrote:
> Hi platform maintainers,
>
> The library versions for OpenEXR, OpenVDB, Blosc and Boost have been
> upgraded. Please rebuild precompiled libraries for your platforms. We want
> to include these in 2.82 still. Due to dependencies, all these libraries
> must be rebuilt:
>
> OpenEXR
> OpenImageIO
> OSL
> OpenVDB
> Blosc
> Boost
> USD
> Alembic
> OpenColorIO
>
> Please commit to the blender-2.82-release svn tag, which is automatically
> checked out when running "make update" from the blender-v2.82-release
> Blender branch. Then we can merge those changes in trunk, I can help with
> that if needed.
>
> I will commit the macOS libraries.
>
> Thanks,
> Brecht.
> ___
> 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] Blender server upgrades

[Ray Molenkamp]

not sure what changed but phab is either no longer or real slow picking up on 
git commits

--Ray

On 2020-01-17 1:01 p.m., Dan McGrath wrote:
> Hi,
>
> Just a heads up that I will be attempting to upgrade some of the FreeBSD
> servers and packages tonight, so there will be reboots.
>
> So, go out, enjoy your Friday night, and get off the internet so I can poke
> at things :) o/
>
>
> Cheers,
>
> Dan McGrath
> ___
> 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] Aligning with the vfx reference platform in 2020

[Ray Molenkamp]

tbbmalloc proxy was failing on win10 on earlier versions of TBB, I forgot the 
exact
version that fixed the issue [1] seems to imply it was 2019_U1, I bumped it to
2019_U9 just because it was current at the time, U6 will probably work, however
I'm currently more interested in bumping the deps we have, rather than rolling 
back the
one that is slightly ahead, given at-least one of them fixes some CVE's 
(openEXR).

However as a platform dev I'm mostly following in the libs department, if 
someone
tells me we need lib X version Y, I'll will go out of my way to make it happen
however these are not my libs, and I cannot be responsible for keeping an eye 
on the
version that get released or the integration into blender whenever there is a
code incompatible update.

Issue is nobody seems to be taking responsibility for the libs, hence they lag 
or
only get updated cause the new version solves build issues I have. Ideally we'd
assign each and  every one of the 30+ libs we have to a module, and the module
owners request updates to them. They don't have to worry about specific 
build-flags
for mac/linux/windows platform devs are quicker and better at it however if your
module depends on a external dependency keep an eye on it!

Can dalai organize anything in this department? doesn't have to be my idea
but we have to do a better/more structured job at managing these deps.

--Ray

On 2020-01-11 8:05 p.m., Stephen Swaney wrote:
> Following the VFX Platofrm for a year is reasonable.
> The problem with doing it long-term is they are handicapped by their
> reliance on Qt, something we thankfully don't suffer from.
>
> Upgrading our dependent libs is a good thing (at least in theory!).
>
> I seem to recall seeing a bunch of bugs related to Intel TBB on Windows
> which makes rolling back to U6 from U9 a bit scary.  Although, newer is not
> always better.  Ray would be a better person to comment on this since he is
> in it up to his ears.
>
> S.
>
> On Fri, Jan 10, 2020 at 1:03 PM Ray Molenkamp  wrote:
>
>> That's me hence i'm asking if i should update these libs or not :)
>>
>> --Ray
>>
>> On 2020-01-10 10:54 a.m., Ton Roosendaal wrote:
>>> Hi,
>>>
>>> To my knowledge these differences are minor and won't be a showstopper
>> for studio pipelines.
>>> I will leave it to the platform maintainers though :)
>>>
>>> -Ton-
>>> --
>>> Ton Roosendaal - t...@blender.org - www.blender.org
>>> Chairman Blender Foundation, Director Blender Institute
>>> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>>>
>>>
>>> On 10/01/2020 18:30, Ray Molenkamp wrote:
>>>> I took a quick survey, most of the libs are either not applicable to us
>> (QT related stuff) or at the preferred version already
>>>> however some of them are lagging behind a bit (or a lot in case of
>> openVDB) and one of them is a little ahead of the VFX platform
>>>> Behind:
>>>> OpenEXRVFX:2.4.xBlender:2.3.0
>>>> OpenSubdiv VFX:3.4.xBlender:3.4.0 RC2
>>>> OpenVDBVFX:7.x  Blender:5.1.0
>>>> Boost  VFX:1.7  Blender:1.68
>>>>
>>>> Ahead:
>>>> Intel TBB  VFX:2019_U6  Blender:2019_U9
>>>>
>>>> Is the plan to get at-least the lagging ones up to the VFX versions for
>> 2.83?
>>>> --Ray
>>>>
>>>>
>>>> On 2020-01-10 10:03 a.m., Ton Roosendaal wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> Blender has always been an early adopter of new libraries. We moved to
>> Python 3 ten years ago already. Unfortunately that made Blender
>> incompatible with the Python 2.7 infrastructure in many studios. But the
>> industry is catching up! Python 3.7 is now the reference standard.
>>>>> To give studios enough time and confidence to check out on Blender, I
>> propose to respect the VFX Platform versions for the entire year of 2020.
>> That implies we will be very conservative with upgrading libraries, for
>> example Python will stick to 3.7 this year for official releases.
>>>>> I've checked it with the core team and administrators, and they're OK
>> - provided this won't hold back essential improvements for our users.
>>>>> Check the reference platform here:
>>>>> https://vfxplatform.com/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Ton-
>>>>> --
>>>>> Ton Roosendaal - t...@blender.org - w

Re: [Bf-committers] Aligning with the vfx reference platform in 2020

[Ray Molenkamp]

That's me hence i'm asking if i should update these libs or not :)

--Ray

On 2020-01-10 10:54 a.m., Ton Roosendaal wrote:
> Hi,
>
> To my knowledge these differences are minor and won't be a showstopper for 
> studio pipelines.
> I will leave it to the platform maintainers though :)
>
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> On 10/01/2020 18:30, Ray Molenkamp wrote:
>> I took a quick survey, most of the libs are either not applicable to us (QT 
>> related stuff) or at the preferred version already
>>
>> however some of them are lagging behind a bit (or a lot in case of openVDB) 
>> and one of them is a little ahead of the VFX platform
>>
>> Behind:
>> OpenEXR    VFX:2.4.x    Blender:2.3.0
>> OpenSubdiv VFX:3.4.x    Blender:3.4.0 RC2
>> OpenVDB    VFX:7.x  Blender:5.1.0
>> Boost  VFX:1.7  Blender:1.68
>>
>> Ahead:
>> Intel TBB  VFX:2019_U6  Blender:2019_U9
>>
>> Is the plan to get at-least the lagging ones up to the VFX versions for 2.83?
>>
>> --Ray
>>
>>
>> On 2020-01-10 10:03 a.m., Ton Roosendaal wrote:
>>
>>> Hi everyone,
>>>
>>> Blender has always been an early adopter of new libraries. We moved to 
>>> Python 3 ten years ago already. Unfortunately that made Blender 
>>> incompatible with the Python 2.7 infrastructure in many studios. But the 
>>> industry is catching up! Python 3.7 is now the reference standard.
>>>
>>> To give studios enough time and confidence to check out on Blender, I 
>>> propose to respect the VFX Platform versions for the entire year of 2020. 
>>> That implies we will be very conservative with upgrading libraries, for 
>>> example Python will stick to 3.7 this year for official releases.
>>>
>>> I've checked it with the core team and administrators, and they're OK - 
>>> provided this won't hold back essential improvements for our users.
>>>
>>> Check the reference platform here:
>>> https://vfxplatform.com/
>>>
>>> Thanks,
>>>
>>> -Ton-
>>> --
>>> Ton Roosendaal - t...@blender.org - www.blender.org
>>> Chairman Blender Foundation, Director Blender Institute
>>> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>>>
>>>
>>> ___
>>> 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
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Aligning with the vfx reference platform in 2020

[Ray Molenkamp]

I took a quick survey, most of the libs are either not applicable to us (QT 
related stuff) or at the preferred version already

however some of them are lagging behind a bit (or a lot in case of openVDB) and 
one of them is a little ahead of the VFX platform

Behind:
OpenEXR    VFX:2.4.x    Blender:2.3.0
OpenSubdiv VFX:3.4.x    Blender:3.4.0 RC2
OpenVDB    VFX:7.x  Blender:5.1.0
Boost  VFX:1.7  Blender:1.68

Ahead:
Intel TBB  VFX:2019_U6  Blender:2019_U9

Is the plan to get at-least the lagging ones up to the VFX versions for 2.83?

--Ray


On 2020-01-10 10:03 a.m., Ton Roosendaal wrote:

> Hi everyone,
>
> Blender has always been an early adopter of new libraries. We moved to Python 
> 3 ten years ago already. Unfortunately that made Blender incompatible with 
> the Python 2.7 infrastructure in many studios. But the industry is catching 
> up! Python 3.7 is now the reference standard.
>
> To give studios enough time and confidence to check out on Blender, I propose 
> to respect the VFX Platform versions for the entire year of 2020. That 
> implies we will be very conservative with upgrading libraries, for example 
> Python will stick to 3.7 this year for official releases.
>
> I've checked it with the core team and administrators, and they're OK - 
> provided this won't hold back essential improvements for our users.
>
> Check the reference platform here:
> https://vfxplatform.com/
>
> Thanks,
>
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> ___
> 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] Mantaflow landing and unit tests.

[Ray Molenkamp]

> One cruel thing i can think about is to force everyone to pay more
> attention is to prevent new build from being uploaded if regression tests
> are failing. We'll hear very quickly from users that there are no new
> builds on buildbot.
Cruel or not, It'll cost less resources to deal with
a single well defined test case, rather than triaging
and managing an unknown number of tickets that may
come from the same issue. I don't mind this idea *at all*

--Ray

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

Re: [Bf-committers] Mantaflow landing and unit tests.

[Ray Molenkamp]

There's a couple of things we can look at:

We can take human element out of it, running the tests on a proposed patch
can and probably should be done automatically. I heard there were plans for
this, I hope they materialize sooner rather than later. I think this is one of 
Nathans projects

We are running the tests now on a nightly basis which is great, however
nobody seems to be looking at the results otherwise we would have figured
out the tests were failing 3 weeks ago and either disabled the test or fixed
the problem. I kinda feel that looking at the tests on a daily basis should
be on someones daily morning checklist, perhaps Nathan and/or Dalai can find
someone for this task?

as for commit messages, we have good guidance there [1], having people try a
little harder will probably go a long way there.

--Ray

[1] https://wiki.blender.org/wiki/Style_Guide/Commit_Messages



On 2020-01-02 7:04 p.m., Sebastián Barschkis wrote:
> Hi Ray,
>
> you’re right, the Cycles tests need to be updated. They need to make use of 
> the new fluid modifier.
> Sergey pointed this out to me right after (within 12h) I landed the commits, 
> i.e. the issue is known.
>
> So yes, blame it on me, I overlooked this part. I will look into this as soon 
> as possible.
>
> I agree that this is not ideal. But apart from better commit messages, how 
> can we do better at this time?
>
> Happy new year and best wishes,
> Sebastián
>
>> On 2. Jan 2020, at 22:31, Ray Molenkamp  wrote:
>>
>> All,
>>
>> Hate to be a heckler for running the unit tests, but please:
>>
>> When you land and/or review something big, RUN THE UNIT TESTS!
>>
>> When the monster 10 patch mantaflow patch landed, it broke
>> 6 cycles unit tests on all platforms, 5 with different renders
>> than the reference images and one full on blender crash [1]
>>
>> bda4a284d20164fec2433f7c40f49fc903319400 [2] fixed the render
>> differences and turned the crash into a render difference [3]
>>
>> Unrelated side note: whats with the less than helpful
>> commit message on this commit? it may as well have been
>> committed with the message 'something fluid' or 'Tuesday'
>> would have just as enlightening for other developers.
>>
>> To summarize:
>>
>> - The person submitting the patches has not run the tests
>> - The reviewers have not run the tests
>> - Less than optimal commit messages
>> - 18!! days after landing, there is still a failing test
>>
>> Holiday season or not: I think we can and should do better than this
>>
>> --Ray
>>
>> [1] https://i.imgur.com/LE3baOg.png
>> [2] https://developer.blender.org/rBbda4a284d20164fec2433f7c40f49fc903319400
>> [3] https://i.imgur.com/5we0hEv.png
>>
>>
>> ___
>> 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

[Bf-committers] Mantaflow landing and unit tests.

[Ray Molenkamp]

All,

Hate to be a heckler for running the unit tests, but please:

When you land and/or review something big, RUN THE UNIT TESTS!

When the monster 10 patch mantaflow patch landed, it broke
6 cycles unit tests on all platforms, 5 with different renders
than the reference images and one full on blender crash [1]

bda4a284d20164fec2433f7c40f49fc903319400 [2] fixed the render
differences and turned the crash into a render difference [3]

Unrelated side note: whats with the less than helpful
commit message on this commit? it may as well have been
committed with the message 'something fluid' or 'Tuesday'
would have just as enlightening for other developers.

To summarize:

- The person submitting the patches has not run the tests
- The reviewers have not run the tests
- Less than optimal commit messages
- 18!! days after landing, there is still a failing test

Holiday season or not: I think we can and should do better than this

--Ray

[1] https://i.imgur.com/LE3baOg.png
[2] https://developer.blender.org/rBbda4a284d20164fec2433f7c40f49fc903319400
[3] https://i.imgur.com/5we0hEv.png


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

Re: [Bf-committers] TBB version inconsistencies

[Ray Molenkamp]

I mentioned the bump of the TBB Version in D6218 [1] however
this should have been communicated better to the other platform
teams. 

As for win64_vc14 it is no longer maintained, the reason I kept it
in svn for a little while longer is twofold

1) so people still on/building 2.80/81 based branches that have
not merged master in a while can still build without issues.

2) cycles standalone still uses it, I have not had time yet to
do the work/testing required there.

--Ray

[1] https://developer.blender.org/D6218



On 2019-12-05 4:38 a.m., Sybren A. Stüvel wrote:
> Dear platform maintainers,
>
> I recently updated the TBB library for Linux (in the
> linux_centos7_x86_64 dir on SVN). The version installed by 'make deps'
> is 2019.9, but the version in linux_centos7_x86_64 was still at 2018.0,
> which caused issues with USD.
>
> Here are the versions currently built for the other platforms:
>
> - darwin: 2018.0
> - win64_vc14: 2018.0
> - win64_vc15: 2019.9
>
> Is the win64_vc14 directory still used? It's not mentioned on
> https://wiki.blender.org/wiki/Building_Blender/Windows.
>
> Could the Darwin maintainer update the TBB library?
>
> To be clear: I didn't upgrade to a new version of TBB, 2019.9 was
> already in versions.cmake.
>
> Thanks,
>
> Sybren
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Alembic upgrade from 1.7.8 to 1.7.12

[Ray Molenkamp]

Windows libs are done!

--Ray

On 2019-11-20 2:26 a.m., Sybren A. Stüvel wrote:
> Dear platform maintainers,
>
> I've just bumped Alembic from 1.7.8 to 1.7.12. This is not a
> needs-to-be-updated-right-now update, but it does add some functionality
> people have been waiting for a long time :-)
>
> Some context: Alembic 1.7.12 introduces a 'DCC FPS' hint, allowing
> Blender to write the scene frame rate to the Alembic file. This will
> make it possible for importers and converters to properly deal with
> situations where 'frame number' is the only reference to time. It should
> prevent issues like described in T55288, where Blender wrote correct
> data to Alembic, but the importing software made bad assumptions because
> it hard-coded 24 FPS.
>
> Currently only the Alembic library is upgraded from 1.7.8 to 1.7.12.
> Writing this new DCC FPS hint will be done in a separate commit once the
> platform libraries have been updated.
>
> Cheers,
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Windows lib changes

[Ray Molenkamp]

fixed make_update.py ! however the mac and windows buildbots seem to have gone 
awol so can't test.

--Ray

On 2019-11-08 4:26 p.m., Brecht Van Lommel wrote:
> The buildbot can probably be fixed by updating the lib folder name in
> build_files/utils/make_update.py.
>
> On Fri, Nov 8, 2019 at 5:16 PM Ray Molenkamp  wrote:
>
>> So... that broke the windows build bot, if anyone with access
>> to the windows bot could check out the libs that be great!
>>
>>  --Ray
>>
>> On 2019-11-08 9:02 a.m., Ray Molenkamp wrote:
>>> All,
>>>
>>> Since the beginning of time we have always used a
>>> weird mix of using the static C runtime for some
>>> parts of blender while using the dynamic runtime
>>> for others.
>>>
>>> No-one exactly remembers how this came to be, but
>>> what was clear that mixing runtimes is 'not great'
>>> and that it eventually would cause issues, which
>>> it recently did [1]
>>>
>>> Today I'm cleaning it up and switching blender
>>> over to the dynamic runtime on windows.
>>>
>>> Now sadly this requires a whole new library set
>>> so if you are building blender on windows you may
>>> have some hiccups and unfortunately a large download.
>>>
>>> Ideally you'd run 'make update' *twice* and it will
>>> sort it self out. (Once to get the updated make.bat
>>> that knows about the new libs, and a second time to
>>> actually grab them)
>>>
>>> However there are some side cases where people
>>> did not follow our building guide and/or systems
>>> where cmake just behaved oddly, so here is a list of
>>> oddities you may run into and how to resolve them.
>>>
>>> 1) I get a build error along the lines of:
>>>
>>> Windows requires pre-compiled libs at:
>> 'c:/blender-git/blender/../lib/win64_vc15'.
>>> Please run make update in the blender source folder to obtain them.
>>>
>>> Solution:
>>>
>>> Do what it says, if "make update" does not work for you, see 2
>>>
>>> 2) I checked out the libraries my self, I don't have SVN
>>> in my path and/or "make update" does not work for me.
>>>
>>> It happens, not everybody is following our building
>>> instructions [2] for various reasons, and some environments
>>> just don't seem to play nice with our scripts.
>>>
>>> Solution:
>>>
>>> You can check out the new set of libraries manually from
>>>
>>> https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64_vc15
>>>
>>> just make sure they and up in the next to the win64_vc14 folder
>>> you currently have and it should work.
>>>
>>> 3) I have a linker error mentioning a RuntimeLibrary mismatch
>>>
>>> These generally come in the form of:
>>>
>>> 'RuntimeLibrary': value 'MTd_StaticRelease' doesn't match value
>> 'MDd_DynamicRelease' in [somefile]
>>> This seems to be coming from CMake not always picking
>>> up on changes in the platform settings.
>>>
>>> Solution:
>>>
>>> Remove your build folder and start a fresh build
>>>
>>> 4) MSVC 2015
>>>
>>> MSVC2015 has been superseded by 2 newer versions both
>>> available for free, 2015 support will be dialed back
>>> to the same level as 32 bit support. We don't test it
>>> nor supply libraries for it anymore, however if you
>>> have your own set of libraries and have patches that
>>> help with vs2015 specific issues you are always
>>> welcome to submit those.
>>>
>>> Solution: Update to vs2017 or vs2019
>>>
>>> 5) I have a branch that has not merged this change yet.
>>>
>>> That's OK, the static vc14 libraries will be available
>>> for some time. However no further updates will be done
>>> to them.
>>>
>>> Special acknowledgments:
>>>
>>> Thanks to @Harleya and @deadpin on chat for helping test
>>> so we could have an as smooth as possible transition to
>>> the new libs.
>>>
>>> [1] https://developer.blender.org/D5387#122165
>>> [2] https://wiki.blender.org/wiki/Building_Blender/Windows
>>>
>>> ___
>>> 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
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Windows lib changes

[Ray Molenkamp]

So... that broke the windows build bot, if anyone with access
to the windows bot could check out the libs that be great!
 
 --Ray

On 2019-11-08 9:02 a.m., Ray Molenkamp wrote:
> All,
>
> Since the beginning of time we have always used a
> weird mix of using the static C runtime for some
> parts of blender while using the dynamic runtime
> for others.
>
> No-one exactly remembers how this came to be, but
> what was clear that mixing runtimes is 'not great'
> and that it eventually would cause issues, which
> it recently did [1]
>
> Today I'm cleaning it up and switching blender
> over to the dynamic runtime on windows.
>
> Now sadly this requires a whole new library set
> so if you are building blender on windows you may
> have some hiccups and unfortunately a large download.
>
> Ideally you'd run 'make update' *twice* and it will
> sort it self out. (Once to get the updated make.bat
> that knows about the new libs, and a second time to
> actually grab them)
>
> However there are some side cases where people
> did not follow our building guide and/or systems
> where cmake just behaved oddly, so here is a list of
> oddities you may run into and how to resolve them.
>
> 1) I get a build error along the lines of:
>
> Windows requires pre-compiled libs at: 
> 'c:/blender-git/blender/../lib/win64_vc15'.
> Please run make update in the blender source folder to obtain them.
>
> Solution:
>
> Do what it says, if "make update" does not work for you, see 2
>
> 2) I checked out the libraries my self, I don't have SVN
> in my path and/or "make update" does not work for me.
>
> It happens, not everybody is following our building
> instructions [2] for various reasons, and some environments
> just don't seem to play nice with our scripts.
>
> Solution:
>
> You can check out the new set of libraries manually from
>
> https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64_vc15
>
> just make sure they and up in the next to the win64_vc14 folder
> you currently have and it should work.
>
> 3) I have a linker error mentioning a RuntimeLibrary mismatch
>
> These generally come in the form of:
>
> 'RuntimeLibrary': value 'MTd_StaticRelease' doesn't match value 
> 'MDd_DynamicRelease' in [somefile]
>
> This seems to be coming from CMake not always picking
> up on changes in the platform settings.
>
> Solution:
>
> Remove your build folder and start a fresh build
>
> 4) MSVC 2015
>
> MSVC2015 has been superseded by 2 newer versions both
> available for free, 2015 support will be dialed back
> to the same level as 32 bit support. We don't test it
> nor supply libraries for it anymore, however if you
> have your own set of libraries and have patches that
> help with vs2015 specific issues you are always
> welcome to submit those.
>
> Solution: Update to vs2017 or vs2019
>
> 5) I have a branch that has not merged this change yet.
>
> That's OK, the static vc14 libraries will be available
> for some time. However no further updates will be done
> to them.
>
> Special acknowledgments:
>
> Thanks to @Harleya and @deadpin on chat for helping test
> so we could have an as smooth as possible transition to
> the new libs.
>
> [1] https://developer.blender.org/D5387#122165
> [2] https://wiki.blender.org/wiki/Building_Blender/Windows
>
> ___
> 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] Windows lib changes

[Ray Molenkamp]

All,

Since the beginning of time we have always used a
weird mix of using the static C runtime for some
parts of blender while using the dynamic runtime
for others.

No-one exactly remembers how this came to be, but
what was clear that mixing runtimes is 'not great'
and that it eventually would cause issues, which
it recently did [1]

Today I'm cleaning it up and switching blender
over to the dynamic runtime on windows.

Now sadly this requires a whole new library set
so if you are building blender on windows you may
have some hiccups and unfortunately a large download.

Ideally you'd run 'make update' *twice* and it will
sort it self out. (Once to get the updated make.bat
that knows about the new libs, and a second time to
actually grab them)

However there are some side cases where people
did not follow our building guide and/or systems
where cmake just behaved oddly, so here is a list of
oddities you may run into and how to resolve them.

1) I get a build error along the lines of:

Windows requires pre-compiled libs at: 
'c:/blender-git/blender/../lib/win64_vc15'.
Please run make update in the blender source folder to obtain them.

Solution:

Do what it says, if "make update" does not work for you, see 2

2) I checked out the libraries my self, I don't have SVN
in my path and/or "make update" does not work for me.

It happens, not everybody is following our building
instructions [2] for various reasons, and some environments
just don't seem to play nice with our scripts.

Solution:

You can check out the new set of libraries manually from

https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64_vc15

just make sure they and up in the next to the win64_vc14 folder
you currently have and it should work.

3) I have a linker error mentioning a RuntimeLibrary mismatch

These generally come in the form of:

'RuntimeLibrary': value 'MTd_StaticRelease' doesn't match value 
'MDd_DynamicRelease' in [somefile]

This seems to be coming from CMake not always picking
up on changes in the platform settings.

Solution:

Remove your build folder and start a fresh build

4) MSVC 2015

MSVC2015 has been superseded by 2 newer versions both
available for free, 2015 support will be dialed back
to the same level as 32 bit support. We don't test it
nor supply libraries for it anymore, however if you
have your own set of libraries and have patches that
help with vs2015 specific issues you are always
welcome to submit those.

Solution: Update to vs2017 or vs2019

5) I have a branch that has not merged this change yet.

That's OK, the static vc14 libraries will be available
for some time. However no further updates will be done
to them.

Special acknowledgments:

Thanks to @Harleya and @deadpin on chat for helping test
so we could have an as smooth as possible transition to
the new libs.

[1] https://developer.blender.org/D5387#122165
[2] https://wiki.blender.org/wiki/Building_Blender/Windows

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

Re: [Bf-committers] Moving to Python-3.8

[Ray Molenkamp]

On 2019-11-08 1:37 a.m., dr. Sybren A. Stüvel wrote:

> Are there any concrete reasons we stick to those particular versions? Or
> is it just a matter of someone taking the time to update them?

I don't think we have official rules about this but
the un-official one I have been using for years is:

Module owners what rely on a dependency can integrate
newer versions and ask for an update of a dep once they
are done on bf-c and the platform devs will take care
of the rest. Previous examples [1][2][3]

That being said the integration *has* to be done by the
module teams, the platform devs just don't/can't know
every single implementation detail of the 30-40 deps we
rely on.

Sometimes we get patches that include lib building
support (like embree) which is appreciated but by no means
required, odds are the platform devs for a platform
are better and quicker at scripting deps than a dev
that has never developed on said platform.

So the barrier for lib updates is a low as I can make it
all you have to do is test the new version works, and ask.

Given we are formalizing lots of things, perhaps now
that module teams are more established we should
assign responsibly for the deps they require to them?

--Ray

[1] https://lists.blender.org/pipermail/bf-committers/2018-December/049691.html
[2] https://lists.blender.org/pipermail/bf-committers/2019-June/050006.html
[3] https://lists.blender.org/pipermail/bf-committers/2019-August/050119.html
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Upgrade Python 3.7.0 to 3.7.4

[Ray Molenkamp]

All,

Took a bit, but the windows libs have been updated, couple of note worthy 
things:

First: After a brief consult with sybren, the site packages have been
updated to the following versions:

IDNA 2.8
CHARDET  3.0.4
URLLIB3  1.25.3
CERTIFI  2019.6.16
REQUESTS 2.22.0
NUMPY    1.17.0

Second : To support running 'make format' without having to be depended
on a system python being installed on windows, the packaging for python
had to be significantly changed. There now is a runnable python in the
lib folder rather than tarballs. 

All tests are still passing, so I'm not expecting a whole lot of problems
however if any do show-up because of this change, please let me know asap.

Third: I left the old python packaging in SVN for now so it will not
disturb any branches dependent on the old packaging method, however,
these old versions will be removed in the future, so be sure to merge
master sooner rather than later if you are working in a branch.

Greetings,
Ray
On 2019-08-02 8:55 a.m., dr. Sybren A. Stüvel wrote:
> Dear platform maintainers,
>
> I've just modified versions.cmake and install_deps.sh to install the
> latest version of Python, namely 3.7.4. Please update the platform
> libraries accordingly.
>
> https://developer.blender.org/rB454daf9b6b87d008e66650927109511f1c1befd2
>
> Kind regards,
>
> Sybren
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.80 Release AHOY

[Ray Molenkamp]

Windows builds are done,

SHA-512 hashes

blender-2.80-windows32.zip 
904FC1682638BA0A28C1F82E050F8C11D9B8AEC4F398FFC692613D3BF09C6AF755E84C2406330F30284EEF64A8BB0E932EC11FB844D7AEA136F1B0434F8B8769
blender-2.80-windows32.msi 
3E0A50EE85AC1B2365711279E94458F24D13DC7E5A62D7657948C608E5806509D4C9CCBA88CB89C5BB7BD9A84E7CDE90C35925C623D53B3554190727263EFA71
blender-2.80-windows64.zip 
C94DEB183589D123A3D4DE34DE7D935CF44386D404E9D907780FF22BE580A2C1865BE4709F9D6AA7B76D0212231FEF817605908DAB66F9CC1FF4778E6A0C5C6A
blender-2.80-windows64.msi 
A5D69E9BC853DDA4A1965D149CBF5CD617DF806DDC8AF4E851B253578CA2B7921629EA1ED1345143C60479992F9DDA1C3A50C88F999AB9C8420BCCF0B0FC2E95

--Ray

On 2019-07-29 8:53 a.m., Brecht Van Lommel wrote:
> Hi all,
>
> We are ready for the final release build for Blender 2.80.
>
> Information for platform maintainers:
>
> - Build from the blender-v2.80-release branch, SHA
> f6cb5f54494e40f0d217c7a1520a14896bd19120
> - Addons revision: 4410bd0a9f82aba3422e737f0fae4a916cf6c0c1
> - Locale revision: a467f38d0c668083ee3774eb1e9491793ff30d05
> - Libraries SVN tag: blender-2.80-release
>
> Suggested name: blender-2.80-.
>
> Tagging will happen soon after all builds are ready.
>
> Thanks,
> Brecht.
> ___
> 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] Blender 2.8x - support and core development goals

[Ray Molenkamp]

Being a windows platform dev this could pretty much be a list called
'things nobody will get exited about' but here's my plans/wish-list
regardless

If I get nothing else, I hope it's this one (2.81):

I think the most important one for stability is having working automated
crash reporting, being able to see the top 10 reasons why people lose work
and proactively fix them should go a long way in improving the end-user
experience.

I Have the client side code for win/linux is in a workable state,
arto will have to take another look at the mac side since I'm pretty
sure I broke that when I merged it from 2.7 to master. Nathan is
looking into the server side of things. (D3576)

Nice to haves (not attached to a release target):

1) I'd like to see the unit tests run nightly on BF infrastructure
(I currently run them nightly on azure, but we cannot run the opengl based
tests on there) but this is something the people at the institute need to work 
on.
(Already on the list in T66306)

2) Cycles unit tests:
Currently the cycles unit tests only test the kernel most appropriate for the
host it runs on, small differences errors between architectures have been
slipping though our test suite. All render tests should run on all kernels
we build. If nobody picks this up I'll have stab at it.
(not yet on the list in T66306, but probably should be there)

Developer experience (not attached to a release target)

1) I'm planning some small tweaks to the build helper scripts on windows
to give developers some features that have been asking for like being
able to specify an absolute path for the build folder. I'm open for
other suggestions/improvements here.

2) Enable JMC for compilers that support it

JMC [1] drastically cuts down the time you spend stepping though boiler plate 
C++
code in the debugger, once master gets unfrozen I'll enable this for debug 
builds
on VS2019.

3) Developer profile.

Not my work, but i'd like to see brechts D5149 land sooner than later, just to 
get
rid of some of the annoyances like buildinfo being on for developers by default
leading to constant rebuilds which leads to less productive developers. (D5149)

4) Rewrite the build instructions for windows.

The wiki could use a refresher, some things can be clarified better, other 
things
can be skipped all together since the build scripts take care of it now-days.

I have been dragging my heels on this.

Libs 2.81:

I'm mostly following here, If you want/need a dep update for your module speak 
up!

1) Python, I heard talk about a python version bump a while ago (but never saw 
the
official request to bump it), also I have to repackage python on windows so
`make format` can use it and we longer have to rely on a system python being
installed, so these things will probably go together.
(not yet on any list I'm aware of)

2) USD will need to be scripted and packaged if sybren wants to get USD into 
2.81, I have
this partially done already, but USD on windows is having an 'unhappy time', 
officially the
windows support is experimental so our success may vary on this. The code 
builds and links
but doesn't work due some plugin registration issues inside USD. I haven't 
found  the time
to debug this yet. (not yet on any list I'm aware of)

3) Removal of 32 bit support.

Finally! (T67184)

Libs Longer term:

I've heard from multiple devs that dealing with deps is a pain, they just 
randomly sprinkle
includes and linker commands until the errors go way, that's a great use of 
their time.

While moving all of blender to a modern target based cmake style may be out of 
reach,
I think we can do this for the deps integration without causing too much 
trouble.
(not yet on any list i'm aware of)

--Ray


[1] 
https://devblogs.microsoft.com/cppblog/announcing-jmc-stepping-in-visual-studio/

On 2019-07-26 12:00 a.m., Dalai Felinto wrote:
> Dear developers,
>
> Which areas would you like to focus on in the next few months? Which
> code improvements, performance, stability, new features in those areas
> would you work on first [1]?
>
> Finally which bigger new features are you confident would make it in
> the 2.81 release, and which are the ones that might happen? These are
> particularly important so we can allocate more time for code review
> early in the release cycle and work together to assess their
> feasibility.
>
> That should empower us to set priorities and keep our ongoing
> development on track. The original goal of a more strict 2-3 month
> release cycle is still on the table, and it is up to us to set dates
> the deliverables. As long as we are working in the right priorities,
> and strive for quality, which specific features land in 2.81 are
> secondary.
>
> I'm away for Siggraph (28-1) so there is no need to rush to reply to this.
>
> [1] - Please update the module page to reflect this -
> https://wiki.blender.org/wiki/Modules /
> https://developer.blender.org/T63725
>
> Best regards,
> Dalai
> ___
> 

Re: [Bf-committers] Blender 2.80 Release Candidate 3 AHOY

[Ray Molenkamp]

Windows builds are done, Dan pointed out we really shouldn't be using MD5 
anymore
so here's the SHA-512 hashes for the files.

blender-2.80rc3-windows64.zip 
4A38C0B1B06E9D658FC178DB0CEFD51D0536056DDC5115863EB6A94D8FF7C0930C5E73EF9F2261F8FDBAAD3568FB5EAAC42F156E6B548B9B4173F4A3B1203A5F
blender-2.80rc3-windows32.zip 
8F86B13CF59ADDDE8B2BED9A4BAB2A43C491BA8E3486CE0B2F4024917BA71C1AE08B6103255F11F17BDFDFF48EBD53D475A595E1599882E25DCB2F130EC2686D

tests results are identical to the earlier RC's

--Ray


On 2019-07-24 8:47 a.m., Brecht Van Lommel wrote:
> Hi all,
>
> We are ready for the third Release Candidate for the Blender 2.80 release.
>
> Information for platform maintainers:
>
> - Build from the blender-v2.80-release branch, SHA
> 507ffee6e1f4a2b2795c7c93cd3f37f4df748ee9
> - Addons revision: f3ee44380d01ab69b2b007409e7d6a9ec143beb2
> - Locale revision: 63f65770e67f38db29f76ac910dd87bd9841b919
> - Libraries SVN tag: blender-2.80-release
>
> Suggested name: blender-2.80rc3-.
>
> Tagging will happen soon after all builds are ready.
>
> Thanks,
> Brecht.
> ___
> 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] Blender 2.80 Release Candidate 2 AHOY

[Ray Molenkamp]

Windows builds are uploaded

26FDFFEB04530C3D2C049DB0EFF7AC27 blender-2.80rc2-windows32.zip
93E91393E031734DD338E240A1C9E5E6 blender-2.80rc2-windows64.zip

Testing situation is identical to rc1.

--Ray


On 7/18/2019 8:58 AM, Brecht Van Lommel wrote:
> Hi all,
>
> We are ready for the second Release Candidate for the Blender 2.80 release.
>
> Information for platform maintainers:
>
> - Build from the blender-v2.80-release branch, SHA
> 38d4483c6a51d70744d5e146dc87f5da8558448d
> - Addons revision: 979298511916b25ec97bb22feb1c06cc9fbc86dd
> - Locale revision: 6625026f62f492dd677f5f29c68b9d70c96fb34b
> - Libraries SVN tag: blender-2.80-release
>
> Suggested name: blender-2.80rc2-.
>
> Put builds to the usual location and let me know when they are ready.
> Tagging will happen soon after all builds are ready.
>
> Thanks,
> Brecht.
> ___
> 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] Blender 2.80 Release Candidate 1 AHOY

[Ray Molenkamp]

After a small consult with sergey, cubins are indeed off for X86
and WITH_CYCLES_CUDA_BINARIES has been manually turned off for
win32 for now.

I struggled with ftp from behind nat, but I think both builds made
it, in-case they didn't I left sergey a link to a  copy on my webhosting.

MD5 for both builds:

E8D4B54EBEFC2ACF93C76560E4A26851  blender-2.80rc1-windows32.zip
F4BA141E119583C5DB520565FF71DA5D  blender-2.80rc1-windows64.zip

Tests:

Win32 fails bmesh_boolean which is a known (T65143) and accepted issue
Win64 had a 100% pass rate.

However

@deadpin on chat correctly pointed out that the object_modifier_array
test while passing really shouldn't (this is for both win64 and win32)

49: Read blend: 
K:/BlenderGit/blender/../lib/tests/modifier_stack/array_test.blend
49:
49: Error: text block not found run_tests.
49:
49: Blender quit
[HANDLER_OUTPUT]
 49/103 Test  #49: object_modifier_array ...
   Passed    4.74 sec
[HANDLER_VERBOSE_OUTPUT]

--Ray

On 7/10/2019 12:30 PM, Ray Molenkamp wrote:
> I hit a snag building win32, it's trying to build cubins and
> failing at it, I have a vague memory of cubins being disabled
> for 32 bit builds? Is this still the case?
>
> --Ray
> On 7/10/2019 10:24 AM, Sergey Sharybin wrote:
>> Correction for the git branch: blender-v2.80-release
>>
>> Sorry for the noise and confusion.
>>
>> On Wed, Jul 10, 2019 at 6:16 PM Sergey Sharybin 
>> wrote:
>>
>>> Hi,
>>>
>>> We are ready for the first Release Candidate for Blender 2.80 release.
>>>
>>> Information for platform maintainers:
>>>
>>> - Build from the blender-2.80-release branch, SHA
>>> 3fe0c32fae20be4146bfa20fe64f56f5716a132b
>>> - Addons revision: f54338c63ba36cbbe83161c0b3d4d2b1aa01c4a9
>>> - Locale revision: 38e501b4d7a37d2db0f48d47bdb07c57f3fb9a0d
>>> - Libraries SVN tag: blender-2.80-release
>>>
>>> Suggested name: blender-2.80rc1-.
>>>
>>> Put builds to usual location and let me know when they are ready.
>>> Tagging will happen soon after all builds are ready.
>>>
>>> Thanks everybody for the hard work!
>>>
>>> --
>>> 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] Blender 2.80 Release Candidate 1 AHOY

[Ray Molenkamp]

I hit a snag building win32, it's trying to build cubins and
failing at it, I have a vague memory of cubins being disabled
for 32 bit builds? Is this still the case?

--Ray
On 7/10/2019 10:24 AM, Sergey Sharybin wrote:
> Correction for the git branch: blender-v2.80-release
>
> Sorry for the noise and confusion.
>
> On Wed, Jul 10, 2019 at 6:16 PM Sergey Sharybin 
> wrote:
>
>> Hi,
>>
>> We are ready for the first Release Candidate for Blender 2.80 release.
>>
>> Information for platform maintainers:
>>
>> - Build from the blender-2.80-release branch, SHA
>> 3fe0c32fae20be4146bfa20fe64f56f5716a132b
>> - Addons revision: f54338c63ba36cbbe83161c0b3d4d2b1aa01c4a9
>> - Locale revision: 38e501b4d7a37d2db0f48d47bdb07c57f3fb9a0d
>> - Libraries SVN tag: blender-2.80-release
>>
>> Suggested name: blender-2.80rc1-.
>>
>> Put builds to usual location and let me know when they are ready.
>> Tagging will happen soon after all builds are ready.
>>
>> Thanks everybody for the hard work!
>>
>> --
>> With best regards, Sergey Sharybin
>>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Libraries update: OpenSubdiv 3.4 RC2

[Ray Molenkamp]

Windows libs has been updated.

--Ray

On 6/27/2019 7:46 AM, Sergey Sharybin wrote:
> Hi,
>
> This is a request for platform maintainers to update OpenSubdiv library to
> 3.4 RC2. All the needed changes are done to versions.cmake.
>
> The update is needed to bring fixes for non-manifold and non-regular
> meshes, which allows us to solve several reports in the tracker.
>
> Unfortunately, the final release is not yet available, but there no much
> changes is expected and we'd better do such rather intrusive changes as
> early as possible.
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Potentially moving from IRC to Blender.Chat

[Ray Molenkamp]

On 5/1/2019 5:18 AM, Pablo Vazquez wrote:
> You still need to create an account on freenode to chat in blendercoders.

You don't, we temporary turned that on a while ago when a botnet was
wreaking havoc on freenode, but in general that option is off and any
user registered or not can join and talk in #blendercoders

--Ray

On 5/1/2019 5:18 AM, Pablo Vazquez wrote:
>> - is wasting space when not logged in (It can be changed to "condensed
>> mode" but only when logged in it apears)
>>
> Compact view can be set to default if enough people agree.
>
>
>> - is slow: [1]
>>
> The version live in production now was right before an improvement that
> speeds up the load/opening of rooms quite substantially, we just need to
> update the docker image.
> https://github.com/RocketChat/Rocket.Chat/pull/13417#issue-251549810
>
>
>> - is big: 4.3 MB for a simple chat app [2]
>>
> I'd trade a couple of MBs for built-in attachments, screen-sharing, video
> conferencing, audio message, email notifications, etc.
>
>
>> - is increasing the barrier to entry. Previously you could just use the
>> freenode web service to chat. Now you need to register for an account
>>
> You still need to create an account on freenode to chat in blendercoders.
> All you need in blender.chat is a Blender ID account which most Blender
> users have made for sites like devtalk, cloud, fund or network.
>
>
>> - has no mobile app for my phone version
>>
> It's available on Android and iOS.
>
>
>> - rocket.chat has 1.9k open issues on github, while IRC is battle-tested
>>
> Maybe you don't know how GitHub issues work? It's a bunch of tasks with
> labels. 355 of those are marked as bugs, some as design, some as feature
> proposals from 2015.
>
>
>> Also consider that there are people with slow phones/slow connections.
>> People who want better UI can always use riot.im, irccloud or any similar
>> service.
>>
> We looked into matrix when we started blender.chat over a year ago and it
> just didn't feel mature enough. Riot looks a lot better now than it did a
> year ago, I wouldn't mind giving it a try if there is people willing to
> help setting it up (rocket chat is literally just pulling a docker image).
> I personally don't mind if it's rocket chat or riot or whatever, I just
> like how much more accessible these apps make it to more people (there's a
> reason why people use Slack, Discord, etc.).
>
> Blender forums used phpBB, but we moved to Discourse.
> blender.org with Typo3 was fine, we moved to Wordpress.
> Remember projects.blender.org? we moved to Phabricator.
> We went from CVS to SVN to git.
>
> Moving *some* communication channels from IRC to something more media
> friendly for a 3D software shouldn't be so shocking.
> ___
> 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] clang-format in master

[Ray Molenkamp]

vc 2017 ships with clang-format 6.0.0, 2019 ships with 7.0.0
judging from the 6.0.0 release notes[1] this should have worked?

Also I don't remember ever seeing that error.

We ship 6.0.1 with our libs, what you can try is, go into

Tools->Options->Text Editor->C/C++->Formatting->General

Near the bottom of that list should be an option to browse
to a custom clang-format, pick the one from the libs folder
(win64_vc14/llvm/bin/clang-format)

does that re-solve the issue for you?

--Ray

[1] 
https://releases.llvm.org/6.0.0/tools/clang/docs/ReleaseNotes.html#clang-format



On 4/18/2019 9:28 AM, Harley Acheson wrote:
> Campbell,
>
> When using Microsoft Visual Studio (Enterprise 2017 15.7.3), it does
> automatically pick up
> that clang is in force. It brings up a dialog box saying that "a
> clang-format file was found
> in your codebase."
>
> However, doing any operations at all it shows that "an Error occurred while
> formatting with
> ClangFormat" with specifics of "YAML:81:21: error: unknown key
> 'IndentPPDirectives'
>
> I read somewhere that "IndentPPDirectives" is relatively new (with LLVM6)
> so perhaps I need
> to update something. No panic here though as I am not in danger of needing
> to submit anything
> right away.
>
> Yes, I can submit this as a bug if preferred.
>
> Cheers, Harley
> ___
> 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] Can not build blender 2.7 branch

[Ray Molenkamp]

Should build now.

--Ray

On 4/9/2019 11:20 AM, wodec wrote:
> System Information
> Operating system: windows 10
> Graphics card: Nvidia Geforce GTX 1050Ti
>
> Short description of error
> Can not build blender 2.7 branch, (windows VS2017 and Cmake 3.14.1 ), compile 
> error (C2220)
>
>
>
> ---
> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
> https://www.avast.com/antivirus
>
> ___
> 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] Blender 2.79 Nightly builds using different Python versions

[Ray Molenkamp]

https://svn.blender.org/svnroot/bf-blender/tags/

--Ray

On 3/15/2019 11:20 AM, Jacob Merrill wrote:
> it would be slick though to saved the SVN timestamp / revision for old
> releases somewhere.
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Error after Updates to developer/git/svn/buildbot

[Ray Molenkamp]

Same issue here,

anonymous usage seems to work

git clone git://git.blender.org/blender.git

works, however authenticated users

git clone g...@git.blender.org:blender.git

fail with the error mentioned earlier

--Ray


On 2/2/2019 10:30 AM, Howard Trickey wrote:
> Happens for me too. git pull from origin/master of blender repository
>
>
> On Sat, Feb 2, 2019 at 12:14 PM Sergey Sharybin 
> wrote:
>
>> Hi,
>>
>>> util.mkdir(p, 0750)
>> AFAIK, this should be 0o750 for Python3. The code seems to be from
>> gitsosis, which we use from an upstream.
>>
>> What is more weird is that for me `git pull` works fine. Does this still
>> happen for you? Which exact repo causes the issue?
>>
>> On Sat, Feb 2, 2019 at 5:15 PM blendergit  wrote:
>>
>>> Hi,
>>>
>>> Not sure if you have completed the update, but today when I try to run
>>> “git pull”, I get this:
>>>
>>> $ git pull
>>> Traceback (most recent call last):
>>>   File "/usr/local/bin/gitosis-serve", line 11, in 
>>> load_entry_point('gitosis==0.2', 'console_scripts',
>> 'gitosis-serve')()
>>>   File
>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
>>> line   487, in load_entry_point
>>> return get_distribution(dist).load_entry_point(group, name)
>>>   File
>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
>>> line   2728, in load_entry_point
>>> return ep.load()
>>>   File
>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
>>> line   2346, in load
>>> return self.resolve()
>>>   File
>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
>>> line   2352, in resolve
>>> module = __import__(self.module_name, fromlist=['__name__'], level=0)
>>>   File "/usr/local/lib/python3.6/site-packages/gitosis/serve.py", line
>> 142
>>> util.mkdir(p, 0750)
>>>  ^
>>> SyntaxError: invalid token
>>> fatal: Could not read from remote repository.
>>>
>>> Please make sure you have the correct access rights
>>> and the repository exists.
>>>
>>> I’m running on Windows 10.
>>>
>>> Regards,
>>> Antonio Vázquez
>>>
>>> De: Dan McGrath
>>> Enviado: sábado, 2 de febrero de 2019 12:45
>>> Para: bf-blender developers
>>> Asunto: [Bf-committers] Updates to developer/git/svn/buildbot
>>>
>>> Hi,
>>>
>>> Just a heads up that today I upgraded the following sites to the latest
>>> 2019Q1 ports in FreeBSD:
>>>
>>>   - developer.blender.org
>>>   - git.blender.org
>>>   - svn.blender.org
>>>   - builder.blender.org
>>>
>>> As well, the Phabricator (developer.b.o) PHP was upgraded from PHP 5.6 to
>>> 7.2. Overall the site seems nice and zippy when doing cached pages, but
>>> otherwise, keep an eye out for horrible stuff!
>>>
>>> Also, if it's good, nice! But if it breaks, it wasn't me that touched
>>> anything, and is all Sergey Sharybin's fault! ><
>>>
>>> At some point the host will go down for a FreeBSD upgrade from 11 to 12.
>>> Probably on Monday or so, I will let you know here.
>>>
>>>
>>> Cheers,
>>>
>>> Dan
>>> ___
>>> 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
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Update openCollada to 1.6.68

[Ray Molenkamp]

done for windows

--Ray

On 12/5/2018 2:54 AM, Gaia Clary wrote:
> Hi, Platform maintainers :)
>
> Please update the subversion repository libraries to OpenCollada 1.6-68
> This allows us to add support for importing Animation clips.
>
> The Release sources recommended by OpenCollada can be found here:
>
> https://s3-us-west-2.amazonaws.com/opencollada-promotion-artifacts/OpenCOLLADA_v1.6.68.zip
>
> Or if you prefer to go with the git repository, the tagged revision is here:
>
>    https://github.com/KhronosGroup/OpenCOLLADA/tree/v1.6.68
>
> The git hash is 6031fa956e1da4bbdd910af3a8f9e924ef0fca7a
>
> Please tell me if anything around the library build needs improvement. I then 
> will forward this to the opencollada people :)
>
> cheers,
> Gaia
> ___
> 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] Metal GPU support

[Ray Molenkamp]

It's up for debate really, I'd prefer not having to maintain 5 different 
versions of all shaders , also there is a fair amount of dynamic glsl being 
generated by blender. so having something that'll take glsl and outputs 
'whatever we want' would be nice.

glslang[1] with spirvcross[2] looked interesting but I haven't spend any time 
with it, so that may or may not be a terrible idea.

--Ray

[1] https://github.com/KhronosGroup/glslang

[2] https://github.com/KhronosGroup/SPIRV-Cross


On 12/4/2018 2:10 PM, Stuart Carnie wrote:
> Ray:
>
> Thank you for the reply. It sounds like there is an interest in supporting
> multiple back-ends, which is exciting.
>
> With regards to the cleanup, it sounds like the current goal is to replace
> any GL calls with GPU_* calls outside the GPU folders. I'd be happy to
> contribute to that cleanup.
>
> Is the desire to support multiple back ends natively, with their own set of
> shaders or to take an approach similar to RA or bgfx (
> https://bkaradzic.github.io/bgfx/overview.html) and use a unified shader
> model. The former is simpler for consumers of the GPU_* APIs, as they only
> need to provide a single set of shaders, but it does mean that offline
> compilation and other optimizations may be limited.
>
> I will also take a look at the thread you shared.
>
> Cheers,
>
> *Stuart Carnie*
>
>
> On Tue, Dec 4, 2018 at 1:14 PM Ray Molenkamp  wrote:
>
>> I'm going to assume RA was build with multiple back-ends in mind, the
>> blender code-base however is an old old code-base, and wasn't really
>> designed to use anything other than openGL.
>> Although we have cleaned it up quite a bit, there are still loads of
>> openGL calls and opengl-isms sprinkled all over the code base.  Before you
>> can add a backend you'd have to deal with the cleanup first.
>>
>> I started a cleanup a couple of months ago to wrap these calls from GL*
>> calls to GPU* calls but due to the speed 2.8 was progressing at this point
>> it was difficult to keep up with the daily changes, or not interfere too
>> much with the eeve progress so put it on hold for a while.
>>
>> To facilitate this cleanup there's the WITH_OPENGL cmake option which will
>> limit the visibility of the opengl headers to pretty much just the BF_GPU
>> module so any code that shouldn't be making any opengl calls will give a
>> nice compiler error.
>>
>> This thread may be of interest to you
>>
>> https://devtalk.blender.org/t/alternative-rendering-backends/830/13
>>
>> --Ray
>>
>> On 12/4/2018 12:14 PM, Stuart Carnie wrote:
>>> Hi Blender 3D developers:
>>>
>>> Given the deprecation and poor support of OpenGL on Apple platforms, I am
>>> curious if there is any interest in my desire to develop Metal GPU
>> support
>>> for Blender 3D?
>>>
>>> I recently implemented Metal support for RetroArch (a cross-platform
>>> emulator front end). Some of the highlights of RA:
>>>
>>> * supports multiple GPU back ends, including GL, Metal, Vulkan, DirectX
>> and
>>> other esoteric APIs
>>> * a complex, shader pipeline for post-processing using a unified shader
>>> system of glsl shaders, some in excess of 20 passes (
>>> https://github.com/libretro/slang-shaders). These are cross compiled to
>>> target APIs such as Metal, Vulkan or DirectX using glslang and
>> SPIRV-cross.
>>> I've had a bit of a peek at the blender 2.8 branch and imagine the place
>> to
>>> start would be the GPU folder. I suspect, given the abstractions, there
>> has
>>> already been some thought into multiple-GPU support and wonder if there
>> is
>>> any public information on this?
>>>
>>> Cheers,
>>>
>>> Stuart
>>>
>>> *Stuart Carnie*
>>> ___
>>> 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
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Metal GPU support

[Ray Molenkamp]

I'm going to assume RA was build with multiple back-ends in mind, the blender 
code-base however is an old old code-base, and wasn't really designed to use 
anything other than openGL.
Although we have cleaned it up quite a bit, there are still loads of openGL 
calls and opengl-isms sprinkled all over the code base.  Before you can add a 
backend you'd have to deal with the cleanup first.

I started a cleanup a couple of months ago to wrap these calls from GL* calls 
to GPU* calls but due to the speed 2.8 was progressing at this point it was 
difficult to keep up with the daily changes, or not interfere too much with the 
eeve progress so put it on hold for a while.

To facilitate this cleanup there's the WITH_OPENGL cmake option which will 
limit the visibility of the opengl headers to pretty much just the BF_GPU 
module so any code that shouldn't be making any opengl calls will give a nice 
compiler error.

This thread may be of interest to you

https://devtalk.blender.org/t/alternative-rendering-backends/830/13

--Ray

On 12/4/2018 12:14 PM, Stuart Carnie wrote:
> Hi Blender 3D developers:
>
> Given the deprecation and poor support of OpenGL on Apple platforms, I am
> curious if there is any interest in my desire to develop Metal GPU support
> for Blender 3D?
>
> I recently implemented Metal support for RetroArch (a cross-platform
> emulator front end). Some of the highlights of RA:
>
> * supports multiple GPU back ends, including GL, Metal, Vulkan, DirectX and
> other esoteric APIs
> * a complex, shader pipeline for post-processing using a unified shader
> system of glsl shaders, some in excess of 20 passes (
> https://github.com/libretro/slang-shaders). These are cross compiled to
> target APIs such as Metal, Vulkan or DirectX using glslang and SPIRV-cross.
>
> I've had a bit of a peek at the blender 2.8 branch and imagine the place to
> start would be the GPU folder. I suspect, given the abstractions, there has
> already been some thought into multiple-GPU support and wonder if there is
> any public information on this?
>
> Cheers,
>
> Stuart
>
> *Stuart Carnie*
> ___
> 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] Blender developers meeting notes - 2018-09-17

[Ray Molenkamp]

you can find the current patch at https://developer.blender.org/D3576

--Ray


On 9/17/2018 1:32 PM, Dalai Felinto wrote:
> Hi,
>
>> The Crashpad patch now works for all platforms. Interested developers are 
>> encouraged
> to test it (...)
>
> Link please? What kind of testing we are looking for? What do you mean by
> good usability?
>
> Thanks,
> Dalai
>
> On Mon, 17 Sep 2018 at 13:52 Brecht Van Lommel 
> wrote:
>
>> Hi all,
>>
>> Here are the notes from today's developer meeting. Next meeting is Monday,
>> 24 September 10:00 CEST (8:00 UTC).
>>
>> 1) New Developers
>>
>> * Welcome to the newest developer at the Blender Institute, Jacques Lucke!
>> He's known for creating Animation Nodes, and will be working on node
>> goodness in Blender. First though is getting used to the Blender C code
>> while helping finish 2.8.
>> * Welcome also to Tobias Johansson, who will be working at the Blender
>> Institute on the Blender Cloud!
>>
>> 2) Blender 2.8
>>
>> * Work continues towards the beta, lots of bugfixes and small improvements
>> this week.
>> * Various tools were updated, including poly build, smooth, randomize and
>> bisect.
>> * Grease pencil received UI tweaks and two important bugfixes related to
>> performance and "exploding" stroke thickness.
>> * The 3D viewport now draws wireframe outlines in ortho mode again.
>> * The Crashpad patch now works for all platforms. Interested developers are
>> encouraged to test it and make sure it has good usability, it would be
>> useful to help stabilizing 2.8.
>>
>> Weekly Reports:
>> * Bastien:
>>
>> https://wiki.blender.org/wiki/User:Mont29/Foundation/2018#Week_261_-_09.2F08_to_09.2F14
>> * Brecht:
>> https://wiki.blender.org/wiki/User:Brecht/Reports/2018#September_10_-_14
>> 
>> * Campbell:
>>
>> http://download.blender.org/ftp/ideasman42/donelist/2018.html#week-291-september-10
>> <
>> http://download.blender.org/ftp/ideasman42/donelist/2018.html#week-288-august-20
>> * Clément:
>>
>> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2018#Week_88_:_10th_-_16th_Sept
>> * Sergey:
>>
>> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2018#Week_88_:_10th_-_16th_Sept
>>
>> <
>> https://wiki.blender.org/wiki/User:Sergey/Foundation/2018#Week_352:_27th_August_-_2nd_September
>> 3) Other Projects
>>
>> * Library upgrades are now complete for all platforms. install_deps.sh on
>> Linux is still failing on some distributions due to OpenEXR, fix is
>> incoming.
>> ___
>> 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] OpenEXR cmake broken Re: Blender developers meeting notes - 2018-09-10

[Ray Molenkamp]

We are aware, The external dependencies build-scripts are using the autotools 
build for linux/mac for
this exact reason, for windows that was not an option, there we use the github 
hash 
0ac2ea34c8f3134148a5df4052e40f155b76f6fb which has 'somewhat' working cmake 
support,
still kinda wonky, but workable.

--Ray


On 9/10/2018 4:01 PM, bju...@ymail.com wrote:
> According to OpenEXR devs ( and my experience as well ) the cmake build of 
> OpenEXR 2.3 is broken for Linux ( possibly windows as well).
>
> OpenEXR devs are aware and noted on Aug 10 they are looking into it.
>
>
> Excerpt below copied from  
> http://lists.nongnu.org/archive/html/openexr-devel/2018-08/msg2.html  
>
> Justin Jones
>
> --
>
> El 10/08/18 a las 17:38, Francois Chardavoine escribió:
>> Just in time for Siggraph, we're excited to announce that OpenEXR 2.3
>> has been released and is available for download.
>>
> Congratulations.  Now for the sad part:
>
> CMake build is completely broken on Linux at least ( Windows probably
> too ).  IlmBase compiles the tables only and exits without compiling
> anything else.
> Building with bootstrap/configure works on Linux for IlmBase.
>
> CMake build is also broken for OpenEXR.  In that case, it does not find
> IlmBase even when -DILMBASE_PACKAGE_PREFIX is used.  Result: half.h,
> ImathInt64.h, etc cannot be found and nothing gets built.
> Building with bootstrap/configure works on Linux for OpenEXR.
>
> ___
> 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] hair_object Branch

[Ray Molenkamp]

The libraries for master/2.8 have been updated to newer versions, to build 
older branches
you'll need to check out libraries from around the same time the last commit 
happened
in that branch, rev62101 will probably do it for you.

--Ray

On 9/9/2018 5:36 AM, Erick Blender wrote:
> Hello Lukas,
>
> I was trying to build your branch in windows 7 gtx 550ti, i m getting build
> errors, here is a complete log file http://pasteall.org/1206714
> Is there some extra lib that you have and they are not in Blender 2.8?
>
>
> Thanks for your answers :)
> ___
> 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] Windows lib update / merge issues to 2.8

[Ray Molenkamp]

All,

I just finished the windows lib update and kicked the 2.79 build bots, all 
seems OK.
There were a couple of cmake changes needed to adjust for some version changes 
here
and there, however I was unable to merge master to 2.8 due to some merge 
conflicts
in unrelated commits. Once master merges 2.8 should also build without problems

If there's any issues or problems, let me know and I'll resolve them.

--Ray

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

[Bf-committers] git warning?

[Ray Molenkamp]

All,

Not sure who to poke for this, but since a few days when committing through git 
push

git it now spits back a python related warning/error

k:\BlenderGit\blender>git push
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 696 bytes | 696.00 KiB/s, done.
Total 6 (delta 5), reused 0 (delta 0)
remote: env: python2: No such file or directory
To git.blender.org:blender.git
   b6b6eab6ae9..2349273ade5  master -> master

The commits still go through, anyhow, someone should probably look at that?

--Ray





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

Re: [Bf-committers] Blender Compile Error

[Ray Molenkamp]

pasteall.org is kinda  terrible for windows build logs though, since it eats 
all the forward slashes,
so you'd better use any of the other paste sites out there for those

--Ray

On 8/11/2018 2:32 PM, Sergey Sharybin wrote:
> Hi,
>
> Don't think you can attach pictures in this mailing list. It is also more
> helpful to see error messages as plain text (that how they are reported in
> the first place ;).
>
> Anyway, to share text snippets, screenshots, .blend files you can use
> pasteall.org. Or, alternatively, plain-text only hastebin.com. Send link
> here and we will have a look.
>
> That being said, i did not see visual studio ever installed incorrectly,
> unless you pull you computer power plug out for the socket during install :)
>
> On Sat, Aug 11, 2018 at 9:28 PM Ágoston Princz 
> wrote:
>
>> Hi Blender Developers
>>
>> I'm not sure that is the right place to send message like this.
>> If it is the case, please tell me where to ask about compile errors.
>>
>> Other case: I had that error message (attached picture).
>> Is it possible that Visual Studio Community Version was installed
>> incorrectly?
>>
>> Thansk a lot!
>>
>> --
>> Ágoston Princz
>> ___
>> 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] Blosc 1.8.1 Re: Library updates for Blender 2.8

[Ray Molenkamp]

On 8/8/2018 1:01 PM, bju...@ymail.com wrote:
>  Blosc is currently blocking a full build using recent versions of gcc on 
> Linux. Upgrading by two revisions (to 1.8.1 I believe ) addresses the issue 
> directly.
It's currently tagged for an update to 1.14.3

> This issue may have been what kicked off the library update review? 
It's really not, the review had been on the schedule for quite a while now, but 
an ancient compiler on windows was blocking some of the updates.
> It would be a pity if it was the last to be updated.
It will be don't worry.

--Ray
> I am away from my build machine so please forgive me if the change has 
> already been made.
>
> Justin Jones
>
> On August 8, 2018 9:54:58 AM MDT, Brecht Van Lommel 
>  wrote:
>> Hi all,
>>
>> Regarding how to get this moving further, I had a quick talk with
>> Sergey.
>> To avoid the Linux part being a bottleneck, I suggest to update the
>> Windows
>> and macOS libraries as soon as they are ready, and commit the build
>> environment CMake changes alongside them. It's not a big deal if the
>> platform versions are out of sync for a bit, and Sergey can do the
>> corresponding updates for Linux when he has time.
>>
>> So Ray and Arto can just coordinate committing these changes amongst
>> themselves. If any C/C++ code needs to change we can use #ifdef's,
>> which we
>> want anyway in case Linux users are compiling against different library
>> versions.
>>
>> Thanks,
>> Brecht.
>>
>> On Sat, Aug 4, 2018 at 9:01 PM Bastien Montagne 
>> wrote:
>>
>>> Don’t think we are in urgent hurry here, we can give it a few more
>> weeks
>>> and see whether 3.7.1 emerges in time for us (would say dead line for
>>> libs update would be end of September?)
>>>
>>>
>>> On 03/08/2018 10:57, Sergey Sharybin wrote:
 One thing which is raising my attention in 3.7.1 release log is:

 - Fixed a performance regression for reading streams with tarfile.

 Also, 3.7.1 is planned to be released soon-ish? Their original plan
 actually mentions July, not sure what is the updated planning. Are
>> we
 really in a hurry for this update?

 On Fri, Aug 3, 2018 at 10:46 AM Sybren A. Stüvel 
>>> wrote:
> On 23/07/2018 19:43, Brecht Van Lommel wrote:
>> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so
>> with
>> bugfixes?)
> Let's go to 3.7.0, unless somebody already knows of actual bugs
>> that'll
> influence our use.
>
> Sybren
>
> ___
> 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
> ___
> 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] Library updates for Blender 2.8

[Ray Molenkamp]

We'll get going on this then, there's one lib I'd like some clarification on
arto requested boost 1.66 on irc, not a problem on windows (I'd welcome an
updated version, but do not require it), but how are the linux guys feeling
about bumping the boost version?

--Ray


On 8/8/2018 9:54 AM, Brecht Van Lommel wrote:
> Hi all,
>
> Regarding how to get this moving further, I had a quick talk with Sergey.
> To avoid the Linux part being a bottleneck, I suggest to update the Windows
> and macOS libraries as soon as they are ready, and commit the build
> environment CMake changes alongside them. It's not a big deal if the
> platform versions are out of sync for a bit, and Sergey can do the
> corresponding updates for Linux when he has time.
>
> So Ray and Arto can just coordinate committing these changes amongst
> themselves. If any C/C++ code needs to change we can use #ifdef's, which we
> want anyway in case Linux users are compiling against different library
> versions.
>
> Thanks,
> Brecht.
>
> On Sat, Aug 4, 2018 at 9:01 PM Bastien Montagne 
> wrote:
>
>> Don’t think we are in urgent hurry here, we can give it a few more weeks
>> and see whether 3.7.1 emerges in time for us (would say dead line for
>> libs update would be end of September?)
>>
>>
>> On 03/08/2018 10:57, Sergey Sharybin wrote:
>>> One thing which is raising my attention in 3.7.1 release log is:
>>>
>>> - Fixed a performance regression for reading streams with tarfile.
>>>
>>> Also, 3.7.1 is planned to be released soon-ish? Their original plan
>>> actually mentions July, not sure what is the updated planning. Are we
>>> really in a hurry for this update?
>>>
>>> On Fri, Aug 3, 2018 at 10:46 AM Sybren A. Stüvel 
>> wrote:
 On 23/07/2018 19:43, Brecht Van Lommel wrote:
> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with
> bugfixes?)
 Let's go to 3.7.0, unless somebody already knows of actual bugs that'll
 influence our use.

 Sybren

 ___
 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

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

Re: [Bf-committers] Library updates for Blender 2.8

[Ray Molenkamp]

see inline comments


On 7/26/2018 10:21 AM, Brecht Van Lommel wrote:
> I think it would be great to have all these libraries updated, especially
> the ones with CVEs.
>
> * Blosc: definitely need to upgrade one to fix GCC build issues
I  marked the upgrade to latest, the minimum we need is 1.8.1 which already 2+ 
years old
seems silly to upgrade to an already ancient version.

> * clew/cuew: I wonder if we even need OpenCL/CUDA support in OpenSubdiv,
> maybe OpenGL is enough..
unsure, sergey would probably know better here, cuda will be problematic either 
way
with the fighting between nvcc and the msvc compiler version that it may or may 
not
like.  it's currently disabled because of that and I don't think anyone noticed?

> * flexbison/schroendinger/lapack: seems fine to remove
Marked for removal
> * openjpeg: don't think there is a good reason to have it in extern/
> anymore, would be happy to see patch to remove it from there
I have brought this up in the past, and sergey seemed very passionate about 
keeping
it there.


>
> I guess most of these are relatively easy with a tweak to versions.cmake,
> not sure how difficult it is on Linux.
Relativity easy , we just need to pay attention to that when we change a lib we 
also
need to rebuild the libs upstream from it even if their version hasn't changed
(we've run into some weird oiio issues in the past due to a libpng upgrade)

just follow this 'easy' chart and it'll be fine!

http://www.lazydodo.com/tmp/blender_externals.png

--Ray
>
> On Mon, Jul 23, 2018 at 9:54 PM Ray Molenkamp  wrote:
>
>> There's quite a few libraries we build for the various platforms
>> (57 by the last count) and it's not always clear who the module
>> owner is and who is supposed to ask for newer versions of certain
>> libs.
>>
>> I took a quick survey of the versions we use and the latest versions
>> available. (based on build_files\build_environment\cmake\versions.cmake)
>>
>>
>> https://docs.google.com/spreadsheets/d/e/2PACX-1vRnu75FDmw8NvbJiH9hjrGNBvrwXU9ocWWMCWZY0ISwcfLOnL7Ep1z67Y5FpN_TaI0QRwbPR2KmrQie/pubhtml?gid=0=true
>>
>> (or in case the email ruins the long link: https://tinyurl.com/y9st4fyt )
>>
>> There are several libs with known CVE's, personally I would prefer
>> to upgrade those to the latest versions (most seem low risk upgrades)
>> but for everything else I really have no strong opinion.
>>
>> Any module owner that wants edit rights, please poke me (email/irc) and
>> I'll get you an editable link.
>>
>> --Ray
>>
>>
>> On 7/23/2018 11:43 AM, Brecht Van Lommel wrote:
>>> Hi all,
>>>
>>> It's been a while since we updated libraries, and with the upgrade to
>>> Visual Studio 2017 this has now become easier on Windows as well. Since
>> the
>>> platform maintainers have time now to do updates, let's try to get this
>> in
>>> motion.
>>>
>>> Some of the latest library versions need C++11, I also propose we require
>>> C++11 in master. This mostly involves removing the WITH_CXX1 option and
>>> code cleanups for STL data types compatibility.
>>>
>>> For libraries, these are the ones I know of. Let us know if any other
>>> library updates are needed.
>>>
>>> * OSL, LLVM, OIIO: so we no longer need a really old LLVM version.
>>> https://developer.blender.org/D3398
>>> https://developer.blender.org/D2915
>>>
>>> * OpenVDB 5.1.0: so we can read files written by other applications that
>>> have OpenVDB 5.x.
>>>
>>> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with
>>> bugfixes?)
>>>
>>> * OpenSubdiv: this will need to include a number of Sergey's bugfixes,
>> the
>>> revision needed is not known (or doesn't exist) yet.
>>>
>>> Thanks,
>>> Brecht.
>>> ___
>>> 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

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

Re: [Bf-committers] Library updates for Blender 2.8

[Ray Molenkamp]

Currently we're only shipping idiff since the unit tests need it, we could add 
the other tools
however since we build for blender they are all statically linked, so just 
oiiotool would be
12 megs, while the whole set of binaries would be 45. not sure we want to add 
this much
dead weight to the libs?

--Ray

On 7/24/2018 12:36 AM, Stefan Werner wrote:
> While not directly applicable to Blender, would it be any trouble to include 
> oiiotool.exe in the Windows binaries? There was just someone asking for 
> binaries on the oiio mailing list:
> http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2018-July/001254.html
>  
> <http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2018-July/001254.html>
>
> -Stefan
>
>> On 23. Jul 2018, at 21:53, Ray Molenkamp  wrote:
>>
>> There's quite a few libraries we build for the various platforms
>> (57 by the last count) and it's not always clear who the module
>> owner is and who is supposed to ask for newer versions of certain
>> libs. 
>>
>> I took a quick survey of the versions we use and the latest versions
>> available. (based on build_files\build_environment\cmake\versions.cmake)
>>
>> https://docs.google.com/spreadsheets/d/e/2PACX-1vRnu75FDmw8NvbJiH9hjrGNBvrwXU9ocWWMCWZY0ISwcfLOnL7Ep1z67Y5FpN_TaI0QRwbPR2KmrQie/pubhtml?gid=0=true
>>
>> (or in case the email ruins the long link: https://tinyurl.com/y9st4fyt )
>>
>> There are several libs with known CVE's, personally I would prefer
>> to upgrade those to the latest versions (most seem low risk upgrades)
>> but for everything else I really have no strong opinion.
>>
>> Any module owner that wants edit rights, please poke me (email/irc) and
>> I'll get you an editable link.
>>
>> --Ray
>>
>>
>> On 7/23/2018 11:43 AM, Brecht Van Lommel wrote:
>>> Hi all,
>>>
>>> It's been a while since we updated libraries, and with the upgrade to
>>> Visual Studio 2017 this has now become easier on Windows as well. Since the
>>> platform maintainers have time now to do updates, let's try to get this in
>>> motion.
>>>
>>> Some of the latest library versions need C++11, I also propose we require
>>> C++11 in master. This mostly involves removing the WITH_CXX1 option and
>>> code cleanups for STL data types compatibility.
>>>
>>> For libraries, these are the ones I know of. Let us know if any other
>>> library updates are needed.
>>>
>>> * OSL, LLVM, OIIO: so we no longer need a really old LLVM version.
>>> https://developer.blender.org/D3398
>>> https://developer.blender.org/D2915
>>>
>>> * OpenVDB 5.1.0: so we can read files written by other applications that
>>> have OpenVDB 5.x.
>>>
>>> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with
>>> bugfixes?)
>>>
>>> * OpenSubdiv: this will need to include a number of Sergey's bugfixes, the
>>> revision needed is not known (or doesn't exist) yet.
>>>
>>> Thanks,
>>> Brecht.
>>> ___
>>> 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

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

Re: [Bf-committers] Library updates for Blender 2.8

[Ray Molenkamp]

There's quite a few libraries we build for the various platforms
(57 by the last count) and it's not always clear who the module
owner is and who is supposed to ask for newer versions of certain
libs. 

I took a quick survey of the versions we use and the latest versions
available. (based on build_files\build_environment\cmake\versions.cmake)

https://docs.google.com/spreadsheets/d/e/2PACX-1vRnu75FDmw8NvbJiH9hjrGNBvrwXU9ocWWMCWZY0ISwcfLOnL7Ep1z67Y5FpN_TaI0QRwbPR2KmrQie/pubhtml?gid=0=true

(or in case the email ruins the long link: https://tinyurl.com/y9st4fyt )

There are several libs with known CVE's, personally I would prefer
to upgrade those to the latest versions (most seem low risk upgrades)
but for everything else I really have no strong opinion.

Any module owner that wants edit rights, please poke me (email/irc) and
I'll get you an editable link.

--Ray


On 7/23/2018 11:43 AM, Brecht Van Lommel wrote:
> Hi all,
>
> It's been a while since we updated libraries, and with the upgrade to
> Visual Studio 2017 this has now become easier on Windows as well. Since the
> platform maintainers have time now to do updates, let's try to get this in
> motion.
>
> Some of the latest library versions need C++11, I also propose we require
> C++11 in master. This mostly involves removing the WITH_CXX1 option and
> code cleanups for STL data types compatibility.
>
> For libraries, these are the ones I know of. Let us know if any other
> library updates are needed.
>
> * OSL, LLVM, OIIO: so we no longer need a really old LLVM version.
> https://developer.blender.org/D3398
> https://developer.blender.org/D2915
>
> * OpenVDB 5.1.0: so we can read files written by other applications that
> have OpenVDB 5.x.
>
> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with
> bugfixes?)
>
> * OpenSubdiv: this will need to include a number of Sergey's bugfixes, the
> revision needed is not known (or doesn't exist) yet.
>
> Thanks,
> Brecht.
> ___
> 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] End of MSVC 2013 support.

[Ray Molenkamp]

I just removed msvc2013 support from make.bat, msvc2017 is now the preferred 
compiler
on windows.

Before I remove the vc12 libs from svn, do we want to tag them for historical 
purposes?
(They have a newer python/numpy/requests/libjpeg than the tagged 2.79 libs)

Also now that msvc2013 is out of the way, I'm open for doing some library 
upgrades,
module owners feel to request them via this mailing list.

If there's any issues feel free to poke me.

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

Re: [Bf-committers] 2.8 bugs on the tracker.

[Ray Molenkamp]

On 7/2/2018 8:03 PM, Ray Molenkamp wrote:
> T55706 is a less clear duplicate of T52523 (and T55706 has a not so useful
> title, so even if they did search it wouldn't have been found)
sorry got my tickets mixed up here, it's a duplicate of T55695.
--Ray
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] 2.8 bugs on the tracker.

[Ray Molenkamp]

All,

Since the tracker has now been opened for 2.8 crashes tickets have been
coming in steadily, I'm unsure how to triage these though, previously
it was easy, just the studio tickets were allowed and they placed them
on the 2.8 work board them selves.

Is tagging the end user tickets with just blender 2.8 enough or do they
need to be placed on some work-board as well?

Also the quality of the tickets is sometimes... not great... T55704 for
instance. I can't seem to repro it,odds are it's hardware dependent however
none of the system information has been included, and the broken version
is just listed as '2.8'

T55705 is a clear duplicate of T55696, so users don't tend to search
before posting.

T55706 is a less clear duplicate of T52523 (and T55706 has a not so useful
title, so even if they did search it wouldn't have been found)

I think we need to offer some better guidance here. maybe have pablo
do a video version of :

https://wiki.blender.org/wiki/Process/Bug_Reports

He seems to reach *A LOT* of people with his videos (just an idea,
don't feel pressured into this pablo)  

I'll happily triage as long as my spare time allows for it, but the
quality of the tickets *has* to improve or this will turn into a
rather tedious task that nobody will have any interest in doing.
 
--Ray



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

Re: [Bf-committers] devtalk.

[Ray Molenkamp]

I think this is a case of what was envisioned and what is actually
happening on devtalk currently being a tiny bit out of whack.

Devs getting feedback on specific topics is great! a wall of
'Hey devs, lets vote! left or right mouse button!',  'when is
feature X finially finished?' and 'lets change blenders version
number!' not quite as much.

--Ray


On 6/1/2018 2:29 PM, Brecht Van Lommel wrote:
> I think it can work if we make it so developers start topics to request
> feedback on features they are working on. For example one topic for
> shortcut key changes, one for collections, etc. Then we can strictly
> moderate it, close topics when a project is done and keep the number of
> topics under control to avoid overpowering the other posts.
>
> If we let everyone make topics about whatever it's always going to be
> difficult to manage, regardless if we do it on devtalk or another forum.
>
> On Fri, Jun 1, 2018 at 8:10 PM, Ray Molenkamp  wrote:
>
>> All,
>>
>> As I understood devtalk was setup as a dev 2 dev support site, I'm kinda
>> confused we invited end users to 'join the conversation' on it now, as
>> they are putting feature requests all over the place, last night the
>> blender development forum was 80+% feature requests on the first page.
>> kinda ruining the signal to noise ratio. Since then someone came by and
>> moved them all to the code-quest section. Also a banner has been put up
>> mentioning the site is not for feature requests. but still, users do what
>> user do...
>>
>> While I do see value in gathering user-feedback, it's not very hard to
>> imagine that the line between feedback and feature requests is arbitrary
>> at the best of times.
>>
>> Especially with all the changes currently in 2.8, it's also easy to see
>> ahead of time that the discussion would be 'heated' at times, devtalk
>> pretty much coasted by with little to no moderation.
>>
>> Given the response so far, it's clear users are screaming for an outlet
>> to share their ideas/opinions/and feature requests.
>>
>> The question is, was devtalk really the best venue for this experiment?
>> couldn't we just have spun up another discourse instance?
>>
>> --Ray
>> ___
>> 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

[Bf-committers] devtalk.

[Ray Molenkamp]

All,

As I understood devtalk was setup as a dev 2 dev support site, I'm kinda
confused we invited end users to 'join the conversation' on it now, as
they are putting feature requests all over the place, last night the
blender development forum was 80+% feature requests on the first page.
kinda ruining the signal to noise ratio. Since then someone came by and
moved them all to the code-quest section. Also a banner has been put up
mentioning the site is not for feature requests. but still, users do what
user do...

While I do see value in gathering user-feedback, it's not very hard to
imagine that the line between feedback and feature requests is arbitrary
at the best of times.

Especially with all the changes currently in 2.8, it's also easy to see
ahead of time that the discussion would be 'heated' at times, devtalk
pretty much coasted by with little to no moderation.

Given the response so far, it's clear users are screaming for an outlet
to share their ideas/opinions/and feature requests.

The question is, was devtalk really the best venue for this experiment?
couldn't we just have spun up another discourse instance?

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

Re: [Bf-committers] Compiling and running 2.8

[Ray Molenkamp]

You re-used a master build folder for 2.8, given some of our defaults in cmake 
have changed

you can't do that. delete your build folder and you'll be fine.

--Ray


On 5/2/2018 7:55 AM, Christian Hubert wrote:
> Hi,
>
>  
>
> I'm trying to setup my dev env for Blender 2.8 but I fail to do it (355
> errors).
>
>  
>
> The output is the following, building the INSTALL project (beginning of the
> output) :
>
>  
>
> 1>-- Build started: Project: ZERO_CHECK, Configuration: Debug x64 --
>
> 1>Checking Build System
>
> 1>CMake is re-running because
> E:/blender-git-28/build_windows_Full_x64_vc15_Release/CMakeFiles/generate.st
> amp is out-of-date.
>
> 1>  the file 'E:/blender-git-28/blender/CMakeLists.txt'
>
> 1>  is newer than
> 'E:/blender-git-28/build_windows_Full_x64_vc15_Release/CMakeFiles/generate.s
> tamp.depend'
>
> 1>  result='-1'
>
> 1>CMake Error at CMakeLists.txt:584 (message):
>
> 1>  WITH_AUDASPACE requires WITH_CXX11
>
> 1>
>
> 1>
>
> 1>-- Configuring incomplete, errors occurred!
>
> 1>See also
> "E:/blender-git-28/build_windows_Full_x64_vc15_Release/CMakeFiles/CMakeOutpu
> t.log".
>
> 1>CMake Configure step failed.  Build files cannot be regenerated correctly.
> Attempting to stop IDE build.
>
> 1>G:\Programs\Microsoft Visual
> Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.target
> s(171,5): error MSB6006: "cmd.exe" exited with code -1073741819.
>
> 1>Done building project "ZERO_CHECK.vcxproj" -- FAILED.
>
>  
>
> What I've done :
>
>  
>
> cd C:\blender-git-28
>
> git clone git://git.blender.org/blender.git
>
> cd blender
>
> git submodule update --init --recursive
>
> git submodule foreach git checkout master
>
> git submodule foreach git pull --rebase origin master
>
> cd C:\blender-git-28
>
> svn checkout https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64_vc14
> lib/win64_vc14
> cd C:\blender-git\blender
> make full 2017
>
>  
>
> and
>
>  
>
> git checkout blender2.8
>
>  
>
>  
>
> What am I missing?
>
>  
>
> Kind regards
>
> Christian
>
>  
>
>  
>
> ___
> 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] Building Blender

[Ray Molenkamp]

Two options here

1) You could have used our make.bat like I previously suggested which would 
have done this step for you.

2) You could also have done this step manually as documented in the 'Building 
from within the Visual Studio IDE'
section of our build instructions [1].

we like to make building blender as easy as possible on windows, we pointed you 
to both of these resources
to in previous emails, but if you are not going to listen to advise, building 
is indeed going to be harder than it
needs to be.

[1] https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows

--Ray

On 5/1/2018 8:04 AM, John Emmas wrote:
> Oops, I just noticed this from my previous post...
>
>>
>>  (if you built with CMake: 'install' target may have not been built)
>>
>
> After building everything, was I supposed to run an installer of some sort?  
> I simply copied all the built EXE's and DLL's into a common folder and hoped 
> for the best.!
>
> John
> ___
> 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] Building Blender

[Ray Molenkamp]

-Sorry for the late response, I'm currently traveling so connectivity is spotty 
at best.

you should be able to make a build with 2015 given 3 conditions are met

1) you have msvc 2015 update 3 or higher

2 You have a full set of our libs in the right place

3) you run 'make full 2015 x64' in the blender source folder.

--Ray


On 4/30/2018 7:09 AM, John Emmas wrote:
> I (almost) managed to build Blender with VS2015 at my first attempt !!
>
> The main problem is that when compiling some of the modules, I see this 
> output :-
>
>       #error "Cannot find pointer size"
>
> which is coming from this section in 'atomic_ops_utils.h' :-
>
>   #if defined(__SIZEOF_POINTER__)
>   #  define LG_SIZEOF_PTR __SIZEOF_POINTER__
>   #elif defined(UINTPTR_MAX)
>   #  if (UINTPTR_MAX == 0x)
>   #    define LG_SIZEOF_PTR 4
>   #  elif (UINTPTR_MAX == 0x)
>   #    define LG_SIZEOF_PTR 8
>   #  endif
>   #elif defined(__WORDSIZE)  /* Fallback for older glibc and cpp */
>   #  if (__WORDSIZE == 32)
>   #    define LG_SIZEOF_PTR 4
>   #  elif (__WORDSIZE == 64)
>   #    define LG_SIZEOF_PTR 8
>   #  endif
>   #endif
>
>   #ifndef LG_SIZEOF_PTR
>   #  error "Cannot find pointer size"
>   #endif
>
> So I'm guessing that neither __SIZEOF_POINTER__ nor UNITPTR_MAX nor 
> __WORDSIZE are defined anywhere.  Could this be a missing #include maybe?  I 
> assume other devs are building Blender successfully with VS2015?
>
> John
> ___
> 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] Building Blender

[Ray Molenkamp]

Sometimes the svn server randomly quits, i've never heard about it randomly 
stalling though, i'd probably interrupt the process at this point.

to recover run 'svn cleanup' and 'svn update' to continue from the point it got 
lost.

--Ray


On 4/29/2018 12:05 PM, John Emmas wrote:
> On 29/04/2018 15:27, Ray Molenkamp wrote:
>> the libs are a couple of gigabytes and having to do it twice is sometimes 
>> problematic
>>
>
> Thanks Ray,
>
> This might seem like a dumb question but can the subversion modules be 
> downloaded incrementally somehow?  I installed a proper copy of subversion 
> and began my download.  It downloaded about 1.2GB and then just stopped... ;-(
>
> Nothing's downloaded for the past 15 minutes so I might need to try again 
> tomorrow.
>
> John
> ___
> 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] Building Blender

[Ray Molenkamp]

follow the wiki, use regular svn. also just to be sure, you are trying to check 
out the libs for a 32bit build with msvc2015/2017.
if that's what your plan was, that's alright,however if you were planning to 
build a 64 bit build (recommended) check out win64_vc14
instead of windows_vc14. the libs are a couple of gigabytes and having to do it 
twice is sometimes problematic for people on
metered connections, so be sure to pick the right ones.

--Ray

On 4/29/2018 7:19 AM, John Emmas wrote:
> On 29/04/2018 11:41, John Emmas wrote:
>>
>> I uninstalled SVN a long time ago so I guess I'll need to find it again.
>>
>
> Okay...  I realised why SVN isn't installed here any more (it's because 
> TortoiseGit can also handle SVN repos).
>
> So I tried cloning, like so:-
>
>     git.exe svn clone 
> "https://svn.blender.org/svnroot/bf-blender/trunk/lib/windows_vc14; 
> "F:\Test\lib\windows_vc14" -T trunk -b branches -t tags
>
> and I see these messages:-
>
>     Initialized empty Git repository in F:/Test/lib/windows_vc14/.git/
>     Using higher level of URL: 
> https://svn.blender.org/svnroot/bf-blender/trunk/lib/windows_vc14 => 
> https://svn.blender.org/svnroot/bf-blender
>     W: Ignoring error from SVN, path probably does not exist: (160013): 
> Filesystem has no item: File not found: revision 100, path 
> '/trunk/lib/windows_vc14'
>     W: Do not be alarmed at the above message git-svn is just searching 
> aggressively for old history.
>     This may take a while on large repositories
>
> For a few minutes it seems as if things are happening but eventually it fails 
> to fetch anything from 'trunk/lib/windows_vc14', giving me this error:-
>
>     Can't create session: Unable to connect to a repository at URL 
> 'https://svn.blender.org/svnroot/bf-blender'
>     : Error running context: Software caused connection abort at 
> /mingw32/share/perl5/site_perl/Git/SVN.pm line 184.
>
> Any ideas anyone..?
>
> John
>
> ___
> 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] MSBuild problems with ZERO_CHECK project

[Ray Molenkamp]

Given lite builds, perhaps it can't find nvcc? check your cmakecache.txt to see 
if it's pointing to the right executable.

if that doesn't do the trick, change the logging level of the msbuild commands 
inside make.bat from minimal to diagnostic and see if that sheds more light on 
the actual error.

--Ray


On 4/7/2018 9:22 AM, The Simple Carnival wrote:
> Hello --
>
> I recently reinstalled Windows and am trying to compile Blender 2.78c, which 
> I was able to do with my previous Windows installation. I suspect there is a 
> CMake issue, but I'm not sure exactly how to address it.
>
> I'm running into problems when trying to create the Blender Release version. 
> (I can create the Lite version without problems.) Specifically, I'll use the 
> following command...
>
> c:\blender-git\blender>make release
>
> ...and then I will quickly receive this error:
>
> The system cannot find the path specified.
> C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(170,5): 
> error MSB6006: "cmd.exe" exited with code 3. 
> [C:\blender-git\build_windows_Release_x64_vc12_Release\ZERO_CHECK.vcxproj]
>
> Line 170 in the Microsoft.CppCommon.targets file is this:
>
>     
>   Sources ="@(CustomBuild)"
>   BuildSuffix ="$(_BuildSuffix)"
>
>   TrackerLogDirectory ="%(CustomBuild.TrackerLogDirectory)"
>   MinimalRebuildFromTracking ="%(CustomBuild.MinimalRebuildFromTracking)"
>
>   TLogReadFiles ="@(CustomBuildTLogReadFiles)"
>   TLogWriteFiles ="@(CustomBuildTLogWriteFiles)"
>   TrackFileAccess ="$(TrackFileAccess)"
>   ToolArchitecture ="$(CustomBuildToolArchitecture)"
>   TrackerFrameworkPath ="$(CustomBuildTrackerFrameworkPath)"
>   TrackerSdkPath ="$(CustomBuildTrackerSdkPath)"
>
>   AcceptableNonZeroExitCodes ="%(CustomBuild.AcceptableNonZeroExitCodes)"
>   >
>     
>
>
> One of those paths is apparently bad, but I'm not sure which...nor have I 
> been able to figure out how to print that information from MSBuild.
>
> I temporarily replaced the entire target where that CustomBuild appears with 
> some junk code:
>
>   
>       
>   
>
> I can't see the message text in the console window, but I was at least able 
> to build the Blender release version successfully.
>
> Although this "fix" worked, it's obviously not addressing the root problem. 
> Any ideas on what's going on here, and how I can get my Blender build files 
> to compile without this workaround?
>
> Thanks!
>
> Jeff Boller
> http://www.sundriftproductions.com
>
>
> ___
> 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