armv7: Re-activate non-x86 CI for ARMv7

[jdemel]

Previously, this part of our CI wasn't run because it always failed. However, we've seen recent changes that may allow it to run again.

[jdemel]

Well. We need some special treatment to build VOLK on ARMv7. I'm not entirely sure how to accomplish that though.

[michaelld]

Reverting my approval. Seems like you noticed the same as I did: the builds from this PR are failing. Looking into it while I have a spare moment ...

[michaelld]

Relevant error: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/amd64) and no specific platform was requested ... which leads me to believe that armv7 is not the correct platform name. Looking to see what platform name options are ...

[jdemel]

Relevant error: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/amd64) and no specific platform was requested

This warning shows up for aarch64 as well. Either, we need to use a toolchain file and then run our tests in the container. Or we need to figure out how to tell CMake that we're on ARMv7. Actually, I vaguely remember that this CMake problem came up a while ago.

[michaelld]

armv7 looks correct ... not sure what's going on here!

[Aang23]

Just a quick thought, but perhaps using CMake options to specify the compiler directly would bypass that issue, or perhaps providing a custom & proper toolchain file (in the same way the Android toolchain does for cross-compiling). Though if the container's actually armv7, it makes no sense for it to not "just work". Perhaps something to do with Ubuntu as a guest?

[michaelld]

This is very interesting ... here's the CMake error trace:

  CMake Error at /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
    list sub-command REMOVE_ITEM requires two or more arguments.
  Call Stack (most recent call first):
    /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
    /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
    /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
    /usr/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
    CMakeLists.txt:14 (project)

and here's the relevant CMake code:

cmake
  if (NOT "x${lang}" STREQUAL "xFortran" AND NOT "x${lang}" STREQUAL "xCSharp"
      AND NOT "x${lang}" STREQUAL "xISPC")
    file(GLOB lang_files
      "${CMAKE_ROOT}/Modules/Compiler/*-DetermineCompiler.cmake")
    set(nonlang CXX)
    if ("x${lang}" STREQUAL "xCXX")
      set(nonlang C)
    endif()

    file(GLOB nonlang_files
      "${CMAKE_ROOT}/Modules/Compiler/*-${nonlang}-DetermineCompiler.cmake")
    list(REMOVE_ITEM lang_files ${nonlang_files})
  endif()

which means that nonlang_files is empty/not defined, which should never be able to happen because the directory ${CMAKE_ROOT}/Modules/Compiler/ is alway populated with a bunch of *DetermineCompiler* files. OK, well, that code is likely to fail if CMAKE_ROOT is not set correctly ... so, maybe that's the key here?

Is there a way we can get access to the build files /volk/build/CMakeCache.txt and /volk/build/CMakeFiles/CMakeError.log? Those should show whether CMAKE_ROOT is set correctly & probably some other things of use.

[jdemel]

#610 supersedes this PR. Also, finally it looks like the armv7 tests run and pass successfully.

[jdemel]

#610 supersedes this PR. Closing.