Ok so that’s what I expected, by default, it will do nothing and let the linker use its default. (which is here, use PIE)
I do understand how to use it from the point of view of the user, but I’m writing a module to share/upstream later on.
I do not have control over CMAKE_POSITION_INDEPENDENT_CODE and I do not want to set it in my module.
Indeed it works if it is either set to TRUE or FALSE, but I don’t think I should enforce that onto the users ?
I mean, we could just say that it’s a problem of configuration on the given system, but I think it’s kind of bad that the user himself has to chime in and set CMAKE_POSITION_INDEPENDENT_CODE manually on such a system.
Ultimately, what I do need is to detect if the linker uses PIE or not by default (by that, I mean without giving it any flag, regardless of CMake variables), which seems to be hard. I suppose the only way to do it is to try_compile with and without ispc’s --pic flag, and see if it really is required or not by default.
@Lectem I don’t expect we will upstream a module-only/custom-command-based implementation of ISPC language support. An upstream implementation will be likely able to access the information it needs in the C++ generator implementations.
I see, but then it means work needs to be done wrt. to generated source files right ?
I don’t think I have enough experience/time with CMake internals to implement this sadly.
Right, that goes back to our earlier discussion in this topic. I don’t expect you to solve those problems or get an upstream-able implementation working. The fully-external approach should work well enough for now pending some separate future dedicated upstream effort.