Problem
AOCL's build system hardcodes installation paths to lib/ and include/ relative to CMAKE_INSTALL_PREFIX, ignoring the standard CMake variables CMAKE_INSTALL_LIBDIR and CMAKE_INSTALL_INCLUDEDIR. This breaks integration with build systems that need to install libraries to non-standard locations.
Impact
When integrating AOCL into a CMake super-project that uses a custom directory layout, we need to install AOCL alongside other host math libraries in a specific subdirectory structure. Despite setting:
-DCMAKE_INSTALL_LIBDIR=lib/host-math/lib
-DCMAKE_INSTALL_INCLUDEDIR=lib/host-math/include
AOCL still installs to:
- Library:
${CMAKE_INSTALL_PREFIX}/lib/libaocl.a (ignores CMAKE_INSTALL_LIBDIR)
- Headers:
${CMAKE_INSTALL_PREFIX}/include/*.h (ignores CMAKE_INSTALL_INCLUDEDIR)
Current Workaround
We're forced to manually copy files after AOCL's build completes:
# Manual library install workaround
install(FILES "${CMAKE_CURRENT_BINARY_DIR}/build-aocl/libaocl.a"
DESTINATION ${CMAKE_INSTALL_LIBDIR})
# Manual header copy workaround with validation
install(CODE "
file(GLOB_RECURSE AOCL_HEADERS \"\${CMAKE_INSTALL_PREFIX}/include/*.h\")
list(LENGTH AOCL_HEADERS NUM_HEADERS)
if(NUM_HEADERS EQUAL 0)
message(FATAL_ERROR \"No AOCL headers found\")
endif()
foreach(HEADER \${AOCL_HEADERS})
file(RELATIVE_PATH REL_PATH \"\${CMAKE_INSTALL_PREFIX}/include\" \"\${HEADER}\")
get_filename_component(HEADER_DIR \"\${REL_PATH}\" DIRECTORY)
if(HEADER_DIR)
file(MAKE_DIRECTORY \"\${CMAKE_INSTALL_PREFIX}/\${CMAKE_INSTALL_INCLUDEDIR}/aocl/\${HEADER_DIR}\")
endif()
file(COPY_FILE \"\${HEADER}\" \"\${CMAKE_INSTALL_PREFIX}/\${CMAKE_INSTALL_INCLUDEDIR}/aocl/\${REL_PATH}\")
endforeach()
")
This workaround:
- Adds ~50 lines of boilerplate to wrapper builds
- Increases maintenance burden
- Breaks the principle of least surprise for CMake users
Expected Behavior
AOCL should respect standard CMake installation variables:
install(TARGETS aocl
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
)
install(DIRECTORY ${BLIS_HEADERS}
DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
)
This is the standard CMake pattern used by virtually all well-behaved CMake projects (e.g., Boost, Eigen, OpenBLAS when built via CMake).
Root Cause Location
The issue likely stems from hardcoded paths in the individual component build scripts:
aocl_blis_build.cmake
aocl_libflame_build.cmake
- etc.
And/or the install logic in CMakeLists.txt that doesn't forward these variables to subprojects.
Benefits of Fixing This
- Standard compliance: Follows CMake conventions expected by integrators
- Flexibility: Allows embedding AOCL in complex build systems with custom layouts
- Simplicity: Eliminates need for manual post-install file copying
- FHS compliance: Supports Filesystem Hierarchy Standard installations on Linux (e.g., Debian packages using
CMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu)
Environment
- AOCL version: 5.2.0
- Build system: CMake 3.25+
- Integration context: CMake super-project with custom directory layout
References
Thank you for considering this enhancement. Respecting standard CMake variables would significantly improve AOCL's integration story for projects beyond standalone builds.
Problem
AOCL's build system hardcodes installation paths to
lib/andinclude/relative toCMAKE_INSTALL_PREFIX, ignoring the standard CMake variablesCMAKE_INSTALL_LIBDIRandCMAKE_INSTALL_INCLUDEDIR. This breaks integration with build systems that need to install libraries to non-standard locations.Impact
When integrating AOCL into a CMake super-project that uses a custom directory layout, we need to install AOCL alongside other host math libraries in a specific subdirectory structure. Despite setting:
AOCL still installs to:
${CMAKE_INSTALL_PREFIX}/lib/libaocl.a(ignoresCMAKE_INSTALL_LIBDIR)${CMAKE_INSTALL_PREFIX}/include/*.h(ignoresCMAKE_INSTALL_INCLUDEDIR)Current Workaround
We're forced to manually copy files after AOCL's build completes:
This workaround:
Expected Behavior
AOCL should respect standard CMake installation variables:
This is the standard CMake pattern used by virtually all well-behaved CMake projects (e.g., Boost, Eigen, OpenBLAS when built via CMake).
Root Cause Location
The issue likely stems from hardcoded paths in the individual component build scripts:
aocl_blis_build.cmakeaocl_libflame_build.cmakeAnd/or the install logic in
CMakeLists.txtthat doesn't forward these variables to subprojects.Benefits of Fixing This
CMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu)Environment
References
Thank you for considering this enhancement. Respecting standard CMake variables would significantly improve AOCL's integration story for projects beyond standalone builds.