All,
My FLTK EmbeddedProject woes are solved. As it turns out, the path of
least resistance was the one I hadn't tried
While the FLKT CMake files were indeed out of date, they weren't that bad.
Fixing them was by far the best solution.
I have a few more libraries for my project, but hopefu
Bill,
I've scoured those examples and read the documentation many times. I'm
also making pretty (perhaps overly) complex use of ExternalProject_Add.
I should have been more specific in my request for tips.
I have not found examples of ExternalProject driving Visual Studio projects
or nmake file
Hi all,
We have a 3rd-party project that builds on multiple OSes via CMake, with
one of them being VxWorks using a custom toolchain (fairly specific to our
platform/tools). This project consists of multiple shared libraries with a
fairly complex hierarchy,
All of this was working just fine unt
All of that is available from selecting a generator and toolset for
your machine;
cmake uses the registry to find devenv to build visual studio projects
--- part I stole to make sure it uses msbuild.exe in favor of devenv.com ---
if( MSVC10 )
IF(NOT CMAKE_CROSSCOMPILING)
FIND_PROGRAM(REAL_CMAKE
All,
Thanks for all the help, I'm getting closer. My current approach does
this
CMAKE_MINIMUM_REQUIRED( VERSION 2.8 )
INCLUDE( ExternalProject )
SET( VS_MAKEFILE_ZIP vsnet-makefiles.0.85.zip )
IF( MSVC )
IF( MSVC_VERSION EQUAL 1200 )
SET( VS_TOOLS_PATH $ENV{VS60COMNTOOLS} )
SET(
Hello,
On a Cray XE6, I am using find_package(MPI REQUIRED) in my CMakeLists.txt. It
correctly finds all of the MPI stuff, except that it sets the MPIEXEC to the
login node mpiexec command. I would like to override this behavior and set the
MPIEXEC command to the "aprun" wrapper, but it is not
But using BUILD_COMMAND() you can get the appropriate build command,
the full path ends up specified; it is determined duing the cmake
configuration phase and would be the same; hence the same script I
showed worked to build makeit.bat that runs Linux GCC Make, MinGW
Make, Watcom Make, Visual Studi
On 1/9/2014 1:48 PM, Rob McDonald wrote:
Correct, this is one of the concerns that makes it more complex than
just searching for the first vcvarsall.bat you come to.
I'd like to match up the vcvarsall to the version of visual studio
currently in use by CMake.
I think there are now enough pieces
Correct, this is one of the concerns that makes it more complex than just
searching for the first vcvarsall.bat you come to.
I'd like to match up the vcvarsall to the version of visual studio
currently in use by CMake.
I think there are now enough pieces that I can write a CMake
'FindVSEnvironmen
I've got a batch file that does something like this to detect the "most
recent" available Visual Studio:
@rem ** Add "Developer Command Prompt" for VS2013, 2012 or 2010
environment:
@set _vsver=
@set _vs12env=%VS120COMNTOOLS%VsDevCmd.bat
@if "%_vsver%" equ "" if exist "%_vs12env%" set _vsver=
Each Visual Studio sets a environment variable that helps you locate the
installed location. So for Visual Studio 2008 it is VS90COMNTOOLS, and for
Visual Studio 2010 it is
VS100COMNTOOLS. So you can have a single bat file that is configured by
cmake to determine both the correct env variable to us
> Why not just write your own batch ('buildit.bat') file that does:
>
>call vcvarsall.bat
>nmake
>
> (or whatever the command to build in the VS command prompt is...)
>
> And then your command to build is:
>
>C:/full/path/to/buildit.bat
>
> It's presumably in a Windows-specific chunk of
Why not just write your own batch ('buildit.bat') file that does:
call vcvarsall.bat
nmake
(or whatever the command to build in the VS command prompt is...)
And then your command to build is:
C:/full/path/to/buildit.bat
It's presumably in a Windows-specific chunk of your CMakeLists a
13 matches
Mail list logo
