Use targets instead of calling cmake command

[DaAwesomeP]

Hi,

Why does the build process call the cmake command directly instead of adding targets for each module? When adding AOCL to another project this causes AOCL to build during configuration (instead of during build). It also causes the modules to be rebuilt every time--even if they have already been built.

Thanks!

[tony-davis]

We encountered this issue while integrating AOCL 5.2 into a larger CMake-based build system. Can confirm this is a significant problem for integration.

The Technical Issue

AOCL's build scripts (aocl_blis_build.cmake, etc.) use execute_process() to invoke cmake commands:

execute_process(
    COMMAND cmake -G ${CMAKE_GENERATOR} -S ${BLAS_DIR} -B ${CMAKE_BINARY_DIR}/blis/build_dir ...
)

execute_process(
    COMMAND cmake --build ${CMAKE_BINARY_DIR}/blis/build_dir --config ${CMAKE_BUILD_TYPE} --target install ...
)

The problem: execute_process() runs during the configuration phase of CMake, not the build phase. This means:

1. AOCL builds during cmake configuration - Every time you run cmake to configure your project, AOCL rebuilds completely (~5-10 minutes), even if nothing changed
2. No incremental builds - Can't leverage CMake's dependency tracking for AOCL components
3. Breaks clean configuration - Configuration should be fast and idempotent; building should happen during ninja/make

Impact on Integration

• Forces integrators to wrap AOCL in ExternalProject_Add() to work around the issue (which we did)
• Even with the workaround, the build behavior is suboptimal
• Makes AOCL difficult to use in CMake-based superprojects or package managers

The Right Approach

AOCL should use proper CMake patterns:

• add_subdirectory() for components in the same tree
• FetchContent for external dependencies
• add_custom_command() with proper OUTPUT declarations for generated files

This would make AOCL a well-behaved CMake component that respects build phases and enables incremental builds.

Thanks for filing this - it's a fundamental issue that makes AOCL harder to integrate than it needs to be.

[DaAwesomeP]

We are working around this by directly building from the https://github.com/amd/blis repo instead:

if (BUILD_BLAS_AOCL OR BUILD_BLAS_AOCL_MT)
    set(BLAS_AOCL_OPTIONS "${BLAS_AOCL_OPTIONS}" "BUILD_STATIC_LIBS OFF")
    set(BLAS_AOCL_OPTIONS "${BLAS_AOCL_OPTIONS}" "BUILD_SHARED_LIBS ON")
    set(BLAS_AOCL_OPTIONS "${BLAS_AOCL_OPTIONS}" "ENABLE_BLAS ON")
    set(BLAS_AOCL_OPTIONS "${BLAS_AOCL_OPTIONS}" "ENABLE_CBLAS ON")
    set(BLAS_AOCL_OPTIONS "${BLAS_AOCL_OPTIONS}" "BLIS_CONFIG_FAMILY amdzen")
    set(BLAS_AOCL_OPTIONS "${BLAS_AOCL_OPTIONS}" "ENABLE_TRSM_PREINVERSION ON")
    set(BLAS_AOCL_OPTIONS "${BLAS_AOCL_OPTIONS}" "ENABLE_ADDON aocl_gemm")
    if (CMAKE_SYSTEM_NAME MATCHES "Windows")
        set(BLAS_AOCL_OPTIONS "${BLAS_AOCL_OPTIONS}" "COMPLEX_RETURN intel")
    else()
        set(BLAS_AOCL_OPTIONS "${BLAS_AOCL_OPTIONS}" "COMPLEX_RETURN default")
    endif()

    if (BUILD_BLAS_AOCL_MT)
        set(BLAS_AOCL_OPTIONS "${BLAS_AOCL_OPTIONS}" "ENABLE_THREADING openmp")
    else()
        set(BLAS_AOCL_OPTIONS "${BLAS_AOCL_OPTIONS}" "ENABLE_THREADING no")
    endif()

    CPMAddPackage(
            NAME blas
            GITHUB_REPOSITORY amd/blis
            GIT_TAG AOCL-Weekly-121225
            OPTIONS
                ${BLAS_AOCL_OPTIONS}
    )
endif()

Once doing the above we can add a dependency from our project to AOCL::BLIS_shared and set include dirs to ${blas_BINARY_DIR}/include/amdzen.