I will commit this today. Thanks adrian for the patch and s0600204 for the help!

In D2671#112871, @nephele wrote:

Else at the very least I'd prefer to test the need for execinfo once at the beginning, so that we don't have calls to the compiler in the middle of our (already complex) prebuild logic.

Why would it matter?

I see. In that case I suppose this is OK (I find it rather ugly but that's personal taste).

Hi! Thanks for your contribution.

Thanks for the rebase @s0600204! Jenkins is indeed broken when source files are deleted (or moved) but there is still a build error on a clean build due to the test file.

I see! Thanks for the info. I'll include your changes in the other patch then 👍

Hello, thanks for the contribution! This should be already fixed by D2523, which is not yet committed. Could you take a look and check that it works? Else I'll update that other diff.

Thank you! 👍

In D2563#111168, @Stan wrote:

Ricotz told today on IRC it still doesn't work on ARM64. See https://launchpadlibrarian.net/467121489/buildlog_ubuntu-bionic-arm64.0ad_0.0.24~r23516-0ubuntu1~18.04~wfg1_BUILDING.txt.gz

Hi! Things look good to me 👍

Do you plan to run the tests manually, or would you be interested in having Jenkins run the tests when a patch touches source/tools/lobbybots?

I will test this and hopefully commit it during the upcoming weekend. I am a bit short on free time these days, so unfortunately when things are related to libraries some of the steps include waiting for me. Don't hesitate to contribute to other areas of the code in the meantime. Or if you want you can start working on the future cppformat upgrade steps since they seem to involve a lot of work.

(you also needed to specify the repository in order to trigger a build, I fixed that)

In D2613#110077, @adrian wrote:

I propose to merge this changes into codebase (I can restore old cppformat name) and create another ticket to update fmt to version 6.x. Unfortunately I'm not sure how much time I will have in the future, so I think better option is to not "lock" this issue further.

I agree, and actually I think it's very nice to use this small upgrade to rename the lib, so you can leave it like this.

Fix for GCC.

Thank you for the patch! We've been meaning to update cppformat (now fmtlib) for some time now. I had a half-finished patch for going to 2.1.1 (which was the last update before the renaming) in #3190, then was planning to update to the newest version in #4148.

Just a note since I see the patch only now:

Can you attach the dds generated by nvtt that it doesn't manage to load? Thanks :)

Hey! This is already in D2523.

No problem, thank you!

In D2563#107181, @Stan wrote:

This fixes NVTT build however I still get for some images:

Remove the macOS change that is out of place and is likely to create issues.

@Angen I forgot to close the diff in rP23382 😫

and check that the new va_list initializer works on other compilers

In D2548#107040, @Stan wrote:

@Itms can you close it?

In D2557#106874, @elexis wrote:

(A commit reference would be useful to ease commit traversal while reviewing, auditing or revisioning)

It was rP16824. And that is funny: looking at the commit, I had written a TODO, so I knew! I then removed the TODO in rP16827, just three revisions later, when I thought the improvements I made were enough.

Excluding the in-game terrain updates, which are not actually implemented, everything works fine for me and the code looks good.

In D2557#106789, @vladislavbelov wrote:

I think it's not enough, because it has only water level changes. That means the whole grid will be updated (no partial update).

Hey, this looks great! I didn't realize the message had that terrain information when I wrote the code!

In rP23305#40462, @Krinkle wrote:

Also, I was expecting the script to track the version of lib it built instead of boolean. Seems simple to implement, will consider that later.

Ideally we would do the same as for SpiderMonkey (see libraries/source/spidermonkey/build.sh):

if [ -e .already-built -a .already-built -nt README.txt ]

so that changes to the README trigger a rebuild. However, this is bypassed (including for SM) by build-osx-libs.sh. There is a big discrepancy between macOS and other unixes with respect to the process followed to build bundled libs.

@Krinkle

rm -f libraries/source/nvtt/.already-built

in order to actually build the new nvtt version with build-osx-libs.sh.

In D2491#105479, @elexis wrote:

In D2491#104180, @Itms wrote:

There is already this PR by a friend

While I appreciate the work on the software, calling leper your friend is a punch in the face and I will not go down in history as someone who read it and left it uncommented.

Also builds and runs --without-pch on Linux (gcc 7). 👍

This is good for me! I think you can commit this just after I commit D2524.

Tests fixed.

Thanks again for the patch Inari. I am commandeering it to fix the tests as well. I will commit this just after D2524.

In D1380#79218, @wraitii wrote:

Right now our precompiled headers also act as global include files, when they probably shouldn't.

Thanks for the patch and I owe you a beer or something for the delay 😅 The changes look perfect. Let's get them in before the copyright year becomes wrong...

Thanks!

This is mainly to test the new macOS patch building. Sorry in advance for the noise...

Could you set svn:ignore to *.cpp on source/third_party/ogre3d_preprocessor/tests (like we do in other tests folders)? That would be great for upcoming svn sts 😉

In D2522#105360, @Stan wrote:

Maybe we could have such a file and a test?

Should be good after rP23305.

Thanks for your patch, I have included the first part (with the other one you needed) in our upgraded NVTT.

Hm I just checked on Trac and I was probably confused. The Phab revisions are all from the lobby moderator and references on Trac all point to him as well. I was thinking we had a H_Baraq contributor way back then, in the 2013s or something, but I'm wrong.

Thanks for the work!

In D2501#104715, @Freagarach wrote:

See also D506?

@voroskoi Maybe you should send a pull request upstream. There is already this PR by a friend but it looks like the NVTT maintainer doesn't want it, maybe they'd rather like your solution.

Like Vlad said, I have just uploaded a NVTT upgrade, so it would be better if you'd test the branch (and I would happily include your patch in my upgrade if it's still needed).

I'm uploading it here for Jenkins, though arcanist may have botched the job, we'll see.

Welp, it definitely did...

nvtt will be rebuilt in D2475. nspr was rebuilt with the SM45 upgrade. I used the tool https://github.com/lucasg/Dependencies to ensure that all the other DLLs do not depend on the 2010 runtime.

I'm committing this with a license header and some whitespace fixes. Thanks for all the work!

Updated version using Docker (in place since months now).

Ach, I forgot to accept first, too late now. I applied this to Jenkins, everything works 👍