[imgui] Add test-engine feature

[RT2Code]

Add test-engine feature to the imgui port: https://github.com/ocornut/imgui_test_engine

I made it a feature because they both depend on each other to build, that's why it is a feature instead of a new port.

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[dg0yt]

Do we need a test port to activate this feature?
It is easy to forget the test, or just to forget to update the SHA512 for a optional download.

[RT2Code]

I didn't know that test ports existed, but I suppose it would be better to have one here. I added it.

[dg0yt]

Now we see how useful test ports and executables are...
With test-engine in imgui, there are two problems downstream:

• stb definitions in test engine duplicate the definitions in downstream apps.
• stb definitions in test engine are not relocatable.

Excerpt from milerius-sfml-imgui:

/mnt/vcpkg-ci/installed/x64-linux/include/stb_image_write.h:1617: multiple definition of `stbi_write_jpg'; /mnt/vcpkg-ci/installed/x64-linux/debug/lib/libimguid.a(imgui_capture_tool.cpp.o):/mnt/vcpkg-ci/b/imgui/src/.6-docking-82d03bc653.clean/test-engine/thirdparty/stb/imstb_image_write.h:1519: first defined here
/usr/bin/ld: /mnt/vcpkg-ci/installed/x64-linux/debug/lib/libsfml-graphics-s-d.a(ImageLoader.cpp.o): warning: relocation against `stbi_write_force_png_filter' in read-only section `.text'
/usr/bin/ld: /mnt/vcpkg-ci/installed/x64-linux/debug/lib/libsfml-graphics-s-d.a(ImageLoader.cpp.o): relocation R_X86_64_PC32 against symbol `stbi_write_tga_with_rle' can not be used when making a shared object; recompile with -fPIC

IMO there should be no stb definition in any lib (unless there would be a single stb lib) - that's how stb is designed.

[RT2Code]

I managed to make it build on all platforms. I disabled uwp support because the test-engine library uses some CRT functions which aren't supported on this platform like _wpopen. I also replaced the embedded stb lib with the one from vcpkg to better conform to the vcpkg maintainer guidelines.

One thing that I'm really unhappy with is the way that the std implementation is managed. The only way I found to make it build everywhere was to disable it for static builds, but keep it enabled for dynamic builds, which is unconsistent.

Wouldn't it be better if the stb port compiled it to a static library instead of only providing the headers and leaving the responsability of handling the implementation to the user? The macro would need to be defined only once, in the port build, and then it would act like any other static library. No multiple definitions, no need to define any macro to get the implementation.

[WangWeiLin-MV]

The port usage and features test pass with the following triplets:

• x64-linux
• x64-windows

Test invalid since PR updated.

[dg0yt]

Wouldn't it be better if the stb port compiled it to a static library instead of only providing the headers and leaving the responsability of handling the implementation to the user? The macro would need to be defined only once, in the port build, and then it would act like any other static library. No multiple definitions, no need to define any macro to get the implementation.

That is also what I think. There are several such packages which claim to be header only, but actually only avoid building a proper static lib.
However I don't want to open this can of worms for packages which document another form of use.

[RT2Code]

I spent more time studying the stb libs and it made me reconsider what I said. Those libs have many important compile time options, and some are designed to build with static symbols to allow for separate configurations in different compile units. If we build them into a static library, we remove those options for the user, so I now think the current way vcpkg handle stb is the best.

That being said, I have found a better way to fix the multiple definition issue. As I said, some stb libs provide the option to make the symbols static instead of public in the compilation unit, and it's perfect to prevent any clash with other libraries using the same stb headers. I just added the STB_IMAGE_WRITE_STATIC macro before std_image_write.h inclusion, and now everything builds fine on every platform with no ugly hacks.

[WangWeiLin-MV]

The port usage tests pass with the following triplets:

• x64-linux
• x64-windows

[RT2Code]

Sorry, I changed it to draft because I want to try a different approach to add this feature which could be better. I'll make a second PR and I'll explain the difference between the two versions, so you can choose the one you think is the most pertinent.

[BillyONeal]

In general, ports are not expected to build tests. Can you explain what a vcpkg customer does with this option? (This might be entirely fine, I just want to understand that it is :) )

[RT2Code]

The test-engine library is an official component of imgui composed of two parts :

• The test-engine itself, a test/automation system for imgui.
• The test-suite, a collection of tests for imgui written with the test-engine.

The latter is not relevant for vcpkg, because as you said, ports are not supposed to build tests, that's why I ignore it in this port. But the test-engine can be very useful for a variety of applications. It's akin to libraries like google-test or catch2, it can be used to write your own tests for imgui, or for automation purposes. As it can simulate user inputs, it can also be used to write some kind of live tutorials, and it is also able to export the result to videos/gifs to showcase it. There's also a performance tool, and that's the feature that is lacking in the current PR that I want to try to add, but it's not easy because of a circular dependency with implot.

In a nutshell, the test-engine is a very powerful framework, adding many new features to imgui and it really should be available in vcpkg.

[RT2Code]

I made the alternative PR I talked about: #38961. It is better in every way and should be preferred in my opinion, but if it is refused for whatever reason, this one serves as an alternative.

[RT2Code]

Ultimately, I was unable to make the new PR work for reasons explained here, so, except if someone knows a way to fix it, I guess this one will have to do.