Remove MSVC2013

[JeromeMartinez]

MSVC2013 does not support C++11.
Also remove the warnings in MSVC2017 and MSVC2019 due to modern C++ features without having set the modern C++ option in theses compiler settings

[cjee21]

FYI, the AppVeyor CI that's using MSVC2015 has errors due to zlib no longer has ASM.

[JeromeMartinez]

FYI, the AppVeyor CI that's using MSVC2015 has errors due to zlib no longer has ASM.

I don't see any error on my side (I don't think I use anymore MSVC2015), do you see somewhere else?
Do you have an idea of quick "fix" for that?

[cjee21]

I don't see any error on my side (I don't think I use anymore MSVC2015), do you see somewhere else?

Here: https://ci.appveyor.com/project/MediaArea/mediainfolib/builds/51497219/job/xlrh6kmhi3ssdbgf

Do you have an idea of quick "fix" for that?

I know nothing about AppVeyor. Maybe use GitHub Actions to build the MSVC Projects instead?

[g-maxime]

I'll try to update the .appveyor.yml

[JeromeMartinez]

Here: https://ci.appveyor.com/project/MediaArea/mediainfolib/builds/51497219/job/xlrh6kmhi3ssdbgf

The ASM compiler is not found but as we compile without ASM it is not an issue (build succeeds).
@g-maxime will adapt the build script for not trying to download the ASM compiler.

Using ASM in zlib would be actually a nice to have but super low priority (zlib is rarely used in A/V file and usually for small blocks, except compressed ADM but it is rare).

Maybe use GitHub Actions to build the MSVC Projects instead?

On our todo-list but would not change the issue with the ASM compiler.

[cjee21]

Using ASM in zlib would be actually a nice to have but super low priority (zlib is rarely used in A/V file and usually for small blocks, except compressed ADM but it is rare).

ASM was removed from zlib as I understand. They no longer have any ASM files and actually the 'Release' and 'ReleaseWithoutAsm' configs might now actually be the same.

On our todo-list but would not change the issue with the ASM compiler.

I can try writing a workflow on my fork for MSVC. Would get more familiar with GitHub Actions while trying that.

[JeromeMartinez]

ASM was removed from zlib as I understand.

Ha! I guess that compiler are enough optimized nowadays for not having the need of it...

I can try writing a workflow on my fork for MSVC. Would get more familiar with GitHub Actions while trying that.

A good way to learn :).
We are fine for moving all to GitHub Actions, and switching to MSVC 2022 at the same time (MSVC 2015 project files may be removed in some time, MSVC 2017 and MSVC 2019 are there just as copies with the corresponding "toolset" but are not expected to be used by us).

[JeromeMartinez]

@cjee21 by the way thank you for helping us and motivating us in the clean up of our projects, appreciated.

[cjee21]

@JeromeMartinez Got the build working on GitHub Actions: https://github.com/cjee21/MediaInfoLib/actions/runs/13282105993

Do we need to run any tests after build?
Also, Windows SDK 10.0.26100 has dropped support for 32-bit ARM so I excluded that.

[JeromeMartinez]

Do we need to run any tests after build?

No, when relevant we do it on Linux builds, and we have currently no Windows specific checks AFAIK.

Also, Windows SDK 10.0.26100 has dropped support for 32-bit ARM so I excluded that.

True that 32-bit ARM is not really needed.

[cjee21]

So you want a PR for this? Any changes desired?

[JeromeMartinez]

So you want a PR for this? Any changes desired?

Thinking again about 32-bit ARM, it does not hurt so let's keep it some time.
Moving all CI to GitHub Actions would be a nice to have, if you are motivated for doing it. No change expected compared to Travis CI.

[JeromeMartinez]

Thinking again about 32-bit ARM, it does not hurt so let's keep it some time.

Thinking again again about that, it was never used if I remember correctly (you managed only 64-bit, right?) so could be removed.

[cjee21]

Thinking again about 32-bit ARM, it does not hurt so let's keep it some time.

The thing is, MediaInfoLibs project files are set to use latest SDK right? So, latest SDK will be used by CI and also my local builds since both have latest installed. Since latest SDK dropped support, adding it to CI will fail the build.

So, keep ARM (32) in the project file but don't build in CI.

By the way, what SDK is the build farm using? Seems you can build ARM 32 previously?

[JeromeMartinez]

So, keep ARM (32) in the project file but don't build in CI.

I am fine with removing it completely from project files.

By the way, what SDK is the build farm using? Seems you can build ARM 32 previously?

ARM and ARM64 were never built in the CI, check the Travis config file, only win32 and x64 are set, I guess it is possible to filter the same way in GitHub. but as said, I am also fine with removing 32-bit ARM from project files as we never used it AFAIK.

[cjee21]

Ok, I remember wrongly, ARM (32) was only added to project files but never built/released. There is no issue with excluding ARM (32) from GitHub CI as I already did (you can see the run result linked above). I'll leave the project file as it is (I'm not the one who added ARM(32)).

[JeromeMartinez]

Fine for me, so PR (on all projects). Please remove the Travis related file too as it is no more needed with this update.

[cjee21]

Fine for me, so PR (on all projects). Please remove the Travis related file too as it is no more needed with this update.

Ok. I'll look into the other repo.

Note: GitHub Actions appear to finish in half the time it takes for AppVeyor even with the added architectures.

[JeromeMartinez]

Note: GitHub Actions appear to finish in half the time it takes for AppVeyor even with the added architectures.

At the beginning... Issue will be that we'll consume more free GitHub Actions, let's see if we reach any free stuff limit :).

[cjee21]

let's see if we reach any free stuff limit :).

I do not think we will run into any limits for open-source projects. I mean, there are repos that run GitHub Actions for hours building multiple versions of FFmpeg every night :)

[cjee21]

GitHub Actions usage is free for standard GitHub-hosted runners in public repositories, and for self-hosted runners. For private repositories, each GitHub account receives a certain amount of free minutes and storage for use with GitHub-hosted runners, depending on the account's plan. Any usage beyond the included amounts is controlled by spending limits.

Found it. So looks like it is free and unlimited for public, open-source repos with only limits on concurrent jobs and time taken for a job.

[JeromeMartinez]

Found it. So looks like it is free and unlimited for public, open-source repos with only limits on concurrent jobs and time taken for a job.

Travis is also "unlimited" but uses to put jobs in a slower queue after consuming "too much" ;-).
Anyway, not a big deal, let's see.