NIfTI: treat nifti as the GIFTI dependency it actually is

[gdevenyi]

Why

Display never includes a nifti header directly. The only NIfTI symbols it uses are NIFTI_INTENT_* and NIFTI_TYPE_* in input_files/poly_formats.c, input_files/vertex_data.c and input_files/input_files.c — and all of them arrive through gifti_io.h, behind #if GIFTI_FOUND.

The nifti include directory and library were nevertheless added unconditionally, so a build with GIFTI disabled (the superbuild's current default — build_gifti() is commented out) picked up an include path it never read and carried a library on the link line it never called.

What

• include_directories(${NIFTI_INCLUDE_DIR}) moves inside the existing IF(GIFTI_FOUND) block, next to the GIFTI include.
• The four unconditional ${NIFTI_LIBRARY} entries in the link lists are replaced by NIFTI::niftiio appended alongside ${GIFTI_LIBRARY} in the two IF(GIFTI_FOUND) guards — the imported target carries its own include directory and dependencies, so nothing else is needed.

No functional change to a GIFTI-enabled build; a GIFTI-disabled build simply stops referencing nifti.

Verification

Configured through the full superbuild: Display generates, and with GIFTI off its link line no longer mentions nifti.

Ordering

NIFTI::niftiio is defined by the companion PR in BIC-MNI/minc-toolkit-v2. Since it is only referenced under IF(GIFTI_FOUND), and GIFTI is currently disabled there, this pin can move independently without breaking the build.

🤖 Generated with Claude Code

https://claude.ai/code/session_019katBUnczdvUS7WQ4RpVoa

[Copilot]

Pull request overview

This PR adjusts Display’s CMake configuration so NIfTI is treated as an implementation dependency of GIFTI (since Display only reaches NIfTI symbols through gifti_io.h when GIFTI_FOUND is enabled), avoiding unnecessary include/link references when GIFTI is disabled.

Changes:

• Moves NIfTI-related build wiring to be conditional on GIFTI_FOUND.
• Replaces unconditional ${NIFTI_LIBRARY} linkage with conditional linkage alongside ${GIFTI_LIBRARY}.
• Stops adding the NIfTI include directory unconditionally.

Suppressed comments (1)

CMakeLists.txt:437

• Same issue as above: NIFTI::niftiio is appended when GIFTI_FOUND is true, but if the imported target is not defined by the toolchain/config packages, configuration will fail when linking Display. Add an explicit target-existence check (or fallback) to keep GIFTI-enabled builds predictable.

  # Only link GIFTI when it was found
  IF(GIFTI_FOUND)
    LIST(APPEND LINK_LIBRARIES ${GIFTI_LIBRARY} NIFTI::niftiio)
  ENDIF(GIFTI_FOUND)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gdevenyi]

Correct, and already fixed in ea36767 (pushed shortly after this review).

This was a latent gap the PR exposed rather than created: Display has never found NIfTI itself, it relied on NIFTI_LIBRARY leaking in from an enclosing superbuild, and standalone that variable was simply empty so nothing complained. Referencing the target turns it into the hard error described.

It now finds the package at the point of use, which is the same place it becomes required:

IF(GIFTI_FOUND)
  IF(NOT TARGET NIFTI::niftiio)
    FIND_PACKAGE(NIFTI CONFIG REQUIRED)
  ENDIF()
  include_directories( ${GIFTI_INCLUDE_DIR} )
ENDIF(GIFTI_FOUND)

REQUIRED gives the clear early failure you asked for, and the NOT TARGET guard leaves an enclosing superbuild alone. This covers both link sites (the 418 and 434 cases), since neither is reached without GIFTI_FOUND.

[gdevenyi]

Added a second commit, fixing a gap the first one exposed.

Display has never found NIfTI itself — it relied on NIFTI_LIBRARY leaking in from an enclosing superbuild, and standalone that variable was simply empty, so nothing complained. Referencing NIFTI::niftiio turns that latent gap into a hard error: a standalone build that does find GIFTI would fail at generate time with the target undefined.

So it now finds the package at the point of use, which is the same place it becomes required:

IF(GIFTI_FOUND)
  IF(NOT TARGET NIFTI::niftiio)
    FIND_PACKAGE(NIFTI CONFIG REQUIRED)
  ENDIF()
  include_directories( ${GIFTI_INCLUDE_DIR} )
ENDIF(GIFTI_FOUND)

The NOT TARGET check leaves an enclosing superbuild alone; standalone, the package is found from the system or from any prefix on CMAKE_PREFIX_PATH. This matches what BIC-MNI/BEaST#15 does, so all three leaf packages now behave the same way: use the superbuild's target if there is one, otherwise find your own.

Verified: the full superbuild still configures and generates cleanly (GIFTI is disabled there, so the block is skipped), and the same find-and-link pattern compiles, links and runs against an installed system nifti_clib.