Hello,
I have been working on improving the cmake language module for C# found here:
https://github.com/awakecoding/CMakeSharp
One thing that has me a bit flummoxed is how to implement the following:
CMAKE_CSharp_CREATE_SHARED_LIBRARY
CMAKE_CSharp_CREATE_SHARED_MODULE
On Mon, Apr 04, 2016 at 15:59:30 +, Dmitry Ivanov wrote:
> We have a strange situation where we do have too many include paths,
> which makes command line for obj compilation too long on windows (more
> 32kb).
> I've tried using set(CMAKE_NINJA_FORCE_RESPONSE_FILE 1), but
> apparently after
On 04.04.2016 18:38, Nils Gladitz wrote:
On 04.04.2016 17:59, Dmitry Ivanov wrote:
PS. Can we do something about bloated cmake ninja generator ? in our
case cmake generates 1.8 Mb Makefile and 84 Mb build.ninja, though
ninja is still faster than make even in this case.
Curious. Did you
On 04.04.2016 17:59, Dmitry Ivanov wrote:
PS. Can we do something about bloated cmake ninja generator ? in our
case cmake generates 1.8 Mb Makefile and 84 Mb build.ninja, though
ninja is still faster than make even in this case.
Curious. Did you count the accumulative size of all Makefile
Hi everyone,
We have a strange situation where we do have too many include paths, which
makes command line for obj compilation too long on windows (more 32kb).
I've tried using set(CMAKE_NINJA_FORCE_RESPONSE_FILE 1), but apparently after
checking cmake upstream I've realized that it's only
On Mon, Apr 04, 2016 at 09:07:09 +, melven.roehrig-zoell...@dlr.de wrote:
> After thinking about my patch I worried it could break other compilers.
> So, here is a more defensive version that shouldn't interfere with anything
> else.
>
> Explanation:
> CMAKE_Fortran_COMPILER_ID was correctly
After thinking about my patch I worried it could break other compilers.
So, here is a more defensive version that shouldn't interfere with anything
else.
Explanation:
CMAKE_Fortran_COMPILER_ID was correctly set to "GNU";
If CMAKE_Fortran_PLATFORM_IS is missing, run gfortran with a C file
->
