### Author:  [@Lectem](https://discourse.cmake.org/u/Lectem)
#### Post date: [March 24, 2020, 4:07pm UTC](https://discourse.cmake.org/t/ispc-language-support/673/21 "2020-03-24T16:07:15Z")
> [@marc.chevrier](#):
>
> No. `CMAKE__LINK_OPTIONS_NO_PIE` is not used by default. If `POSITION_INDEPENDENT_CODE` is not set ( `TRUE` or `FALSE` ), no flags are applied to link step.
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)
> [@marc.chevrier](#):
>
> To ensure consistency for the link step, define the variable `CMAKE_POSITION_INDEPENDENT_CODE` and include module `CheckPIESupport` in the root `CMakelist.txt` and call `check_pie_supported()` .
>
> variable `CMAKE_POSITION_INDEPENDENT_CODE` can take `TRUE` or `FALSE` :
>
> - set to `FALSE` : `gcc` and `ispc` will compile in their default mode ( `PIC` for gcc and `NO_PIC` for ispc) but the linker will specify `-fno_pie` so link will succeed.
> - set to `TRUE` : `gcc` and `ispc` will compile with option `-fPIC` and the linker will use option `-fpie` and the link will succeed.
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.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [March 24, 2020, 4:21pm UTC](https://discourse.cmake.org/t/ispc-language-support/673/22 "2020-03-24T16:21:25Z")
> [@Lectem](#):
>
> I’m writing a module to share/upstream later on
@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.
---
### Author:  [@Lectem](https://discourse.cmake.org/u/Lectem)
#### Post date: [March 24, 2020, 5:09pm UTC](https://discourse.cmake.org/t/ispc-language-support/673/23 "2020-03-24T17:09:47Z")
> [@brad.king](#):
>
> 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.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [March 24, 2020, 5:34pm UTC](https://discourse.cmake.org/t/ispc-language-support/673/24 "2020-03-24T17:34:13Z")
Right, that goes back to our [earlier discussion in this topic](https://discourse.cmake.org/t/673/8). 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.
---
### Author:  [@Lectem](https://discourse.cmake.org/u/Lectem)
#### Post date: [October 14, 2020, 8:37am UTC](https://discourse.cmake.org/t/ispc-language-support/673/25 "2020-10-14T08:37:28Z")
For anybody finding this thread, CMake 3.19 now has native support for ISPC! Though only for `make` and `ninja`
> [@CMake 3.19.0-rc1 is ready for testing](https://discourse.cmake.org/t/cmake-3-19-0-rc1-is-ready-for-testing/1996):
>
> I am proud to announce the first CMake 3.19 release candidate. [https://cmake.org/download/](https://cmake.org/download/) Documentation is available at: [https://cmake.org/cmake/help/v3.19](https://cmake.org/cmake/help/v3.19) Release notes appear below and are also published at [https://cmake.org/cmake/help/v3.19/release/3.19.html](https://cmake.org/cmake/help/v3.19/release/3.19.html) Some of the more significant changes in CMake 3.19 are: “cmake(1)” and “cmake-gui(1)” now recognize “CMakePresets.json” and “CMakeUserPresets.json” files. The “Xcode” generator now uses the Xcode “new build system” when gen…
---
### Author:  [@aneshlya](https://discourse.cmake.org/u/aneshlya)
#### Post date: [August 10, 2021, 11:46am UTC](https://discourse.cmake.org/t/ispc-language-support/673/26 "2021-08-10T11:46:59Z")
@robert.maynard, are there any plans to add ISPC support to VS generator?
---
### Author:  [@robert.maynard](https://discourse.cmake.org/u/robert.maynard)
#### Post date: [August 10, 2021, 12:29pm UTC](https://discourse.cmake.org/t/ispc-language-support/673/27 "2021-08-10T12:29:10Z")
I don’t work on ISPC support any longer.
@zackgalbreath Might be able to provide more information
[Previous page](https://discourse.cmake.org/t/ispc-language-support/673.md?page=1)