Add Cmake build/test to Actions. Add Dockerfiles to reproduce Actions workflows.

[dwpaley]

No description provided.

[hattne]

Looks good to me; only nitpicks from my side. Please keep in mind that I'm a total n00b as far as these actions are concerned.

I generally like to build in a separate directory to keep the source directory clean, but for this kind of one-off build that is irrelevant.

[hattne]

I think cmake --build . or possibly cmake --build . --parallel may be better here: that would remove the assumption that the Unix Makefiles generator was used.

[hattne]

A little surprised you need libtiff-dev, since by default CMake should build LibTIFF in-tree. Or is this a way to get the dependencies for the in-tree LibTIFF build?

Actually, I think the environment should be set up with the HDF5 and LibTIFF dependencies. Then, the build could be configured with -DCBF_WITH_HDF5:BOOL=OFF, -DCBF_WITH_PCRE:BOOL=OFF, and -DCBF_WITH_LIBTIFF:BOOL=OFF to avoid building the dependencies in-tree. After all, the purpose is to test CBFlib, not the dependencies. It would also save some CI resources.

Note that the CQRlib dependency would still be built in-tree; I guess Ubuntu has a package for it, but I'm not sure if it'll work as things currently stand.

[dwpaley]

Here's the build error if I don't add libtiff-dev:

[ 95%] Building C object CMakeFiles/tiff2cbf.dir/examples/tif_sprint.c.o
/home/runner/work/cbflib/cbflib/examples/tif_sprint.c:48:10: fatal error: tiffio.h: No such file or directory
   48 | #include <tiffio.h>
      |          ^~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/tiff2cbf.dir/build.make:79: CMakeFiles/tiff2cbf.dir/examples/tif_sprint.c.o] Error 1

from the build log here: https://github.com/dials/cbflib/actions/runs/14525513797/job/40756100837 and pretty much the same result if I try the build by hand in a container. I do note that libtiff appeared to build successfully prior to hitting this error.

Will add another commit momentarily to skip building hdf5 and libtiff. When I build according to your suggestion, then ctest runs (numbers from my dubious memory) 149 tests instead of 223. Any concerns about that?

[hattne]

It sorta-kinda looks like tiff2cbf is trying to include tiffio.h before LibTIFF has been installed. And if one has LibTIFF in the environment, the build falls back on tiffio.h from there. I'll look into this more closely tonight.

Regarding the tests: this is to be expected. If you're building LibTIFF in-tree, you will run the LibTIFF test suite in addition to the CBFlib tests (the tests cannot be disabled in LibTIFF 4.0.6, if I recall). I don't remember the precise numbers, but 149 looks like a reasonable number of tests for CBFlib alone.

[hattne]

See above: I would use cmake --build . here. I have next to no experience with these actions, I'm not sure which of the make invocations is responsible for building the thing.

[yayahjb]

Unfortunately, libtiff was, is and is likely to remain a fragile environment to work in, It is not surprising that it works better with an install of libtiff-dev than without it. To extract from a long discussion by claude,ai in response to the question In maintaining debian and ubuntu software that uses liftiff it seems to be necessary to also installl libtiff-dev. It there any argument against installing liftiff-dev routinely clause says "If you're frequently building or maintaining software that requires libtiff, installing libtiff-dev routinely is a perfectly reasonable approach and will save you time troubleshooting build failures. The downsides are minimal for most use cases." ...

…

On Mon, Apr 21, 2025 at 7:13 PM Johan Hattne ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In .github/workflows/cmake_ctest.yml <#83 (comment)>: > + pull_request: + types: + - synchronize + - opened + workflow_dispatch: + +jobs: + build_test: + runs-on: ubuntu-latest + + steps: + - uses: ***@***.*** + - name: install extra dependencies + run: | + sudo apt-get update + sudo apt-get install -y libtiff-dev It sorta-kinda looks like tiff2cbf is trying to include tiffio.h before *LibTIFF* has been installed. And if one has *LibTIFF* in the environment, the build falls back on tiffio.h from there. I'll look into this more closely tonight. Regarding the tests: this is to be expected. If you're building *LibTIFF* in-tree, you will run the *LibTIFF* test suite in addition to the *CBFlib* tests (the tests cannot be disabled in *LibTIFF* 4.0.6, if I recall). I don't remember the precise numbers, but 149 looks like a reasonable number of tests for *CBFlib* alone. — Reply to this email directly, view it on GitHub <#83 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB6EAOM3QJXKHHAFCQ724322V3SDAVCNFSM6AAAAAB3L5KSZ2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDOOBSGM4TKMRYGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hattne]

@dwpaley does c56ab7a address the issues on your end?

@yayahjb If c56ab7a does indeed fix Daniel's problem, there is arguably a bug in LibTIFF (not setting the include directories properly on the tiff target), and as far as I can see it would be present even in the current code. I've made a note to check again once CBFlib dependencies can updated.

[hattne]

@yayahjb If c56ab7a does indeed fix Daniel's problem, there is arguably a bug in LibTIFF (not setting the include directories properly on the tiff target), and as far as I can see it would be present even in the current code. I've made a note to check again once CBFlib dependencies can updated.

Wrong I was! The upstream LibTIFF issue was fixed in libtiff #12, released with 4.0.10. Updating to 4.7.0 as per #90 obsoletes the workaround in c56ab7a.