From a default cmd.exe I see cmake 3.9 correctly finding VS2017 when
specifying the VS Generator.
C:\test\build>C:\support\cmake-3.9.2\bin\cmake -G "Visual Studio 15 2017" ../src
-- The C compiler identification is MSVC 19.11.25508.2
-- The CXX compiler identification is MSVC 19.11.25508.2
-- Chec
Robert,
That certainly doesn't work for me - but maybe I'm doing something
non-standard.
If I don't source the vcvarsall.bat file, SDK installations (c:\Program Files
(x86)\Windows Kits\... and c:\Program Files (x86)\Microsoft SDKs\...) are not
found by CMake.
-kt
-Original Message-
You shouldn't need to import VS17 vcvarsall to use the VS17 Generator,
that should only be needed if using the MSYS or Ninja generators.
As far as building from the command line, the easiest route is to use
cmake --build --config
On Fri, Sep 15, 2017 at 3:05 PM, Thompson, KT wrote:
> Randy,
>
I have quite a few sub-projects in this project. I had added a few
projects on windows that statically linked to the runtime (to make the
product more portable). I realized yesterday that it was causing the
static runtime flags to be applied for all projects above it too (including
the core libra
WTH, apparently this can even happen without regeneration (that I know of, at
least):
%> CD kdevld-lnx-work/build/plugins/ wmake --MP -w
###
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins
### /home/bertin/script/wmake --MP -w
### Mon Se
Hi,
I'm seeing a weird issue with a large project: KDevelop. It was reorganised
recently but I think that's what exposes the issue, rather than causing it.
My workflow puts both source and out-of-source build directories rather deep in
a dedicated "playground"; for convenience I create symlinks
