Alpaka: Build issue with headerCheck

[sbastrakov]

This is probably similar to #364 and #440 .

I'm building the latest alpaka develop on a Windows machine with OpenMP and CUDA installed using
cmake . -G "Visual Studio 15 2017 Win64" > cmake_output.txt 2>&1
and the headerCheckfails with the following cmake_output.txt.
Setting -DALPAKA_ACC_GPU_CUDA_ENABLE=OFF does not help, here is the output.

I'm actually not sure if this issue was present for me before, since previously I've mostly compiled with disabled tests.

[BenjaminW3]

I can not locally reproduce this. It works for me using CMake 3.12 and Visual Studio 2017 15.7 on the current develop branch.
Which CMake version have you used? Have you tried a clean clone?

[BenjaminW3]

Are you using one of the 3.* release branches? The fix may not have been backported there (I do not know).

[ax3l]

@BenjaminW3 nope, he referred to develop in the PR description

[ax3l]

@sbastrakov your cmake output reads:

-- Found alpaka: C:/Code/alpaka/include (found version "0.3.0")

in both cases. Are you sure your paths are set correctly?

[sbastrakov]

To reproduce just made a fresh clone and retried (yes, for the develop branch as before) with the same result. I have cmake 3.11.0 and MSVS 15.6.4.
@ax3l what's wrong with that? Ofc between the tries I've cleaned up.

[sbastrakov]

@BenjaminW3 but is my issue that these tests do not compile and they should (and do on your machine), or that they should be disabled and don't get disabled?

[ax3l]

-- Found alpaka: C:/Code/alpaka/include (found version "0.3.0")

in both cases. Are you sure your paths are set correctly?

what's wrong with that?

ah, could be just not bumped in the develop branch. alright!

[BenjaminW3]

@sbastrakov They correctly compile on my machine as well as in CI (linux only).
@ax3l Appveyor for Windows builds is not available anymore out of unknown reasons. Can this be enabled again?

[ax3l]

Appveyor for Windows builds is not available anymore out of unknown reasons. Can this be enabled again?

Sure, dunno why it's off. Didn't you disable it after some issues?

[BenjaminW3]

Nope, it should correctly compile. At least it did some time ago.

[sbastrakov]

The issue at my machine seems to be that test\analysis\headerCheck\src\main.cpp present in the repo is deleted with this line and then it does not exist by the time the add_executables are called.
@BenjaminW3 is it supposed to be deleted and then should be somehow added back?

Btw also tried with CMake 3.12 with the same result.

[ax3l]

Is this issue related to #598 or yet another MSVC-specific one?

[BenjaminW3]

I am not sure if it is msvc specific. The main.cpp is in the test sources and should never be deleted. This command should delete the generated files in the build directory only. Are you doing an in source build?

[sbastrakov]

Yes, in source. So my cloned repo is c:/Code/alpaka and I do a cmake call from this directory and get the output presented in my first message in this issue. In that line FILE(REMOVE_RECURSE ${_GENERATED_SOURCE_DIR}) the value of ${_GENERATED_SOURCE_DIR} is then C:/Code/alpaka/test/analysis/headerCheck/src, which removes this file and then leads to the issue.

Tried building in a new directory, and then it is fine. So the issue is basically resolved. However, so that nobody else gets the same issue, is there a good reason to make an in source build fail - seems to be not hard to work around even the existing logic (e.g., even brute-force approach with coping that main.cpp before deleting a directory and then restoring it)? In any way, is it documented that now it is not allowed? I did not see it (but ofc maybe i was not reading carefully).

[ax3l]

We have an in-source build protection in PIConGPU that we can apply here as well.

[BenjaminW3]

Would prefer this as well. I am currently doing some kind of in source builds as well. I am building in alpaka/build. We could possibly whitelist build or _build subfolders.

[ax3l]

I build inside such dirs a lot as well. I think the PIConGPU check (strictly forbids in-source) can be used and should be extended that way

https://github.com/ComputationalRadiationPhysics/picongpu/blob/b9494e31aa436c2ffaabe0723608d93a494c556c/include/picongpu/CMakeLists.txt#L59-L76

[sbastrakov]

I don't have anything against an in-source build protection (maybe with a whitelist) in combination with documentation and messages, how it's done in PIConGPU. In my mind PIConGPU in-source protection is very logical, since each build is anyways related to a set of parameter files and such sets are better kept separate from the source code.

But for alpaka I don't see a strong reason to forbid in-source builds. And in case it is only a matter of personal preference, why (kinda artificially) forbid some choices.

[ax3l]

But for alpaka I don't see a strong reason to forbid in-source builds.

It's more considered a good (cmake, even configure) practice to avoid pollution of the source and to avoid problems as the one above.

[sbastrakov]

I see. Okay, the original issue is resolved and a potential adding of a guard against in-source builds should be a separate issue/PR, so closing this one.