Overall there seems to be very little consideration for other platforms and various arbitrary changes.

joining the test party

still not OK for general use.

Update to 16.8.

I'll admit, the whole, "oh just build this random git hash, but leave the original openvdb we have alone, and just copy these headers, it'll work" is somewhat unorthodox, but given @Brecht Van Lommel (brecht) signed off on it I didn't question it.

In D9465#235810, @Jacques Lucke (JacquesLucke) wrote:

This is great. I was also looking into using libtooling to write some checks, but did not get very far yet.
It would be nice to get the necessary infrastructure in Blender.

• fix error message

Not quite ready for review yet but put it out for people to play with.

I can't seem to get master nor this patch to misbehave with msvc, but i can validate that when i have quotes they display properly and this patch doesn't break anything.

Given it is seemingly only useful when asan is on, perhaps toggle this behavior with WITH_COMPILER_ASAN ?

Hi please fill out your patch description, the wiki has some guidelines on what to include there.

Added the libs, however enabling it leads to a single failed test

Bastien Montagne (mont29) added subscribers: Campbell Barton (campbellbarton), Brecht Van Lommel (brecht), Bastien Montagne (mont29).

• undo whitespace change.

• fix one bad addition

• Merge remote-tracking branch 'origin/master' into arcpatch-D8628

Quick update for broader testing, not ready for review yet.

• Merge remote-tracking branch 'origin/master' into tmp_asan_cleanup

@Clément Foucault (fclem) has made a better fix.

You should not be calling IFACE_("Pictures") in fsmenu_read_system this will cause the msgid to be translated, and when you switch languages it will use the translated text as msgid, come up empty and stick with the previous translation.

Taking another pass at this, there is quite a mix of comment styles, sometimes even in the same function, best to follow the style guide on this.

After trying to catch it in a master build and see what is up, I cannot get it to misbehave.

I struggled to repro as well until i changed this option to match what I see in the video

Thanks for the patch!

A structure like

I have only repro'd with the file from T81587, have not tried any of the others.

Comments are comments, lets not try to give extra meaning to things that have none

I can reproduce this on AVX , it may not be architecture related.

As a result, anyone who ever had any exposure to modern CMake immediately knows what is going on without any abstraction.

I was a little more nuanced than that, i said as long as you can justify the changes, and the images are consistent between renders, you'll be ok, updating the ref images is not that big of a deal, however those two conditions do have to be met.

Please wait until D8864 has landed and then follow the structure it uses.

In D8864#225308, @Brecht Van Lommel (brecht) wrote:

I assumed this was only a conversation starter and didn't need to be accepted since you planned more work, but from devtalk it seems this is waiting so I'll accept it since it also seems fine as a first step to commit directly and then continue adding more libraries in master.

we bumped the lower bound fairly recently, to 3.10

I'm still convinced that exposing it in the UI is the way to go here, this is not a platform issue, the code to perform this registration is there, it's just not exposed in the UI

I can't test currently, but the change seems ok as a stop gap measure before we can land D7840 (target is 2.92 there) and get the sculpting guys going.

In T70313#1024014, @Alexander Zubov (motorsep) wrote:

And that's the reason they don't bother fixing this because they feel that you can just rearrange screens (which is nonsense .... )

I think @Brecht Van Lommel (brecht) mentioned a desire to move to -fvisibility=hidden on linux (and mac?) so for now this will do, until there is a blender wide solution in place.

some minor nitpicking looks good otherwise.

In T80830#1021100, @Sebastián Barschkis (sebbas) wrote:

• The platform maintainer who first implemented the preliminary support, puts it to master.>

@Sergey Sharybin (sergey) I assume "preliminary support" will be treated like new features, i.e. must go in in bcon1?

only pugi was required for the 2.91 cycle, once we get closer to or are in bcon1 for 2.92 i'll land this.

none of those are used in the VSE, for all i know ffmpeg is delivering the frame to us like this, a developer will have to look at this, throwing random things at the wall going "could it be this?" doesn't seem like a good use of anyone's time.

Code review (D8662) kind of dragged out on that one, which was weird, since it was a pretty straight forward lib with no crazy things in it, the patch was posted nearly a month before the bcon2 date and was mentioned in both the 2020-08-24 and 2020-08-31 meeting notes, complexity wise it was no different than D8384 (GMP) which sailed through in about a week.

In T80912#1018643, @Richard Antalik (ISS) wrote:

Regarding endianness it seems we rely on __BIG_ENDIAN__ and __LITTLE_ENDIAN__ symbols to be defined correctly, but they are not defined in GCC. I don't build on Linux so I don't know if this has to be defined explicitly somewhere in make files. @Ray molenkamp (LazyDodo) Are you familiar with this?

That is correct, looking at T80818 all platforms have updated, so we can turn it on by default

The platform files on the blender side are included like this

Of course running this already shows that baking was already broken

small nit pick : all deps have this order

I'm OK with landing this in one of the GP branches (just tell me where it needs to go) so there's actually something to test against (we'll just have to wait with landing it to master until all platforms are done)

it took a healthy chunk off the time it takes to run the unit tests, nice work!

People keep pinging this thread so i'll give another rundown on what is happening here.

Urgh you're right on the boost DIR vs DIRS, this has always been "wrong" our cmake is a giant mess.