I am using cmake 2.8.2 and I have added a custom configuration to my project
like this:
# Add configuration for debug pthreads builds based on the debug
configuration
#
=
set(CMAKE_C_FLAGS_DEBUGPTHREADS
Thanks for that link Michael. It doesn't please me, but I can confirm that
it does work :-) It's a nice hack around a deficiency in cmake. I ended up
using this code:
# First create a dummy library to hang the pthreads
# dependency on via the IMPORTED_LINK_INTERFACE_LIBRARIES property.
On 6 May 2011 01:12, Michael Hertling mhertl...@online.de wrote:
Yes, absolutely. Although setups with libraries which are needed in some
configurations only are quite rare, AFAIK, your case shows that this may
well happen. ;-) Possible - and more appropriate - solutions could be:
- New
I think you probably wanted to write and call your function like this:
FUNCTION(build var)
MESSAGE(STATUS var: ${var})
ENDFUNCTION(build)
SET(var red blue yellow green)
build(${var})
That prints out as you would expect:
-- var: red;blue;yellow;green
--
Glenn
On 12 May 2011 07:27,
I think that you can use an environment variable rather than a normal
variable to bypass the normal scoping rules. So:
set(ENV{foo} bar)
will I think allow other CMakeFiles to read it using:
$ENV{foo}
regardless of the sub-directory level. I haven't tried using this so it may
not work but I
I do exactly that for my project using these lines:
if(UNIX)
# only build 32-bit binaries
add_definitions(-m32)
set(CMAKE_EXE_LINKER_FLAGS${CMAKE_EXE_LINKER_FLAGS}
-m32)
set(CMAKE_SHARED_LIBRARY_C_FLAGS${CMAKE_SHARED_LIBRARY_C_FLAGS}
This is what I do:
# Add configuration for ReleaseNoOutfiles builds based on the release
configuration
#
=
set(CMAKE_C_FLAGS_RELEASENOOUTFILES
${CMAKE_C_FLAGS_RELEASE}CACHE STRING Flags used by the
A simple set of CMAKE_C_FLAGS or CMAKE_CXX_FLAGS will set the value for the
current directory and below:
set(CMAKE_C_FLAGS${CMAKE_C_FLAGS} -m32)
Any add_directory() commands after the above line will inherit the -m32
flag.
--
Glenn
On 5 June 2011 20:36, Richard Offer
On 13 June 2011 02:53, Michael Hertling mhertl...@online.de wrote:
AFAIK, there's no other approach to take account of single- and multi-
config generators at the same time for this purpose, but perhaps, you
could design the loop a bit smarter:
FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES
On 16 June 2011 15:45, Michael Hertling mhertl...@online.de wrote:
IMO, the default should not need to be explicitly enabled but the
exception, and readability - though important - is subordinate to
functionality, but probably, this is a matter of personal taste.
However, if you stick with
If the library you are trying to build is one that is totally under your
control then really it should be a subdirectory of your MY_APP source tree
so that you can call add_subdirectory() on it. If MY_LIB is shared across
multiple projects then you can always arrange for it to appear as a
Thanks for the clarification - I have a much clearer understanding now.
--
Glenn
On 18 June 2011 14:30, Michael Hertling mhertl...@online.de wrote:
COMPILE_DEFINITIONS is used *always*, i.e. for every generator in every
configuration, and COMPILE_DEFINITIONS_CONFIG is used *additionally*
in
For variables like CMAKE_C_FLAGS one can append to them like this:
set(CMAKE_C_FLAGS ${CMAKE_CFLAGS} -some_option)
For target properties like LINK_FLAGS I was using this command:
set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
/NODEFAULTLIB:LIBCMT)
to do the append. However, when
I have just started using some externally supplied cmake projects in my
cmake project. To do this I added these lines to my top level
CMakeLists.txt file:
include(ExternalProject)
ExternalProject_Add(external_proj
PREFIX${CMAKE_BINARY_DIR}/external_proj
SOURCE_DIR
If you can modify the subdirectory cmakefiles then maybe you could protect
the declaration of the uninstall target like this:
if (NOT TARGET uninstall)
add_custom_target(uninstall ...)
endif()
That way if the top level cmakefile declares an uninstall target it should
prevent the subdirectory
--target clean from the
command line then it does clean the project properly. Is
ExternalProject_Add() missing some functionality here, or have I
misunderstood something ?
--
Glenn
On 1 July 2011 18:01, David Cole david.c...@kitware.com wrote:
On Fri, Jul 1, 2011 at 7:23 AM, Glenn Coombs
on the
lower level makefile.
--
Glenn
On Wed, Jul 6, 2011 at 12:24 PM, David Cole david.c...@kitware.com wrote:
On Wed, Jul 6, 2011 at 12:17 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
On 5 July 2011 17:13, David Cole david.c...@kitware.com wrote:
It is (intentionally) missing some functionality
On 7 July 2011 15:15, David Cole david.c...@kitware.com wrote:
I'm sure that what you want to do is possible. I'm also sure that it's a
huge effort to get it to work with all CMake generators. It will also be
difficult to write a good test of the functionality.
Furthermore, I view it as
Have you tried using target_link_libraries(A D E F) in A/Deps.cmake instead
of add_dependencies ? I think that the add_dependencies command only
enforces a build order between targets. I don't think it actually adds
libraries to the link line.
On 18 July 2011 17:54, Marco Corvo
/Johan
On Mon, Jun 27, 2011 at 4:47 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
For variables like CMAKE_C_FLAGS one can append to them like this:
set(CMAKE_C_FLAGS ${CMAKE_CFLAGS} -some_option)
For target properties like LINK_FLAGS I was using this command:
set_property
Have a look at the documentation for CMAKE_RUNTIME_OUTPUT_DIRECTORY. On
Linux the .so shared library files do go in the LIBRARY_OUTPUT_DIRECTORY.
However, on Windows the DLL files are placed in the runtime directory and
only the import libraries (.LIB files) are placed in the
You could set the target property RUNTIME_OUTPUT_DIRECTORY on your library
targets. That would override the CMAKE_RUNTIME_OUTPUT_DIRECTORY variable
just for those targets.
2011/7/27 Laura Autón García laura.au...@gmail.com
Hello Alan,
Thank you very much for your answer.
It woks perfectly
http://public.kitware.com/Bug/view.php?id=6493
configuration dependent COMPILE_FLAGS for SET_TARGET_PROPERTIES
http://public.kitware.com/Bug/view.php?id=6269
Some CMake commands should support Debug/Release configurations
Previously with cmake 2.8.4 we were using these lines to compile an assembly
language file in our project:
if(UNIX)
enable_language(ASM)
# see if we are building 32-bit or 64-bit executables
file(WRITE ${CMAKE_BINARY_DIR}/check_32or64bit.cpp int main(int argc,
char *argv[]) { return 8 *
. Is there a cleaner way to do this
or is my current solution okay ?
2011/8/2 Alexander Neundorf a.neundorf-w...@gmx.net
Hi,
On Tuesday 02 August 2011, Glenn Coombs wrote:
Previously with cmake 2.8.4 we were using these lines to compile an
with 2.8.5 there was a major rework of the assembler support
Have you tried using the include_directories() command ? In your top level
CMakeLists.txt add a line like this:
include_directories(SWC1 SWC2 SWC3 Common)
before you do any add_subdirectory() commands.
Does that not add the appropriate -Ixxx flags to the compile command ? It
does for me but
if there is a method of doing the
same thing at module level (leaf CMakeLists.txt files) and propagate the
updates upwards in directory hierarchy.
Thanks again,
Andrei
On Wed, Aug 3, 2011 at 8:10 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
Have you tried using the include_directories() command
We do much the same but use a batch file called
startDevStudio.vs2010.cmake.bat like this in the top level:
@echo off
if not exist build\cmake mkdir build\cmake
cd build\cmake
cmake -G Visual Studio 10 ..\..\
IF ERRORLEVEL 1 (
echo.
echo CMake configure failed
echo.
harmless before. Should I file this
as a bug - or will it just be marked as not a bug, i.e. don't use double
quotes like that with add_definitions ?
--
Glenn
2011/8/3 Alexander Neundorf a.neundorf-w...@gmx.net
Hi,
On Wednesday 03 August 2011, Glenn Coombs wrote:
I tried changing from ASM
Probably too late now and there isn't a bug filed so far as I know, but one
thing I would love to see added to cmake is an append command so that lines
like this:
set(CMAKE_EXE_LINKER_FLAGS_RELEASE ${CMAKE_EXE_LINKER_FLAGS_RELEASE}
/INCREMENTAL:NO)
become shorter and easier to understand:
Something like this:
if (MSVC)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS}
/FORCE:Multiply)
endif()
in your top level CMakeLists.txt should do the trick. I think the /W0 flag
will suppress any warnings. This would need to be added to CMAKE_C_FLAGS
and/or CMAKE_CPP_FLAGS in a
:34, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2011-08-09 17:19+0100 Glenn Coombs wrote:
Probably too late now and there isn't a bug filed so far as I know, but
one thing I would love to see added to cmake is an append command
so that lines like this:
set(CMAKE_EXE_LINKER_FLAGS_
Add the sub dependencies that library A has with target_link_libraries():
target_link_libraries(A png)
--
Glenn
On 11 August 2011 10:02, Doug douglas.lin...@gmail.com wrote:
Hrm... this seems like something cmake should be able to do, but I don't
know how to make it work.
If I have
change my build target.
Sure I can do a giant IF(TARGET MATCHES Android) ... ENDIF, which I guess
is what I will do for now, but it seems like a poor solution.
Edit: woops; ment that to go to the list.
~
Doug.
On Thu, Aug 11, 2011 at 7:39 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
Add
Out of all the suggestions so far I'd like to say that my preferred solution
is Michael's one of:
SET(variable value ... CONCAT [SEP sep])
I haven't seen any discussion yet of my 2nd alternative of getting cmake to
automatically convert lists to space separated strings for certain variables
Which is precisely the sort of thing that started this whole discussion :-)
In the same way that C/C++ would still work without the += operator it does
allow a wonderful conciseness that I miss on occasion. Especially given
cmake's propensity for verbose variable names.
On 13 August 2011 10:22,
On 15 August 2011 20:23, Albert Meltzer buls...@gmail.com wrote:
Maybe the esteemed colleagues would suggest another good and reliable way
to handle situations such as this:
IF (lang STREQUAL perl) ...
ELSEIF(lang STREQUAL python) ...
ELSEIF()
...
ENDIF ()
without having to SET(perl
. But that would break the backwards
compatibility rule. Are there any cmake variables where real semicolons
need to be passed through to the compiler/linker ?
--
Glenn
On 15 August 2011 12:56, David Cole david.c...@kitware.com wrote:
On Aug 13, 2011, at 5:14 AM, Glenn Coombs glenn.coo...@gmail.com
What you can do however is set the variable which uses the FLAGS
definition, i.e. CMAKE_C_COMPILE_OBJECT in your example. I have a
CMakeLists.txt file where I override the default assembler flags:
set(CMAKE_ASM-ATT_COMPILE_OBJECT CMAKE_ASM-ATT_COMPILER ${ASM_SYS_FLAGS}
-o OBJECT SOURCE)
to use
Could you not create a file in each subdirectory called something like
header-deps.cmake ? This file would contain the include_directory()
commands necessary for using this module, plus include() commands of other
modules that it depends on. So for your example:
# utils/b/header-deps.cmake
”)
** **
but then the –DDEBUG is missing for the build of mylibd. I guess both
mylibd and mylib use CMAKE_C_COMPILE_OBJECT and I need a way to pass the
–DDEBUG to the compile of one and not the other.
** **
-David
** **
*From:* Glenn Coombs [mailto:glenn.coo...@gmail.com]
*Sent:* Wednesday
of mylibd. I guess both
mylibd and mylib use CMAKE_C_COMPILE_OBJECT and I need a way to pass the
–DDEBUG to the compile of one and not the other.
-David
*From:* Glenn Coombs [mailto:glenn.coo...@gmail.com]
*Sent:* Wednesday, September 07, 2011 4:19 AM
*To:* David Cole
Calling a function pushs a new variable scope. All variables visible in the
callers scope are copied into the new scope but changes by default only
affect the callee scope. You could try using the PARENT_SCOPE option to the
set command but I'm not sure that will achieve what you want as it only
Hi,
I've just had a CMakeLists.txt fail to work as expected because somebody was
testing to see whether an environment variable was set with the syntax: if
(DEFINED $ENV{VAR}). This short example shows the problem:
cmake_minimum_required(VERSION 2.8)
project(foo)
message(HOME: $ENV{HOME})
if
Doh :-) Thanks for pointing out what should perhaps have been obvious in
retrospect. Cache variables are one of the more confusing areas of cmake.
--
Glenn
On 10 October 2011 22:38, Bill Hoffman bill.hoff...@kitware.com wrote:
On 10/10/2011 3:52 PM, Robert Dailey wrote:
Yes, this works
Yes, that did help. Works perfectly without the $ character.
--
Glenn
On 11 October 2011 19:55, Michael Wild them...@gmail.com wrote:
On 10/11/2011 06:02 PM, Glenn Coombs wrote:
Hi,
I've just had a CMakeLists.txt fail to work as expected because somebody
was testing to see whether
We have recently switched from cvs to perforce and encountered the same
problem. In our case the fix was to change the CMakeList.txt file to refer
directly to the file in the source tree rather than first copying it to the
build tree and then referring to it there. As the clean command only
under load
(in C, when stack will be over).
That's why I didn't insist on changing behavior when found this bug 3
years ago.
On Tue, Jan 31, 2012 at 8:02 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
On a related note:
http://www.gccxml.org/Bug/view.php?id=12437
can you check if ITK and VTK
I need to test for the presence of a directory called driver_root. I
couldn't see a find_directory() command in the help so I am using the
following lines in my CMakeLists.txt:
message(1 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})
if (DEFINED ENV{DRV_ROOT})
find_file(DRV_ROOT_CHECK
an
incorrect match.
--
Glenn
On 3 September 2012 09:58, Adolfo Rodríguez Tsouroukdissian
adolfo.rodrig...@pal-robotics.com wrote:
On Tue, Aug 28, 2012 at 6:59 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
I need to test for the presence of a directory called driver_root. I
couldn't see
Hi,
I just installed the Visual Studio 2012 Express edition for Windows Desktop
and cmake 2.8.9 is having some issues with it. Initially when I ran the
cmake configure step it failed to find the devenv or msbuild program:
CMake was unable to find a build program corresponding to Visual Studio
Thanks for that - I will try it again with the 2.8.10 release candidate.
--
Glenn
On 18 September 2012 22:17, David Cole david.c...@kitware.com wrote:
On Mon, Sep 17, 2012 at 1:02 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
Hi,
I just installed the Visual Studio 2012 Express edition
-robotics.com
http://www.cmake.org/mailman/listinfo/cmake wrote:
* On Tue, Aug 28, 2012 at 6:59 PM, Glenn Coombs glenn.coombs at
gmail.com http://www.cmake.org/mailman/listinfo/cmakewrote: I
need to test for the presence of a directory called driver_root. I**
couldn't see
I am invoking cmake as part of a jenkins script and am using cmake --build
. to kick off the build. This works but does not do the equivalent of
make -j4 to take advantage of all 4 cores when run on a linux machine.
When run on a windows machine the building in parallel is already taken
care of
http://www.cmake.org/Bug/view.php?id=12437 (do not set default stacksize of
10MB for Visual Studio)
--
Glenn
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
Hi,
I have a Qt4 program that I'm working on and ran into an issue yesterday
with the automoc cpp files. I had added a new slot and connected a
comboxbox currentIndexChanged signal to it but when I ran the program I
could see messages on stdout complaining that my slot didn't exist. I
tracked
wrote:
On Thursday 25 April 2013, Glenn Coombs wrote:
Hi,
I have a Qt4 program that I'm working on and ran into an issue yesterday
with the automoc cpp files. I had added a new slot and connected a
comboxbox currentIndexChanged signal to it but when I ran the program I
could see
No, cleaning the project didn't remove that file.
--
Glenn
On 26 April 2013 17:28, Alexander Neundorf a.neundorf-w...@gmx.net wrote:
On Friday 26 April 2013, Glenn Coombs wrote:
No, the yuv_player_automoc.cpp file is not removed on a clean (nor are
the
other moc_*.cpp files). Having just
Neundorf a.neundorf-w...@gmx.net wrote:
On Sunday 28 April 2013, Glenn Coombs wrote:
No, cleaning the project didn't remove that file.
Can you manually set the ADDITIONAL_MAKE_CLEAN_FILES directory property to
some file and check whether this file is deleted when you clean ?
Something like
, Alexander Neundorf a.neundorf-w...@gmx.net wrote:
On Monday 29 April 2013, Glenn Coombs wrote:
I added these lines:
set_directory_properties(
PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
${CMAKE_CURRENT_BINARY_DIR}/abc.txt
)
# check the location where abc.txt is supposed to be deleted
Alex,
Would you like me to file a bug report on this ?
--
Glenn
On 1 May 2013 08:33, Glenn Coombs glenn.coo...@gmail.com wrote:
I select Clean Solution from the Build menu which is a complete clean.
The output looks like this:
1-- Skipped Clean: Project: INSTALL, Configuration: Debug
I won't bother just yet then. Let me know if I can be of any help in
testing your fix.
BTW, is your fix likely to make it into the pending 2.8.11 release ?
--
Glenn
On 5 May 2013 19:33, Alexander Neundorf a.neundorf-w...@gmx.net wrote:
On Sunday 05 May 2013, Glenn Coombs wrote:
Alex
The regexp you're using matches anything where the last character at the
end of the line isn't one of the characters inside the square brackets. I
don't think cmake's regexps allow negation of words so specifying a regexp
that matches everything except projectA/, README and CMakelists.txt is
I'm using cmake version 2.8.12.1 and have just encountered an issue with my
cmake setup where I was using the [Project name]_SOURCE_DIR variable in an
include_directories command and it was being ignored. In my top level
CMakeLists.txt I had:
project(blah)
add_subdirectory(foo)
consistent behaviour IMHO.
--
Glenn
On 28 April 2014 19:33, Matthew Woehlke mw_tr...@users.sourceforge.netwrote:
On 2014-04-23 14:18, Glenn Coombs wrote:
Are the [Project name]_SOURCE_DIR variables being automatically stored in
the cmake cache?
Running 'grep _SOURCE_DIR CMakeCache.txt
What I am saying is that project(foo) should internally execute the
equivalent of set(foo_SOURCE_DIR /path/to/source) rather than set(foo
/path/to/source CACHE STRING). That way it would fail on every run if
you referenced a project source directory variable before you had done the
on the first
run but do on subsequent runs.
On 1 May 2014 19:00, John Drescher dresche...@gmail.com wrote:
On Thu, May 1, 2014 at 1:54 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
What I am saying is that project(foo) should internally execute the
equivalent of set(foo_SOURCE_DIR /path
Ugh ! It gets messier. I'm beginning to understand why it is the way it
is. The cmake developers have probably already been round this loop and
decided it wasn't worth the effort :-)
On 1 May 2014 19:41, Nils Gladitz nilsglad...@gmail.com wrote:
On 01.05.2014 20:38, Glenn Coombs wrote
This seems to be the recommended way to link against the zlib library:
find_package(ZLIB)if (ZLIB_FOUND)
include_directories(${ZLIB_INCLUDE_DIRS})
target_link_libraries(MyProg ${ZLIB_LIBRARIES})
endif()
When I run this on linux I see that ZLIB_LIBRARIES has the value
/usr/lib64/libz.so.
wrote:
Am Dienstag, 24. Juni 2014, 22:32:22 schrieb Glenn Coombs:
This seems to be the recommended way to link against the zlib library:
find_package(ZLIB)if (ZLIB_FOUND)
include_directories(${ZLIB_INCLUDE_DIRS})
target_link_libraries(MyProg ${ZLIB_LIBRARIES})
endif()
When I
I have a project which compiles and links into both a stand alone
executable and a dynamic shared library. The library and the executable
link against the same project libraries but have different object files
containing their entry points: main.o for the executable and dll_main.o for
the
Don't all shout at once :-) I'm guessing there are no easy solutions
then...
--
Glenn
On 28 June 2014 14:33, Glenn Coombs glenn.coo...@gmail.com wrote:
I have a project which compiles and links into both a stand alone
executable and a dynamic shared library. The library and the executable
).
All the best,
Angeliki
On Sat, Jul 19, 2014 at 2:39 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
Don't all shout at once :-) I'm guessing there are no easy solutions
then...
--
Glenn
On 28 June 2014 14:33, Glenn Coombs glenn.coo...@gmail.com wrote:
I have a project which
you have.
Cheers!
Angeliki
On Mon, Jul 21, 2014 at 7:05 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
The problem is that I need to add both -whole-archive and
-no-whole-archive options. And I need to control exactly where they occur
so that only my libraries occur inside the whole
I think this works like you want:
cmake_minimum_required(VERSION 2.6)
set(DO_RELAX 1)
if(DO_RELAX)
set(OR_RELAX || echo \no big deal\)
else()
set(OR_RELAX)
endif()
add_custom_command(OUTPUT foo COMMAND generate-foo ${OR_RELAX} VERBATIM)
add_custom_target(do-foo ALL DEPENDS foo)
--
I think that you can use the target_link_libraries command to do this:
add_library(A a.cpp)
target_link_libraries(A INTERFACE -custom-flags)
--
Glenn
On 30 July 2014 16:51, Adrian M Negreanu gro...@gmail.com wrote:
Hi,
Is it possible to attach a property on a target, and that property
to
.
On 07/29/2014 12:25 PM, Glenn Coombs wrote:
I think this works like you want:
cmake_minimum_required(VERSION 2.6)
set(DO_RELAX 1)
if(DO_RELAX)
set(OR_RELAX || echo \no big deal\)
else()
set(OR_RELAX)
endif()
add_custom_command(OUTPUT foo COMMAND generate-foo ${OR_RELAX
If you know which version of cmake first introduced the feature you want to
check for then you could base your decision on the values of these 3 cmake
variables:
CMAKE_MAJOR_VERSION
CMAKE_MINOR_VERSION
CMAKE_PATCH_VERSION
--
Glenn
On 5 August 2014 04:30, Leif Walsh leif.wa...@gmail.com wrote:
Hope that helps! Also for future googling the concept is called Usage
Requirements.
On Aug 2, 2014 8:11 AM, Glenn Coombs glenn.coo...@gmail.com wrote:
I think that you can use the target_link_libraries command to do this:
add_library(A a.cpp)
target_link_libraries(A INTERFACE -custom-flags
In my opinion this is a deficiency in how cmake currently works with object
libraries. If one of the source files in an object library depends on a
third library then it should be possible to specify that in the link
interface of either the object library or the source file. It is wrong to
have
I have the following code in one of my CMakeLists.txt files:
set(feature_files_h)
set(feature_files_cpp)
macro(create_feature_files NAME)
add_custom_command(
OUTPUT ${FEATURES_OUTPUT_DIR}/${NAME}.cpp
${FEATURES_OUTPUT_DIR}/${NAME}.h
DEPENDS ${FEATURES_INPUT_DIR}/${NAME}.txt
...@kitware.com
wrote:
If you are using VS2013 you should look at the /maxcpucount flag which
allows msbuild to build multiple projects at the same time. You will
have to manually balance /MP and /maxcpucount as they cause a P*C
number of processes to execute.
On Tue, Sep 23, 2014 at 11:05 AM, Glenn
Hi,
I have installed Boost on Windows 7 for Visual Studio 2013 by running these
installers:
boost_1_56_0-msvc-12.0-32.exe
boost_1_56_0-msvc-12.0-64.exe
downloaded from
http://sourceforge.net/projects/boost/files/boost-binaries/1.56.0/.
I'm using CMake 2.8.12.1 and when I try to build a simple
and
BOOST_LIBRARYDIR automatically in some cases.
https://gist.github.com/rpavlik/586f1fda6e32777623e1
Ryan
On Fri, Nov 14, 2014 at 6:56 AM, Glenn Coombs glenn.coo...@gmail.com
wrote:
Hi,
I have installed Boost on Windows 7 for Visual Studio 2013 by running
these installers:
boost_1_56_0-msvc
If you run make help it will list targets it understands. And as you
pointed out there is no target for foo.cc. You can make foo but if you
really want a target for foo.cc you can add one yourself:
cmake_minimum_required(VERSION 3.0.0)
project(custom-command-target)
add_custom_command (
will investigate further but it could be just what I need.
--
Glenn
On 30 June 2015 at 22:34, Stephen Kelly steve...@gmail.com wrote:
Glenn Coombs wrote:
I am getting the error in the subject. The code I have looks like this:
if (PRE_COMPILED_HEADERS_FOUND
I don't think policies are sufficient. I just tried using the new
target_sources command that was introduced in CMake 3.1.0 in a
CMakeLists.txt file that specified cmake_minimum_required(VERSION 3.0) and
it didn't warn that the CMakeLists.txt file wouldn't work with CMake 3.0.
I think if you want
I am getting the error in the subject. The code I have looks like this:
if (PRE_COMPILED_HEADERS_FOUND)
ADD_PRECOMPILED_HEADER(${header_pch} ${source_pch} sources systemc)
endif()
add_library(systemc ${sources} ${sources_no_pch} ${headers})
where the call to add_dependency
88 matches
Mail list logo
