andrew/libakgl
1
0
Fork 0
Code Issues 67 Pull Requests Actions Packages Projects Releases Wiki Activity

No akglConfig.cmake is generated or installed, so find_package(akgl) cannot work #18

New Issue
Open
opened 2026-08-02 18:32:58 -04:00 by tachikoma · 0 comments
tachikoma commented 2026-08-02 18:32:58 -04:00
Collaborator
Copy Link

Source: TODO.md, "Entries in this file that are themselves stale" (at bbb7b8f)

TODO.md claimed, under "akgl.pc names no dependencies", that "the CMake path is
not affected -- akglConfig.cmake re-finds the targets".

No such file is generated or installed. CMakeLists.txt:933-948 ships the
library, the headers and akgl.pc only. There is no
configure_package_config_file, no write_basic_package_version_file, no
install(EXPORT ...). find_package(akgl) cannot work against an install tree at
all.

That makes the pkg-config problem worse than it was stated: pkg-config is not one
of two ways to consume an installed libakgl, it is the only one, and it names no
dependencies.

Fix: export the target and generate a config package alongside it, with a
SameMinorVersion compatibility rule -- the soname carries MAJOR.MINOR
deliberately for 0.x, so 0.9 and 0.10 are different ABIs and the version file
should refuse the mismatch at configure time.

Files: CMakeLists.txt:933-948

Filed by Tachikoma (Claude Code, Opus 5, 1M context)

**Source:** TODO.md, "Entries in this file that are themselves stale" (at bbb7b8f) `TODO.md` claimed, under "akgl.pc names no dependencies", that "the CMake path is not affected -- `akglConfig.cmake` re-finds the targets". **No such file is generated or installed.** `CMakeLists.txt:933-948` ships the library, the headers and `akgl.pc` only. There is no `configure_package_config_file`, no `write_basic_package_version_file`, no `install(EXPORT ...)`. `find_package(akgl)` cannot work against an install tree at all. That makes the pkg-config problem worse than it was stated: pkg-config is not one of two ways to consume an installed libakgl, it is the only one, and it names no dependencies. **Fix:** export the target and generate a config package alongside it, with a `SameMinorVersion` compatibility rule -- the soname carries `MAJOR.MINOR` deliberately for 0.x, so 0.9 and 0.10 are different ABIs and the version file should refuse the mismatch at configure time. **Files:** `CMakeLists.txt:933-948` --- Filed by Tachikoma (Claude Code, Opus 5, 1M context)
tachikoma added this to the 0.10.0 milestone 2026-08-02 18:32:58 -04:00
tachikoma added the packagingblast-radius:high labels 2026-08-02 18:32:58 -04:00
tachikoma added the status::grooming label 2026-08-02 18:49:14 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
abi-break
Cannot land without a soname bump
 api-gap
A caller cannot express something
 blast-radius:high
Ordering: highest blast radius
 blast-radius:low
Ordering: lowest blast radius
 blast-radius:medium
Ordering: middling blast radius
 defect
Wrong behaviour reachable from the public API
 design-decision
Needs a decision written down before code
 docs
Header comments, manual, AGENTS.md
 hygiene
Style, dead code, consistency
 packaging
Build, install, pkg-config, CMake config
 performance
Has a number in PERFORMANCE.md behind it
 status::blocked
Waiting on something else -- a decision, a dependency, or another issue
 status::grooming
Not yet worked out: scope, approach or priority still being settled
 status::ready
Understood well enough to start: scope and approach are settled
 test-coverage
A gap in the suites, not a defect
No Label blast-radius:high packaging status::grooming
Milestone
No items
No Milestone 0.10.0
Projects
Clear projects
No project
Assignees
Clear assignees
tachikoma andrew
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: andrew/libakgl#18
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?