Re: [CMake] find_program doesn't use the PATH
On Wed, 2019-07-31 at 20:32 +0200, Kornel Benko wrote: > The find_program() is searching something like "/usr/bin/NAME". > "NAME" should be a placeholder. > What you had in mind was probably the second form > find_program(GETTEXT_MSGMERGE_EXECUTABLE NAMES msgmerge) > Mark the string "NAMES". Oh, good grief. Sigh. Thanks for catching that. -- Braden McDaniel -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[CMake] find_program doesn't use the PATH
I was tempted to go ahead and file a bug on this; but it seems so basic
that I figure I must be missing something.
Per the documentation for find_program:
If NO_DEFAULT_PATH is not specified, the search process is as
follows:
⋮
5. Search the standard system environment variables. This can be
skipped if NO_SYSTEM_ENVIRONMENT_PATH is an argument.
* PATH
That indicates to me that for "find_program(PROG_VAR NAME foo)", CMake
ought to find "foo" if "foo" is in the PATH. That doesn't seem to be
the case, though. A concrete example:
cmake_minimum_required(VERSION 3.0)
cmake_policy(SET CMP0048 NEW)
project("hello" VERSION 0.1.0 LANGUAGES C)
find_program(GETTEXT_MSGMERGE_EXECUTABLE NAME msgmerge)
message(STATUS "GETTEXT_MSGMERGE_EXECUTABLE =
${GETTEXT_MSGMERGE_EXECUTABLE}")
add_executable(hello hello.c)
This outputs:
$ cmake -G "Unix Makefiles" ~/src/hello
-- GETTEXT_MSGMERGE_EXECUTABLE = GETTEXT_MSGMERGE_EXECUTABLE-NOTFOUND
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mcdanb/build/hello
$ which msgmerge
/usr/bin/msgmerge
I am using CMake 3.14.5.
Have I misunderstood the documentation on this point?
--
Braden McDaniel
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] How to support separate debug and release build directories?
On Fri, 2019-06-21 at 15:28 +0100, David Aldrich wrote: > > > I would also like this to work if I use the make targets e.g. > > make > > > debug. > > > > I think that's outside the scope of the Makefile generator. For > > that > > generator, CMAKE_BUILD_TYPE is a configuration-wide setting. If > > you > > want a different configuration, you need a different build > > directory > > (where "build directory" is wherever you run cmake). > > If I don't use make targets (so that user can type 'make debug' etc) > the build command would be more cumbersome: > > cmake3 --build -D CMAKE_BUILD_TYPE=Debug . Assuming that command actually triggers a reconfigure (when previously configured with a different CMAKE_BUILD_TYPE), you'll most likely hose incremental builds of the other build type(s). (And if it doesn't trigger a reconfigure in that case, it's pretty certainly not doing what you want.) > What would best practice be to provide convenient commands for our > developers to easily build the target ? For the Makefile generator, best practice is to use separate build directories (i.e., places where you run cmake) for different configurations (i.e., different settings recorded during the configuration step). If you want to provide developers with some known set(s) of configuration settings, I suggest wrapper scripts that invoke cmake with those settings. -- Braden McDaniel -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] How to support separate debug and release build directories?
On Fri, 2019-06-21 at 14:19 +0100, David Aldrich wrote:
> Thanks for the help I have received in the past few days. I am making
> incremental improvements to my CMake project and have a new
> challenge. I am running CMake 3.13 on Centos 7.6, targeting make.
> My CMake file successfully builds debug or release targets and puts
> the executable in an out-of-source build directory. I have added
> debug and release make targets so I can execute 'make debug' etc.
>
> I now want to support separate target directories: build/debug and
> build/release. I've shown my CMakeLists.txt below. So far I've just
> added an attempt to support build/debug:
>
> if (CMAKE_BUILD_TYPE EQUAL "DEBUG")
> message("debug mode")
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/debug)
> endif (CMAKE_BUILD_TYPE EQUAL "DEBUG")
>
> but:
>
> $ cmake3 -DCMAKE_BUILD_TYPE=DEBUG ..
>
> puts the target into build, not build/debug.
The conventional solution to this is to run cmake in the "build/debug"
directory.
> I would also like this to work if I use the make targets e.g. make
> debug.
I think that's outside the scope of the Makefile generator. For that
generator, CMAKE_BUILD_TYPE is a configuration-wide setting. If you
want a different configuration, you need a different build directory
(where "build directory" is wherever you run cmake).
--
Braden McDaniel
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_OSX_DEPLOYMENT_TARGET vs CMAKE_OSX_SYSROOT
On Sun, 2016-09-25 at 11:54 +0200, Gregor Jasny wrote: > On 23/09/2016 22:35, Gregor Jasny wrote: > > > > On 20 Sep 2016, at 16:00, Braden McDaniel <bra...@endoframe.com > > > > > wrote: > > > > > > > > When setting CMAKE_OSX_SYSROOT to the unversioned directory > > > > name (using Xcode 8, as it happens) and setting > > > > CMAKE_OSX_DEPLOYMENT_TARGET, I get this error: > > > > > > > > > > > > -- The CXX compiler identification is AppleClang 8.0.0.838 > > > > CMake Error at /Applications/CMake.app/Contents/share/cmake- > > > > 3.6/Modules/Platform/Darwin.cmake:76 (message): > > > > CMAKE_OSX_DEPLOYMENT_TARGET is '10.10' but CMAKE_OSX_SYSROOT: > > > > > > > > "/Applications/Xcode- > > > > 8.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SD > > > > Ks/MacOSX.sdk" > > > > > > > > is not set to a MacOSX SDK with a recognized version. Either > > > > set > > > > CMAKE_OSX_SYSROOT to a valid SDK or set > > > > CMAKE_OSX_DEPLOYMENT_TARGET to > > > > empty. > > > > Call Stack (most recent call first): > > > > /Applications/CMake.app/Contents/share/cmake- > > > > 3.6/Modules/CMakeSystemSpecificInformation.cmake:36 (include) > > > > CMakeLists.txt:37 (project) > > > > > > > > > > > > I'm able to suppress the error by using the versioned (symlink) > > > > directory; but isn't the premise of this error message invalid? > > > > As I understand it, since Xcode 7 (or perhaps earlier?), there > > > > is no requirement that the deployment target match the SDK > > > > version. > > The deployment target gives you backwards compatibility back to the > specified version. In your example the binary should be runnable on > macOS 10.10 and later even that you used a newer SDK. That way you > have > access to the latest SDK features which you could use after a > thorough > check at runtime. Yes, that squares with my understanding of the current semantics. Interestingly, in Xcode 8, the versioned SDK directory is actually a symlink to the unversioned one. It would not surprise me if the versioned SDK directory went away altogether in a future release; this version number is moot with the current semantics. > I filed https://gitlab.kitware.com/cmake/cmake/issues/16323 and will > push a fix soon. Thanks! -- Braden McDaniel <bra...@endoframe.com> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] CMAKE_OSX_DEPLOYMENT_TARGET vs CMAKE_OSX_SYSROOT
When setting CMAKE_OSX_SYSROOT to the unversioned directory name (using Xcode 8, as it happens) and setting CMAKE_OSX_DEPLOYMENT_TARGET, I get this error: -- The CXX compiler identification is AppleClang 8.0.0.838 CMake Error at /Applications/CMake.app/Contents/share/cmake-3.6/Modules/Platform/Darwin.cmake:76 (message): CMAKE_OSX_DEPLOYMENT_TARGET is '10.10' but CMAKE_OSX_SYSROOT: "/Applications/Xcode-8.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk" is not set to a MacOSX SDK with a recognized version. Either set CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to empty. Call Stack (most recent call first): /Applications/CMake.app/Contents/share/cmake-3.6/Modules/CMakeSystemSpecificInformation.cmake:36 (include) CMakeLists.txt:37 (project) I'm able to suppress the error by using the versioned (symlink) directory; but isn't the premise of this error message invalid? As I understand it, since Xcode 7 (or perhaps earlier?), there is no requirement that the deployment target match the SDK version. Braden -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMake 3.0.2 check_include_files can't find include files in Mac OS X
On Sun, 2015-02-01 at 22:56 +0100, NoRulez wrote: I've my SDK under /Developer/SDKs/MacOSX10.7.sdk. You need to set CMAKE_OSX_SYSROOT to that path. It's surprising you were able to get very far at all without that; perhpas CMAKE_OSX_SYSROOT got set to something else (you definitely don't want that). -- Braden McDaniel bra...@endoframe.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] whole archive linkage
On Sat, 2015-01-24 at 13:41 +1000, Adam wrote: The library contains a static which registers itself in its constructor. This problem is described here http://stackoverflow.com/a/842770 As something of an aside to your question, I don't know that I accept that as a sane use case. C++ doesn't guarantee that (in that example) m will be constructed before h. If m is not constructed first, construction of h calls operator[] on an uninitialized object. -- Braden McDaniel bra...@endoframe.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Get the BINARY_DIR for a target?
On Tue, 2015-01-06 at 12:34 -0500, Braden McDaniel wrote: Are there any properties on a target that I can query to get whatever was the CMAKE_CURRENT_BINARY_DIR when the target was defined? I'm aware of the LOCATION property; however, its generator-specific nature makes teasing the non-generator-specific part out of it rather challenging (without some other information about the target definition's location in the source tree, which is specifically what I'm trying to avoid). FWIW, I'm writing a function that takes a list of targets as input. It looks like I can add my own arbitrary property for this. So, my current solution is to wrap add_library with my own function that calls add_library and then sets MY_SPECIAL_PROPERTY on the target to the current value of CMAKE_CURRENT_BINARY_DIR. Later, I get the value of MY_SPECIAL_PROPERTY inside the function I described in my previous message. If someone knows of a better way, do tell. -- Braden McDaniel bra...@endoframe.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Get the BINARY_DIR for a target?
Are there any properties on a target that I can query to get whatever was the CMAKE_CURRENT_BINARY_DIR when the target was defined? I'm aware of the LOCATION property; however, its generator-specific nature makes teasing the non-generator-specific part out of it rather challenging (without some other information about the target definition's location in the source tree, which is specifically what I'm trying to avoid). FWIW, I'm writing a function that takes a list of targets as input. -- Braden McDaniel bra...@endoframe.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Interaction between source COMPILE_FLAGS and directory COMPILE_OPTIONS
On Wed, 2014-11-19 at 22:55 +, Braden McDaniel wrote: The documentation for the source property COMPILE_FLAGS describes it as, Additional flags to be added when compiling this source file. However, when using the Visual Studio 2013 generator (at least), it appears to replace (rather than complement) the options added via the directory property COMPILE_OPTIONS. It (i.e., source COMPILE_FLAGS) also replaces options added by setting the CMAKE_LANG_FLAGS variable. Is this the intended behavior? Actually, let me amend this a bit... Upon further testing, the flags that seem to be affected are the ones that disable warnings (i.e., /wd). That is, if I add these flags in the source COMPILE_FLAGS, they replace any /wd flags specified in the directory COMPILE_OPTIONS. AFAICT so far, other flags in the directory COMPILE_OPTIONS are left intact. I am using CMake 3.0.2. -- Braden McDaniel bra...@endoframe.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Interaction between source COMPILE_FLAGS and directory COMPILE_OPTIONS
The documentation for the source property COMPILE_FLAGS describes it as, Additional flags to be added when compiling this source file. However, when using the Visual Studio 2013 generator (at least), it appears to replace (rather than complement) the options added via the directory property COMPILE_OPTIONS. It (i.e., source COMPILE_FLAGS) also replaces options added by setting the CMAKE_LANG_FLAGS variable. Is this the intended behavior? Braden -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] add_custom_command and CONFIG-dependent output
On Fri, 2014-08-22 at 16:58 -0400, David Cole via CMake wrote:
Use ${CMAKE_CFG_INTDIR} in the context of add_custom_command OUTPUT,
not $CONFIG.
You may also use that in the COMMAND arguments.
See documentation here:
http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_CFG_INTDIR.html
The $ generator expressions are relatively new, and do not work in
all contexts that you might expect yet. CMAKE_CFG_INTDIR has been
around for quite some time, though, and works very well with custom
commands.
Ah, thanks... Though, I think there may be a general disconnect here:
that is, it seems likely that one would want to construct output with a
pattern composed from generator expressions. For instance, in a
subsequent rule I attempted to do this:
set(LIB $TARGET_FILE:${LIBRARY_TARGET})
set(STAGED_LIB ${LIB_STAGEDIR}/$TARGET_FILE_NAME:${LIBRARY_TARGET})
add_custom_command(
OUTPUT ${STAGED_LIB}
COMMAND ${CMAKE_COMMAND} -E copy ${LIB} ${STAGED_LIB}
MAIN_DEPENDENCY ${LIB_STAGEDIR}
)
... which obviously has the same problem.
While I gather from your comment that something like this might be
possible in the future, is there some other general approach that can be
taken with current CMake?
Braden
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] add_custom_command doesn't know about target; but get_target_property does
On Fri, 2014-08-22 at 12:37 +0200, Nils Gladitz wrote:
On 22.08.2014 02:15, Braden McDaniel wrote:
Ah. Bummer.
Well, as you might have guessed, I'm trying to address an issue where
the LOCATION property of a target (EXPORT_TARGET, in the example above)
was being used. Is there some way I can get this information about the
target that doesn't involve modifying the CMakeLists.txt in each
subdirectory where a target of interest resides?
Perhaps something like:
file(GENERATE
OUTPUT ${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$CONFIG
CONTENT $TARGET_FILE:${EXPORT_TARGET}
)
Or if you want to keep this at build time a custom command with the
OUTPUT signature and
e.g. a custom target that depends on that output.
Actually, I'd rather not do it at build time; I just didn't realize I
could avoid it. That should work quite nicely. Thanks!
--
Braden McDaniel bra...@endoframe.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] add_custom_command doesn't know about target; but get_target_property does
Nils Gladitz nilsgladitz@... writes:
Perhaps something like:
file(GENERATE
OUTPUT ${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$CONFIG
CONTENT $TARGET_FILE:${EXPORT_TARGET}
)
Actually, upon closer inspection, it looks like this doesn't work because
$TARGET_FILE:${EXPORT_TARGET} won't be aware of the current configuration at
CMake
configure-time. I'm trying to get the configuration-dependent path of the
emitted library.
(And I need to support Windows project files.)
Or if you want to keep this at build time a custom command with the
OUTPUT signature and
e.g. a custom target that depends on that output.
It's not clear to me that this approach would solve the above problem.
Braden
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] add_custom_command and CONFIG-dependent output
I'm trying to do this:
set(LIB_STAGEDIR ${STAGEDIR}/lib/$CONFIG)
add_custom_command(
OUTPUT ${LIB_STAGEDIR}
COMMAND ${CMAKE_COMMAND} -E make_directory ${LIB_STAGEDIR}
)
…and CMake complains thusly:
add_custom_command called with OUTPUT containing a . This
character is
not allowed.
Is there some way to specify OUTPUT when it is dependent on the value
of $CONFIG or similar?
--
Braden McDaniel
bra...@endoframe.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] add_custom_command doesn't know about target; but get_target_property does
I have the following code that executes in a top-level CMakeLists.txt
*after* having recursed into subdirectories:
get_target_property(TARGET_NAME ${EXPORT_TARGET} NAME)
message(STATUS ${EXPORT_TARGET} NAME = ${TARGET_NAME})
add_custom_command(
TARGET ${EXPORT_TARGET} POST_BUILD
COMMAND ${CMAKE_COMMAND} -E echo $TARGET_FILE
${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$CONFIG
)
EXPORT_TARGET is a library target defined in a subdirectory. This
results in the following output from CMake:
my_target NAME = my_target
CMake Warning (dev) at CMakeLists.txt:965 (add_custom_command):
Policy CMP0040 is not set: The target in the TARGET signature of
add_custom_command() must exist. Run cmake --help-policy CMP0040
for
policy details. Use the cmake_policy command to set the policy and
suppress this warning.
The target name my_target is unknown in this context.
How come get_target_property knows about the target but
add_custom_command does not?
I am using CMake 3.0.1.
--
Braden McDaniel
bra...@endoframe.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Mixing non-CMake ExternalProjects using Visual Studio
On Apr 1, 2013, at 3:10 PM, Micha Hergarden micha.hergar...@gmail.com wrote:
On 01-04-13 20:02, Braden McDaniel wrote:
When mixing a CMake Visual Studio build that has ExternalProjects (that is,
via ExternalProject_Add) that use non-CMake makefile builds, how does one
resolve the mismatch between the *_config variables
(CMAKE_CXX_FLAGS_RELEASE, etc.)?
Specifically, how do I propagate the build flags in the *_config variables
down to the ExternalProject? I can't seem to find a way in CMake that will
let me pick which variable to propagate (that is, CMAKE_CXX_FLAGS_DEBUG when
I'm building the Debug configuration, CMAKE_CXX_FLAGS_RELEASE when building
the Release configuration, etc.).
One option seems to be just to build the makefile-based ExternalProject four
times--one for each configuration CMake generates in its project files. But
that, too, has a problem: what if the makefile-based ExternalProject has a
dependency on another ExternalProject with a CMake build?
Are there any good solutions to these sorts of problems?
In my project I've added wrappers for each stage:
PATCH_COMMAND ${CMAKE_CURRENT_BINARY_DIR}/patchwrapper
CONFIGURE_COMMAND ${CMAKE_CURRENT_BINARY_DIR}/configurationwrapper
BUILD_COMMAND ${CMAKE_CURRENT_BINARY_DIR}/buildwrapper
INSTALL_COMMAND ${CMAKE_CURRENT_BINARY_DIR}/installwrapper
These wrappers include a defaults file that I create from a defaults.in,
using configure_file command. That way I can set flags and all kinds of build
related variables. Although officially it's not recommended to use it in
generic cmake based projects, it works quite well for me as I don't
distribute my project. I just use the external projects to precompile some
third party tooling.
Thanks... I've made quite a bit of progress with this approach.
I'm attempting to use cmake -P for the wrapper script and I've been mostly
successful; though I've hit a bit of a speedbump that I'll outline in another
posting.
--
Braden McDaniel
bra...@endoframe.com
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Mixing non-CMake ExternalProjects using Visual Studio
On Apr 11, 2013, at 11:27 AM, Braden McDaniel bra...@endoframe.com wrote:
On Apr 1, 2013, at 3:10 PM, Micha Hergarden micha.hergar...@gmail.com wrote:
On 01-04-13 20:02, Braden McDaniel wrote:
When mixing a CMake Visual Studio build that has ExternalProjects (that is,
via ExternalProject_Add) that use non-CMake makefile builds, how does one
resolve the mismatch between the *_config variables
(CMAKE_CXX_FLAGS_RELEASE, etc.)?
Specifically, how do I propagate the build flags in the *_config
variables down to the ExternalProject? I can't seem to find a way in CMake
that will let me pick which variable to propagate (that is,
CMAKE_CXX_FLAGS_DEBUG when I'm building the Debug configuration,
CMAKE_CXX_FLAGS_RELEASE when building the Release configuration, etc.).
One option seems to be just to build the makefile-based ExternalProject
four times--one for each configuration CMake generates in its project
files. But that, too, has a problem: what if the makefile-based
ExternalProject has a dependency on another ExternalProject with a CMake
build?
Are there any good solutions to these sorts of problems?
In my project I've added wrappers for each stage:
PATCH_COMMAND ${CMAKE_CURRENT_BINARY_DIR}/patchwrapper
CONFIGURE_COMMAND ${CMAKE_CURRENT_BINARY_DIR}/configurationwrapper
BUILD_COMMAND ${CMAKE_CURRENT_BINARY_DIR}/buildwrapper
INSTALL_COMMAND ${CMAKE_CURRENT_BINARY_DIR}/installwrapper
These wrappers include a defaults file that I create from a defaults.in,
using configure_file command. That way I can set flags and all kinds of
build related variables. Although officially it's not recommended to use it
in generic cmake based projects, it works quite well for me as I don't
distribute my project. I just use the external projects to precompile some
third party tooling.
Thanks... I've made quite a bit of progress with this approach.
I'm attempting to use cmake -P for the wrapper script and I've been mostly
successful; though I've hit a bit of a speedbump that I'll outline in another
posting.
The problem was that I was setting CMAKE_ARGS in ExternalProject_Add in order
to invoke my CMake script; but setting CMAKE_ARGS has the effect of calling
CMake twice (once to configure, once to build). The second call would result
in an error.
Using BUILD_COMMAND to invoke CMake with my script has the desired effect.
(Well, almost. stdout from the build process now goes into a log file instead
of being visible in the IDE's build output window. But it'll do.)
--
Braden McDaniel
bra...@endoframe.com
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] string(REGEX REPLACE …) syntax problem
On Mar 30, 2013, at 11:29 PM, David Cole dlrd...@aol.com wrote:
REGEX REPLACE will replace this with that in the entire input string,
everywhere it matches. If you want to limit it to just the one bit that
matches inside the parenthesis, you have to match the entire string, too, so
that it will also be replaced. In your example, the \\1 is being set to
Release and the /build Release is being replaced with \\1 in the entire
input string. So in effect, you erased the /build from in front of it.
What you want is to erase the whole string, except for the Release, right?
This should work:
string(REGEX REPLACE ^.*/build ([A-Za-z]+).*$ \\1 BUILD_CONFIG
${FOO})
I just added ^.* at the beginning, and .*$ at the end, so it matches the
entire input string.
Thank you... That makes sense, now that I think about it.
--
Braden McDaniel
bra...@endoframe.com
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Mixing non-CMake ExternalProjects using Visual Studio
When mixing a CMake Visual Studio build that has ExternalProjects (that is, via ExternalProject_Add) that use non-CMake makefile builds, how does one resolve the mismatch between the *_config variables (CMAKE_CXX_FLAGS_RELEASE, etc.)? Specifically, how do I propagate the build flags in the *_config variables down to the ExternalProject? I can't seem to find a way in CMake that will let me pick which variable to propagate (that is, CMAKE_CXX_FLAGS_DEBUG when I'm building the Debug configuration, CMAKE_CXX_FLAGS_RELEASE when building the Release configuration, etc.). One option seems to be just to build the makefile-based ExternalProject four times--one for each configuration CMake generates in its project files. But that, too, has a problem: what if the makefile-based ExternalProject has a dependency on another ExternalProject with a CMake build? Are there any good solutions to these sorts of problems? -- Braden McDaniel bra...@endoframe.com -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] string(REGEX REPLACE …) syntax problem
I must be Doing It Wrong; but I'm not seeing how...
If I do a REGEX MATCH as follows:
build_command(FOO)
string(REGEX MATCH /build ([A-Za-z]+) BUILD_CONFIG ${FOO})
message(STATUS BUILD_CONFIG = ${BUILD_CONFIG})
... I get, as expected:
BUILD_CONFIG = /build Release
However, if I use the same expression with REGEX REPLACE:
build_command(FOO)
string(REGEX REPLACE /build ([A-Za-z]+) \\1 BUILD_CONFIG ${FOO})
message(STATUS BUILD_CONFIG = ${BUILD_CONFIG})
... BUILD_CONFIG holds the entire build command line rather than just the
configuration name:
BUILD_CONFIG = C:\PROGRA~2\MICROS~1.0\Common7\IDE\devenv.com my.sln Release
/project ALL_BUILD
How am I misapplying REGEX REPLACE?
--
Braden McDaniel
bra...@endoframe.com
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Deep variable expansion (or, replacing literal ${FOO})
The value of the variable CMAKE_CFG_INTDIR is the literal string ${config}
(that is, CMake does not expand this variable itself). I'd like to expand this
literal variable within CMake using a value I supply; that is, I'd like to
replace the literal string ${config} with something else; say, foo. Alas, I
have not been able to get this to work:
string(REPLACE \${config} foo MY_OUTPUT_VAR ${CMAKE_CFG_INTDIR})
Why isn't this working? Is there some other way to accomplish what I want?
Braden
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using the Microsoft compiler with Unix Makefiles
On 6/19/12 8:33 AM, Bill Hoffman wrote: On 6/19/2012 6:49 AM, Michael Jackson wrote: It can be done as Bill Hoffman seems to do this all the time. Let's wait to see what he says. I do know that it involves a lot of setup. Yes, this is my preferred generator. I used cygwin gmake, but this one: http://www.cmake.org/files/cygwin/make.exe-cygwin1.7 The one that comes with cygwin can not handle c:/ paths that VS requires. Hm... That part's a bit annoying. If I'm going to have to bootstrap with a special binary, I could use a binary of cmake as well. What I'm trying to accomplish is building a cmake that can generate Visual Studio project files. It appears that's not what I get when I build using the GNU toolchain. If there were a way to enable this when building with the GNU toolchain, that would probably be the easiest way to solve my problem. Failing that, I'll just build it the conventional way (using a prebuilt Windows binary). Braden -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Using the Microsoft compiler with Unix Makefiles
Is it possible to use the Microsoft compiler (cl) with Unix Makefiles? I found some older list postings that suggested it could work; however, setting CC, CXX, and CMAKE_CXX_COMPILER to cl doesn't do the trick. (It appears that the compiler doesn't like some of the flags used in the makefiles.) Can this be made to work with modern CMake (2.8.7), or am I barking up the wrong tree? Braden -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Headers don't install on Mac OS X (mysql-connector-c)
I'm building mysql-connector-c-6.0.2, which uses cmake, on Mac OS X 10.7.3 using MacPorts cmake 2.8.7. I have found that make install does not actually install the project's header files. When I tried to reproduce this on Linux (Fedora 16), it worked just fine; so it looks like this is a Mac-specific (or perhaps even more specific) problem. I'm a total novice at CMake; but I see this in the top-level CMakeLists.txt: INSTALL(DIRECTORY include/ DESTINATION include FILES_MATCHING PATTERN *.h) Looking at http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:install ... I don't see anything obviously wrong with that usage. The package in question can be found here: http://mysql.mirrors.pair.com/Downloads/Connector-C/mysql-connector-c-6.0.2.tar.gz Braden -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Headers don't install on Mac OS X (mysql-connector-c)
On 4/26/12 2:45 PM, Eric Noulard wrote:
2012/4/26 Braden McDanielbra...@endoframe.com:
I'm building mysql-connector-c-6.0.2, which uses cmake, on Mac OS X 10.7.3
using MacPorts cmake 2.8.7. I have found that make install does not
actually install the project's header files.
When I tried to reproduce this on Linux (Fedora 16), it worked just fine; so
it looks like this is a Mac-specific (or perhaps even more specific)
problem.
I'm a total novice at CMake; but I see this in the top-level CMakeLists.txt:
INSTALL(DIRECTORY include/
DESTINATION include
FILES_MATCHING PATTERN *.h)
Looking at
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:install
... I don't see anything obviously wrong with that usage.
The package in question can be found here:
http://mysql.mirrors.pair.com/Downloads/Connector-C/mysql-connector-c-6.0.2.tar.gz
This package is dirty because it contains many files coming from some
Sparc configuration, the following files are coming from a previous in-source
leftover:
Makefile
CMakeFiles
cmake_install.cmake
CPackConfig.cmake
CPackSourceConfig.cmake
CTestTestfile.cmake
Remove those files from the source and try
a clean out-of-source build install:
http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees
I've seen some traffic that led me to question whether this distribution
works with out-of-source builds; so I did
find . \( -name Makefile -o -name CMakeFiles -type d -prune -o -name
cmake_install.cmake -o -name CPackConfig.cmake -o -name CPackSourceConfig.cmake
-o -name CTestTestfile.cmake \) -exec rm -rf {} ';'
and proceeded with an in-source-tree build.
Header files were still not installed.
So, I got the latest sources from launchpad:
bzr branch lp:libmysql
This version has something slightly different in CMakeLists.txt to
install the headers:
INSTALL(DIRECTORY ${CMAKE_SOURCE_DIR}/include/
DESTINATION include/mysql
FILES_MATCHING PATTERN *.h)
INSTALL(DIRECTORY ${CMAKE_BINARY_DIR}/include/
DESTINATION include/mysql
FILES_MATCHING PATTERN *.h)
So, from there, I proceeded with an out-of-source-tree build.
Once again, the headers were not installed.
I began to be suspicious of the possibility of a platform-specific CMake
bug affecting the file selector (possibly in the pattern matching). So
I tried eliminating the pattern selectors from the install directives:
INSTALL(DIRECTORY ${CMAKE_SOURCE_DIR}/include/
DESTINATION include/mysql)
INSTALL(DIRECTORY ${CMAKE_BINARY_DIR}/include/
DESTINATION include/mysql)
This successfully installs the headers (and possibly a bit more).
Braden
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
