Task - Add CMake Target(s)

[xsscx]

Task - Add CMake Target(s)

ci-latest-release to be modified:

• Add packaging for (dynamic,static) platform binaries that unzips and runs
  • Licensing a la npm install iccdev

If there is a need to modify the main CMake install target please indicate with tree & description.

Task

• @xsscx to add branch with packaging mods and update this issue for continued interation

ETA: 24 hours

Originally posted by @xsscx in #1276

[github-actions]

Thanks for opening this issue.

The triage bot added initial labels based on the template and issue text. Maintainers may adjust labels as they review scope, reproduction details, CTest/regression needs, and security impact.

If you have questions, contact a listed Maintainer.

[xsscx]

Add

• New Target/Rule for CPack .deb/.rpm

Fix

• dist-bin
• install & uninstall rules

Proto

• iccPawgReport
  • Already copies the Windows Libs/DLL
    • Issue is the PATH fixups for local devenv
    • Needs a Helper
  • Unix relies on Dependencies
    • does the right thing

[xsscx]

@colourbill-ctrl For the Packaging, any preferences?

• Tree Layout
• Static & Dynamic Packages
• Path Fixup Scripts
• All Libs & DLL in seperate directory
• Includes
  • Readme.md
  • License.md
  • other

What else do you want to see packaged assuming just the binaries & libs?

[colourbill-ctrl]

Thanks @xsscx — preferences below.

First, to reiterate my reservation from #1276: I'm with @ChrisCoxArt that I'm not entirely sure who this is for, so if we do this, let's start slow. Ideally we'd have some way to monitor who actually downloads the packaged installers to see if anyone uses them — but that only really works if we do considerably more work and publish the installers somewhere instrumented (e.g. through color.org), which is a lot more effort than the current GH-Releases path. So I'd treat v1 as a low-cost probe, not a committed product.

With that framing: since #1276 converged on package-manager channels that already exist (brew, vcpkg, npm) and the remaining ask here is CPack .deb/.rpm plus the "unzips and runs" archive, I'd keep v1 deliberately minimal: dynamic native packages + one self-contained archive, exes + libIccProfLib2 + LICENSE/README, no extras. Let real tester feedback (the <200 dev users @ChrisCoxArt scoped) drive anything fancier.

Summary

Item	Preference
Tree layout	Layout-by-target: FHS for .deb/.rpm (/usr/bin, /usr/lib, /usr/share/doc); flat self-contained dir for the zip and for Win/macOS
Static vs dynamic	Both, split by vehicle: dynamic → native packages (depend on system libs); static/self-contained → portable archive
Path-fixup scripts	Windows-only, and minimized — co-locate DLLs with the exes rather than mutate PATH. Linux/macOS need none (rpath/$ORIGIN / system loader)
Libs in separate dir	Tie to layout: system lib dir for native packages; co-located (or bin/+lib/ with rpath) for archives. Not a global yes/no
Includes	LICENSE.md (required, licensing parity with npm) + a trimmed packaging README; add VERSION/build manifest (SHA+date+platform) and THIRD-PARTY notices for bundled image libs
Else	Carry through SHA256SUMS; exclude the Testing/ tree; auto-generate the tool catalog from built exes (no hand-kept list). Skip man pages/completions in v1

Detail

Tree layout. For native packages, standard FHS is what apt/dnf users expect and what CPack/DEB emits cleanly:

/usr/bin/iccPawgReport, iccDumpProfile, …     ← all tool exes on PATH
/usr/lib/libIccProfLib2.so.2(.x.y)            ← versioned soname + symlink
/usr/share/doc/iccdev/{README.md,LICENSE.md}

The relocatable RUNPATH=$ORIGIN layout (libs next to exes) is the right answer for the portable archive and for Win/macOS, not for a system .deb/.rpm.

Static vs dynamic. Offer both, but split by vehicle rather than shipping a static .deb:

• Dynamic .deb/.rpm — declare Depends:/Requires: on system libtiff/jpeg/png/zlib; ship only the exes + libIccProfLib2. Smallest, cleanest uninstall — the "does the right thing on Unix" path you noted.
• Static / self-contained archive — bundle everything for "unzips and runs" with zero deps (the Installer for CmdLine Tools #1276 goal). A statically-linked .deb would defeat the package manager, so static belongs in the archive, not the native package.

Path-fixup scripts. This is really a Windows + local-devenv problem (your note: Windows copies the DLLs but PATH fixup is the pain; Unix is fine). Linux/macOS need no script — rpath/$ORIGIN for archives, system loader for packages. On Windows, prefer making fixup unnecessary by keeping DLLs co-located with the exes (the exe dir is searched first) over mutating user PATH. If a helper is still wanted, scope it to "add install dir to PATH / register the uninstall entry," keep it idempotent and Windows-only.

Libs in a separate directory. Don't decide this globally — tie it to the layout: native packages put libs in the system lib dir (not a bundled dir); archives/Win/macOS co-locate libs with the exes (matches the existing $ORIGIN / @loader_path bundling). A separate lib/ subdir is fine only if the exes' rpath points at it; flat-alongside is simpler and already works. The thing to avoid is a loose pile of DLLs the user has to manage by hand.

Includes. Yes to README + LICENSE, plus two cheap high-value adds:

• LICENSE.md — required; this is the licensing-parity-with-npm item.
• README.md — a packaging-specific trimmed version (what's installed, where, how to run, how to uninstall), not the full repo README.
• VERSION / build manifest — git SHA + build date + platform, so a user can report exactly which build they have (matters for the PAWG/security work).
• THIRD-PARTY notices — for the libtiff/jpeg/png/zlib bundled into the static archive (compliance for redistributed deps).

Anything else (binaries & libs only).

• Carry through the SHA256SUMS the release pipeline already emits.
• Exclude the Testing/ tree explicitly — that's the "not the entire testing folder tree" point from Installer for CmdLine Tools #1276.
• Auto-generate the tool catalog from the actual built exes (CPack component/file list) so the package tracks Tools/CmdLine as it grows — no hand-maintained list.
• Skip man pages / shell completions in v1 — small dev-only audience, not worth the maintenance yet.