Blaze_Import() does not run if CMakeLists.txt is subsequently changed

[Louis Marascio]

In Blaze_Import() there is a guard:

      if(blaze_FOUND)
         if(NOT Blaze_Import_QUIET OR Blaze_Import_DEBUG)
            message(WARNING "Blaze was already imported and will not be imported again")
         endif()
      else()

On an initial run of CMake blaze_FOUND is false and thus the bulk of Blaze_Import() runs. Notably, the bulk of this function defines an INTERFACE library Blaze and sets various properties on it for the configuration. Since this is an INTERFACE target it is not persisted as part of the build system and the properties are applied to those targets that link against Blaze.

This works fine on the initial run; however, if one changes CMakeLists.txt or otherwise causes CMake to run again and since Blaze_FOUND is written to the CMakeCache that means that Blaze_Import() will not run. In effect, on this run of CMake, the Blaze target will not exist and thus those targets that depend on it will not get the configuration required to build against Blaze and link against the underlying dependencies (lapack, etc).

I’m not sure why Blaze_Import() attempts to guard against subsequent runs, is there a reason I’m missing? The way it currently is, CMake can only be run once for a given project and then if you want to run it again you must remove your CMakeCache to wipe out the blaze_FOUND variable, otherwise the build will not work.

[Louis Marascio]

I should add that I can easily submit a PR for this but I want to make sure I’m not missing something first. Perhaps there is a reason that guard is there? Everything seems to work correctly if I comment it out.

[Klaus Iglberger]

Hi Louis!

Thanks for taking the time to report this defect. I’m not aware of any particular (strong) reason why this guard exists, but I’ve not written the CMakeLists.txt myself. Still, I believe it could be removed to enable multiple runs of CMake.

I’ll not be able to address this issue within the next couple of weeks. Since this problem hasn’t been reported before I suspect that very few people have run into this issue. Therefore I don’t consider it as urgent. But since you have already proven your CMake experience, I would be glad if you would spent the time to try to fix the issue. The help would be very much appreciated.

Thanks again for reporting this defect,

Best regards,

Klaus!

[Louis Marascio]

Sounds good, thanks Klaus. I’ve submitted a PR to address this: https://bitbucket.org/blaze-lib/blaze/pull-requests/55

[Klaus Iglberger]

Do not guard against multiple Blaze_Import() calls

Guarding against multiple Blaze_Import() calls will cause subsequent invocations of CMake to improperly configure the Blaze target. To avoid this we remove the guard inside of Blaze_Import() and always run the function. There should be no adverse side effects and indeed, because the Blaze target is an INTERFACE target it must be reconfigured since its settings (include directories, for example) are not persisted with the build system itself.

Resolves #422

→ <<cset 89dda60cc8c9>>