deps: Add build recipe for GIF

[hisergiorojas]

Description

As requested in #4387.

Checklist:

• [ x] I have read the contribution guidelines.
• I have updated the documentation, if applicable. (Check if there is no
  need to update the documentation, for example if this is a bug fix that
  doesn't change the API.)
• I have ensured that the change is tested somewhere in the testsuite
  (adding new test cases if necessary).
• If I added or modified a C++ API call, I have also amended the
  corresponding Python bindings (and if altering ImageBufAlgo functions, also
  exposed the new functionality as oiiotool options).
• My code follows the prevailing code style of this project. If I haven't
  already run clang-format before submitting, I definitely will look at the CI
  test that runs clang-format and fix anything that it highlights as being
  nonconforming.

[lgritz]

How did you test this and verify that it works?

[hisergiorojas]

I'm still working on the pull request -

Here's what I'm currently doing to test and verify the CMake files:

1. I've turned on the "ignore homebrew-installed dependencies" option in the CMakeLists.txt file.
2. Then I'm building with these commands:

mkdir build
cd build
cmake .. -DOpenImageIO_BUILD_MISSING_DEPS=all

This makes CMake to build all dependencies locally instead of using system-installed versions.

[hisergiorojas]

[hisergiorojas]

[hisergiorojas]

Another way to test and verify:

1. To build oiiotool specifically, you can continue the build process with:

make -j8 # Adjust based on the number of CPU cores

2. Once the build completes, you can verify GIF support by:

a. Converting an image to GIF format:
./bin/oiiotool path/to/some/image.jpg -o test_output.gif

b. You can also try to convert a GIF to another format to further verify that it's working:
./bin/oiiotool ~/Downloads/earth.gif -o earth.jpg

[lgritz]

Should we be bothered by the fact that the build_dependency_with_cmake function doesn't take a "PATCH_COMMAND" argument, and so this extra patch won't be applied?

[lgritz]

Also, build_dependency_with_cmake doesn't take a URL or URL_HASH argument, and in fact the only kind of download it knows how to do is to clone a git repo? I just don't understand how the code as presented here can work.

Are you sure you aren't locally running and testing a version of this patch that is different from the one currently in this PR?

This hypothesis is also supported by the fact that the screenshots you attached have messages about FetchContent, which we do not call anywhere and also aren't mentioned in this patch.

[hisergiorojas]

just realized I forgot to push my latest change where I removed the build_dependency_with_cmake method since it only accepts a git repository

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: hisergiorojas / name: Sergio Rojas (0f7a559, 34ba540)

[lgritz]

This PR has been idling for a while, I think because it never quite passed CI. Is this something you're going to return to, @hisergiorojas? Maybe we should start by rebasing it on top of the current main and see what, if anything, is still broken?

[lgritz]

Closing. This never fully passed CI, the PR has sat idle for months without the author fixing it, and in the mean time, somebody else has fully implemented it in #4921. Sincere thanks for trying to implement this; it's ok, not all PRs work out. The effort is appreciated.