Re: [CMake] COMMAND dependencies with add_custom_command()
On 2017-01-25 20:25, Craig Scott wrote: > The documentation for add_custom_command() contains this little nugget when > discussing the COMMAND keyword: > > If COMMAND specifies an executable target name .. Additionally a >> target-level dependency will be added so that the executable target will be >> built before any target using this custom command. However this does NOT >> add a file-level dependency that would cause the custom command to re-run >> whenever the executable is recompiled. > > I'm struggling to come up with a scenario where that last part about file > level dependencies becomes relevant. Can anyone come up with a simple use > case which highlights that particular aspect of dependencies and commands? Let's start with an example, so we can talk about this concretely: add_executable(my_generator generate.cpp) add_custom_command( OUTPUT generated.out DEPENDS content.in COMMAND my_generator ...) I think what this is saying is that the dependencies will be such that if `generated.out` needs to be built, the build will ensure that `my_generator` is built first (since the command would obviously fail otherwise). However, the build will NOT be set up such that a change to `generate.cpp` causes `generated.out` to be recreated. IOW, if `generated.out` exists, it will only be considered "dirty" if it is older than `content.in`, but NOT if it is older than `my_generator`. Does that help? -- Matthew -- 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] Linker flags on all except a couple of programs
On 2017-01-12 00:49, Paul Smith wrote: > I have a CMake-based build that creates about 170 binaries (most of them > are individual unit test programs). > > I have set the CMAKE_EXE_LINKER_FLAGS to a set of flags I wanted on all > the binaries. > > Now it turns out that I need to remove, or not set, one specific flag on > a small number (like 5) of these binaries, but I still want it set on > all the others. Unfortunately for this flag there's no "turn it off" > extra flag I can add to the end of the list of flags: I have to actually > remove the flag itself. > > What's the cleanest/simplest way to accomplish this? I don't really > want to modify my cmake files to add an explicit set_target_property() > to all 165 binaries that I _do_ want to have this flag set on, just so I > can avoid calling it on the 5 binaries I don't. I want to add something > particular to the 5 "oddball" binaries, instead, to override these > values. > > But I can't seem to come up with a way to remove a flag from a global > list like this, just for one (or a few) targets. I *thought* (but have not checked) that after the target exists, you can get its link flags as a target property, which you could then adjust as needed. Failing that, I think you can remove the flag from the appropriate global variable, create the target (add_executabe or whatever), then restore the previous value. If you wrap this in a function, it will scope the value so you don't even have to worry about restoring it after. Of course, you could also just wrap all your add_executable calls in a function that handles the set_target_property dance for you... Hope this helps! -- Matthew -- 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] To include external libraries using Cmake
On 2017-01-05 05:10, aishwarya selvaraj wrote:
> Thanks for feedback :
>
>> IF (${ARMADILLO} STREQUAL “ARMADILLO-NOTFOUND”)
>> # do what you want
>> ENDIF ()
>
> I tried this way of writing :
>
> IF (${ARMADILLO} STREQUAL "ARMADILLO-NOTFOUND")
> include(ExternalProject)
> ExternalProject_Add(armadillo
> URL https://github.com/lsolanka/armadillo/archive/master.zip
> PREFIX ${CMAKE_CURRENT_BINARY_DIR}/armadillo-latest)
> ENDIF()
>
> and
>
> IF (ARMADILLO STREQUAL ARMADILLO-NOTFOUND)
>include(ExternalProject)
>MESSAGE(STATUS "Trying to install armadillo...")
> ExternalProject_Add(armadillo
> URL https://github.com/lsolanka/armadillo/archive/master.zip
> PREFIX ${CMAKE_CURRENT_BINARY_DIR}/armadillo-latest)
> ENDIF()
`if(NOT ARMADILLO)` is probably better...
> But both of them gave me an error :
> CMake Error: The following variables are used in this project, but
> they are set to NOTFOUND. Please set them or make sure they are set
> and tested correctly in the CMake files:
> ARMADILLO
> linked by target "tsm" in directory /home/computing9/TSM_cmake
> SNDFILE
> linked by target "tsm" in directory /home/computing9/TSM_cmake
Ah... I was mostly replying to Parag; I hadn't actually looked that
closely at your original problem.
What you're trying to do is similar to a "superbuild" with optional
components. The usual way to do this is to treat *your own project* as
one of several external projects, so that the "superbuild" consists
solely of external projects. Something like:
set(mydeps)
if(NOT armadillo)
externalproject_add(armadillo ...)
list(APPEND mydeps armadillo
endif()
# similar for other externals
externalproject_add(myproject ... DEPENDS ${mydeps})
This way, by the time your project configures, the library exists.
(You'll probably end up looking for the library twice; once in the
superbuild to decide whether to build it, and again in your project
proper where you'll a) assume it exists and hard error otherwise, and b)
want to specify as an additional search path where the superbuild will
produce it.)
Without this, trying to set up the rules so that you can both link the
library that will be created, and also get the dependencies correct so
that the build knows how to produce it when needed, is probably going to
be tricky. (Read: I'm not convinced it's impossible, but I've never seen
someone actually doing this and wouldn't recommend it.)
An alternative that may work is to set up the externals as subprojects
and have CMake fetch them at configure time if they are needed, and then
incorporate their builds directly in your own build (i.e. using
add_subdirectory rather than externalproject_add); then you can link to
the library target names when you build them yourself, and everything
will work.
p.s. I don't recommend always obtaining the current master of externals.
It's usually safer to pick a SHA and bump it as needed, so that you are
insulated against breaking changes upstream. I'm also not sure why you
are fetching snapshots instead of just using the git repositories directly.
--
Matthew
--
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] [EXTERNAL]: To include external libraries using Cmake
(Arf, re-send with an account that's allowed to post to the list...)
On 2017-01-04 14:52, Parag Chandra wrote:
> If I’m not mistaken, when a library cannot be found, the value of
> the variable “ARMADILLO” will be set to “ARMADILLO-NOTFOUND”.
Correct. But...
> So I think you need to adjust your test to:
>
> IF (${ARMADILLO} STREQUAL “ARMADILLO-NOTFOUND”)
> # do what you want
> ENDIF ()
CMake treats several strings as having the Boolean value 'false',
including "FALSE" (duh), "0", "OFF", and anything that ends with
"-NOTFOUND". So, it's clearer to just write `if(NOT ARMADILLO)`.
(That said, note that it is convention to name variables that receive
the location of a library like ARMADILLO_LIBRARY. Also, uppercase
commands are sooo last decade ;-).)
BTW, avoid writing unquoted variable expansions in `if()`, as they are
subject to multiple expansion that way. (And it's only recently that
quoted values are not subject to expansion!) Instead, just write the
variable name without the `${` and `}`; it will be expanded for you.
--
Matthew
--
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] Executing python though CMake and linking libraries
On 2016-11-25 04:04, Kit Chambers wrote:
> I have a Cmake custom target which runs a python script:
>
> add_custom_target(run
> COMMAND python myscript.py
> )
>
> ...
>
> To me it looks like my LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not being
> passed through CMake to Python so it cannot find all the necessary sub
> libraries. However, i cannot work out how to pass this information through.
As written, your custom target will be run with whatever environment
your build tool decides to use. *Probably* that will be the environment
when you actually run the build tool (make, ninja, etc.), but it's
possible some build too might monkey with the environment in which it
runs build commands. Also, requiring people building your software to
modify their local environment is probably not ideal.
You probably want to wrap your custom target's command with
`${CMAKE_COMMAND} -E env ...` to ensure it gets the necessary
environment. (Also, you should probably use `${PYTHON_EXECUTABLE}`
instead of `python`, and, similarly, note `${CMAKE_COMMAND}` instead of
`cmake`.)
(Personally, I wouldn't mind seeing CMake learn an `ENVIRONMENT` option
to add_custom_command / add_custom_target that would set up this
wrapping automatically.)
--
Matthew
--
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] Is there a default value for CMAKE_MODULE_PATH?
On 2016-11-09 10:05, Jayesh Badwaik wrote: > Over past few days, Boost has updated from version 1.61 to version 1.62. The > latest version of CMake that I have (3.6.3) does not yet have the appropriate > FindBoost.cmake and hence, issues warnings as shown in the postscript. > > As I see this is temporary, and there is a correct FindBoost.cmake in the git > repository which works fine. So, I want to use this new module file till the > time when the new version of CMake comes out and I won't have to use this > special file anymore. > > All the solutions that I have found on internet require me to put a line > setting the CMAKE_MODULE_PATH in my project source code. I don't want to do > it > since the change is supposed to be temporary anyway. So, I was wondering if > there is a location inside the PROJECT_SOURCE_DIR which is scanned by default > by cmake? > > If there is no such location, I can live with the warnings for a little > while, > but I was just curious. I don't think you can avoid setting CMAKE_MODULE_PATH. Also, it's only "temporary" until you bump your cmake_minimum_required. What I've done in some projects is include the module in a directory named after the version of CMake that will include the updated version. You can then iterate over such directories and compare the name to the CMake version to decide whether or not to add that directory. This way someone with new enough CMake to not need the module will use the built-in version, while someone with older CMake will get your copy. -- Matthew -- 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] exporting targets from build tree
On 2016-07-27 18:49, Michael Legleux wrote:
> I have 2 projects (one built with cmake, one in the process of being
> converted to using it)
>
> Project A (built with cmake) builds lib_a that Project B requires.
> I'm thinking I'm doing something wrong around here:
> project(lib_a)
>
> add_library(lib_a STATIC ${SRC})
> target_link_libraries(${PROJECT_NAME}
>PRIVATE lib_b
>)
> export(TARGETS lib_a FILE lib_a.cmake)
>
> cmake complains that lib_b is not in the target export set. I do not WANT
> it exported and it is not required by project b.
> I simply want lib_a to be found/used by Project B via find_package(Project
> A)
>
> I do not want to have to install/ or create a package for this behavior,
> just allow another project to reference the libs in the build tree and
> headers in the source tree.
>
> I can't seem to find the correct way to express this with cmake despite
> looking at many solutions of near similar functionality.
Did you ever solve this? Offhand, I would guess that lib_a is a static
library. If this is the case, using lib_a requires also linking to
lib_b, because the symbols in lib_a require lib_b, and lib_a is not
actually linked yet.
--
Matthew
--
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-developers] Improving the version selection behavior of EXACT
On 2015-01-09 14:18, Rolf Eike Beer wrote: Matthew Woehlke wrote: On 2014-10-03 03:35, Rolf Eike Beer wrote: find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed.. In most cases this behavior is not the one that one would expect or need. Most people would instead allow any 2.0.x version to match. This sort of selection is currently impossible without additional effort in every Find*.cmake that is used. This is probably a bit late, but did anyone think of using MATCHES to say all provided components match exactly and the rest can be whatever? I bet everybody will get it wrong. Ok, this is version 2.1 and any of it's patch versions, if _I_ got it right: if (VER MATCHES ^2\\.1(\\..*|[^0-9].*)?$) So this should match 2.1, 2.1a, 2.1.1, but not 2.10. What combination of stuff did I miss? ...except I was talking about a new mode for find_package (*not* necessarily a regex). IOW: find_package(Foo 2.1 MATCHES) ...finds Foo 2.1, 2.1.0, 2.1.beta, etc., but not 2.0, 2.0.1, 2.2, etc. (In if(), if available at all (which maybe it needs to be), it would be spelled VERSION_MATCHES.) Anyway, your regex is overcomplicated; I'd think it would be just '^2[.]1([.]|$)'. (I'd be a little hesitant to allow '2.1a' to match '2.1'... is that '2.1 alpha' or 'release a after 2.1'? Or the release following '2.19' because someone is using hex version numbers? I'm not entirely sure that *any* of those should match 2.1, and certainly at most only one should match.) -- Matthew -- 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-developers
Re: [cmake-developers] Improving the version selection behavior of EXACT
On 2014-10-03 03:35, Rolf Eike Beer wrote: find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed. In most cases this behavior is not the one that one would expect or need. Most people would instead allow any 2.0.x version to match. This sort of selection is currently impossible without additional effort in every Find*.cmake that is used. This is probably a bit late, but did anyone think of using MATCHES to say all provided components match exactly and the rest can be whatever? -- Matthew -- 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-developers
Re: [cmake-developers] Extracting target metadata, IDE integration
On 2014-12-22 19:30, Aleix Pol wrote: On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev wrote: * No progress indication. Since the generation may take several minutes, providing feedback is crucial. I never found such case, ParaView. (To a lesser extent, VTK.) I would argue that a project which has a cmake script that takes several minutes is broken, but maybe we can open a thread to discuss it? Well, yes, one might argue that :-). * When there are existing in-source generated files in the project dir, CMake doesn't allow generating into a separate out-of-source folder. An IDE has to invent workarounds here. Arguably, in-source generation is broken by definition... Also, because CMake allows either a source OR BUILD directory to be given, such a configuration is almost certainly doomed. IMO, trying to do an out-of-source build of a source directory that already contains an in-source build *is* broken (i.e. no arguably about it)... and so is an IDE trying to work around such situation. At most, detect the situation and nicely report the problem to the user. -- Matthew -- 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-developers
Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'
On 2014-10-13 10:39, Brad King wrote: On 10/10/2014 07:45 AM, Ruslan Baratov wrote: Locking directory is equivalent to locking file `cmake.lock` in directory /path/to/shared/directory/: I think this can be activated buy a DIRECTORY option. Why do we need even that? Can't CMake just test if the lock target is a directory? p.s. For a lock with no timeout, maybe there can be a built-in timeout after which CMake displays a message what it's trying to do, so that it doesn't just hang mysteriously. -- Matthew -- 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-developers
Re: [cmake-developers] CMake, Ninja generator, and ExternalProjects
On 2014-07-25 17:05, Williams, Norman K wrote: There’s also the ‘console pool’ facility that would allow ExternalProject builds to display output, though that would get back to the Gmake issue of different processes interleaving output. It wouldn't; the 'console' pool only permits one job at a time. So your outer build would run serially, directly showing the output of whatever (*one*) inner build is running at the time. -- Matthew -- 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-developers
Re: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible
On 2014-10-03 08:56, Brad King wrote: On 10/02/2014 06:08 PM, Matthew Woehlke wrote: Please see also http://public.kitware.com/Bug/view.php?id=14915 which it sounds like this (partly) fixes; you may want to reference that in your patch or vice versa. I've applied the patch here and added the issue reference: Ninja: Use 'console' pool for CMake re-run if possible (#14915) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f32a241 (The partly is that the request is also for the 'install' target to use the console pool; not sure if you did that, want to tackle that, etc., but in any case this is a step in the right direction.) I'll leave that to a follow-up patch if anyone wants to do it. I was sort-of hoping / encouraging that Sylvain might be interested :-). Anyway, thanks! (Re-running CMake is the more important task, I think, as that's known to take minutes in some cases... install, while also an obvious candidate for such treatment, I believe tends to be quicker, so it less important.) -- Matthew -- 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-developers
Re: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible
On 2014-10-03 14:00, Sylvain Joubert wrote: Le 03/10/2014 17:41, Matthew Woehlke a écrit : On 2014-10-03 08:56, Brad King wrote: I'll leave that to a follow-up patch if anyone wants to do it. I was sort-of hoping / encouraging that Sylvain might be interested :-). I quickly checked if it is possible. Unlike the rerun target which is manually added by the Ninja generator, the install and package targets are handled in a generic way by the utility target generator. Thus, handling these targets is not as straightforward as rerun. I'll keep digging a bit, maybe I can find a way to do it. ;-) Many thanks, Sylvain. Don't worry if it's going to be a pain; I was thinking since you were in there anyway it might be easier for you. It's certainly much appreciated if you want to tackle this, but no worries if you don't. Thanks again for the re-run CMake patch! -- Matthew -- 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-developers
Re: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible
On 2014-10-02 17:34, Sylvain Joubert wrote: Since Ninja 1.5, a pre-defined pool 'console' can be used for non buffered output. See http://martine.github.io/ninja/manual.html#_the_literal_console_literal_pool This patch specifies that special pool for the build.ninja build block if the Ninja version used is at least 1.5 I haven't tried it yet, but I've been wanting this feature; thanks for the patch! Please see also http://public.kitware.com/Bug/view.php?id=14915 which it sounds like this (partly) fixes; you may want to reference that in your patch or vice versa. (The partly is that the request is also for the 'install' target to use the console pool; not sure if you did that, want to tackle that, etc., but in any case this is a step in the right direction.) -- Matthew -- 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-developers
Re: [CMake] Question regarding External Project add and VTK
On 2014-06-02 17:48, jmerkow wrote: I want to add VTK as an external project, but I have a few questions. Looking online at examples of other projects using vtk as an external project, many of them use a 'superbuild' style technique [...] they have some option to enable SuperBuild (or a seperate CMakeLists.txt file) then that adds all the external projects (i.e. vtk or itk), and finally they add their own project as an external project (obv with superbuild turned off). I am wondering why this is done this way.. I think the answer is that you otherwise get into a chicken-and-egg situation. Basically, your own project can't configure until VTK is available; therefore, it is necessary to make configuration of your own project be done as a build step that can depend on the build of VTK, which is what the above pattern achieves. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Using reflinks during install phase
On 2014-05-29 08:56, Brad King wrote: I did not realize in my previous response that you intend to execute a cp process, but rather thought you would be implementing the underlying calls to the filesystem directly. That was my assumption also. I would've thought that would be better, as coreutils basically exists only on Linux. (And even then, someone could in theory have a different 'cp', though that is unlikely.) @Alessandro, would you expect this to ever be used on e.g. a BSD or OS/X system? -- Matthew -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On 2014-05-15 08:36, Ben Boeckel wrote: On Thu, May 15, 2014 at 12:45:27 +0200, Nicolas Desprès wrote: Nope. These variables are the cmake equivalent to the __LINE__ and __FILE__ C-pre-processor macro. What I need is the #line directive equivalent which force the value of these variables so that error messages reported by cmake uses the forced value. If you'd like to try a patch, the relevant code is in Source/cmExprParser*. Add a callback for #line nnn and update the CurrentLine variable cmExprParserHelper.cxx. Don't forget tests :) . This will also likely need a policy since there's no guarantee that #line directives don't exist in already existing code as comments. Maybe we should not introduce pragma-like constructs that are indistinguishable from comments? :-) TBH I'd be a little ambivalent about such a feature. A line pragma itself isn't too bad, but opening the door for other types of pragmas makes me a little more nervous :-). -- Matthew -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On 2014-05-21 15:24, Nicolas Desprès wrote: On Wed, May 21, 2014 at 8:06 PM, Matthew Woehlke wrote: On 2014-05-15 08:36, Ben Boeckel wrote: This will also likely need a policy since there's no guarantee that #line directives don't exist in already existing code as comments. Maybe we should not introduce pragma-like constructs that are indistinguishable from comments? :-) TBH I'd be a little ambivalent about such a feature. A line pragma itself isn't too bad, but opening the door for other types of pragmas makes me a little more nervous :-). If it is possible I would rather prefer a cmake macro too. I don't see why not... in fact it may be easier, since you won't have to fiddle with the parsing at all. My knee-jerk inclination is to add a 'pragma()', e.g. 'pragma(LINE 15 FILE foo.py)', except then I feel like there should be at least a 'pragma(POLICY)' also :-). (See previous comment about it sliding into a major feature.) Maybe something like 'set_reference()' / 'set_script_source()' could be used instead. -- Matthew -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On 2014-05-01 13:35, John Drescher wrote: I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. Executing cmake . would fail in the bin folder if it had no way to know where the source folder is. If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On 2014-05-01 14:26, Nils Gladitz wrote: On 01.05.2014 20:16, Matthew Woehlke wrote: If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? If they were regular instead of cache variables they would have scopes. I guess this would break any project that currently referred to their sub- or sibling projects with those variables. Hmm... that's a good point. I suspect project() could work around the scope at least by arranging to set them in the root scope, but there might be other, related issues that could arise. Nuts :-). -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
On 2014-04-28 04:58, Johannes Zarl wrote:
I'm always happy to learn something new. How would you manage to make the
following if statement trigger?
set( arg value)
if ( ${arg} STREQUAL TOTO )
message ( arg equals 'TOTO', and arg equals 'value' )
endif()
Exactly how you would expect:
set( TOTO value)
...and it does trigger:
$ cmake -P evil.cmake
arg equals 'TOTO', and arg equals 'value'
No, but the if statement didn't trigger, either.
Well, yes, but that's because I caused arg to be compared against 'evil'
instead of 'TOTO'. Since arg is set to 'value', it still didn't match.
The previous example was more metaphorical.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
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' would answer this question. (And yes, they are.) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Please restore --help-full cmake option for version 3
On 2014-04-24 08:35, Nils Gladitz wrote: On 04/24/2014 02:17 PM, Alan W. Irwin wrote: I also just discovered that --help-man and --help-html were gone as well for those who preferred man or html formatting of the full documentation as opposed to the ascii form delivered by --help-full. The latter is the most important to me and is presumably the easiest to implement, but I am sure others prefer the man page or html formats instead so I hope CMake developers will deal with those cases as well. The documentation is now generated by Sphinx (http://sphinx-doc.org/) rather than CMake itself. The man and html documentation (also plain text but not single file and not installed) can be generated when building CMake itself. The current html version of CMake git master e.g. looks like this: http://www.cmake.org/cmake/help/git-master/ So even though the cmake binary can no longer generate the html and manpage documentation itself it is still available. Is there a reason CMake cannot know where to find these pages in order to display them on request? (--help-man doesn't seem necessary except to generate the man pages; if they're being generated by some other means, I'd think 'man cmake' is sufficient to display them.) -- Matthew -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Please restore --help-full cmake option for version 3
On 2014-04-24 14:42, Alan W. Irwin wrote: So my remaining question (without all the html and man distractions) boils down to a request to implement --help-full as the concatanation (following the same order as the present CMake 2 results) of those individual manual results. Come to think of it, it's pretty common to have a monolithic form of otherwise categorized documentation. Single web pages are (as noted) much easier to search, likewise for man pages and plain text. And of course if you want the documentation in PDF form... If there isn't currently a .rst file somewhere to concatenate all the various documentation together with appropriate headings and table of contents, this would probably be a good thing to add. (And then it could be leveraged for --help-full.) -- Matthew -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Explanation....
On 2014-04-24 04:53, Johannes Zarl wrote:
On Wednesday, 23. April 2014, 18:54:39, Matthew Woehlke wrote:
if ( ${arg} STREQUAL TOTO)
set( TOTO evil)
You sure? When I checked, this did not work.
Are *you* sure? :-)
Also, the following gives me a syntax error:
message( ${ foo})
Right; *explicit* expansion is limited in what characters are allowed.
As David Cole points out, you must expand such variables indirectly. Of
course, implicit expansion counts as indirect expansion, which is why
there is no safe character/prefix that can guarantee implicit expansion
won't occur.
(And - again as David Cole already noted - you didn't get an error in
the set() command, did you?)
See also
http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9936.
This is totally different, in that it uses an unsafe prefix.
No it doesn't. The point being made there (and here) is that *ANY*
prefix is unsafe. (Granted, some are more unsafe than others...)
On 2014-04-24 06:31, David Cole wrote:
I, for one, would fully support breaking backwards compatibility to fix
this, and be strict with variable and macro and function name
identifiers.
Of course, the *real* problem is implicit expansion. The permissiveness
of variable naming makes it harder to work around this, but would be
less of an issue if implicit expansion was less eager.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] [PATCH] remove x placeholder from STREQUAL operands
On 2014-04-18 09:07, Brad King wrote: On 04/18/2014 08:58 AM, Rolf Eike Beer wrote: To forbid whitespace and control characters in variable names can IMHO only be good. Some people use arbitrary variable names as a way to do key/value tables. In such cases it is intentional to use arbitrary characters in variable names even though they are never written literally in the source. Adding actual data types (a true list type would be an enormous improvement) could remove the need for such trickery... -- Matthew -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package
On 2014-04-23 16:21, Alan W. Irwin wrote: [...] I keep making a plea for a proper fix to bug 9220 because propagating compiler information (held potentially in a large number of different environment variables and CMake variables for many different computer languages) from the principal CMake project to the test project is somewhat problematic. This sounds like it would be relevant to external projects, also. Does this include propagating compile/link flags? A better and more canned solution to the problem of propagating tools and flags in general (e.g. from a superbuild project to its external_project 'children') would be most welcome... (That said... bonus points for allowing at least compile/link flags to be overridden per sub-project; I have at least one instance where I need this ability, in order to specify strict warning flags generally that need to be disabled for a specific sub-project.) -- Matthew -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Explanation....
On 2014-04-16 06:03, Rolf Eike Beer wrote:
Am 16.04.2014 11:39, schrieb Johannes Zarl:
Instead of ``${var} STREQUAL VALUE'', write:
IF ( var MATCHES ^VALUE$ )
NO, please don't! I try hard to kill all those as it requires
compiling a regular expression for a simple string match. Just change it
to something that is no valid variable name, i.e. will never get expanded:
if ( ${arg} STREQUAL TOTO)
set( TOTO evil)
Admittedly it's much less likely that variable names containing
non-identifier characters¹ will occur by accident, the only truly safe
way to avoid unintended implicit expansion is to either rely on implicit
expansion (i.e. always assign your operands to variables and give the
variable names as the literal arguments), or use some other command that
doesn't perform expansion.
(¹ except for '-', which will often occur in automatically created
variable names when used in project names, e.g. my-project_SOURCE_DIR.)
See also
http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9936.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Custom Commands and Environmnt Settings for PATH and LD_LIBRARY_PATH
On 2014-04-11 05:32, Jörg Kreuzberger wrote:
[stuff about environment and custom commands]
So it would help to have a possiblity to have a custom command like this:
add_custom_command( OUTPUT out
COMMAND ..
COMMAND ..
ENVIRONMENT PATH=$ENV{PATH}
ENVIRONMENT LD_LIBRARY=
I'm pretty sure this is not the first time this sort of thing has come
up. It would indeed be useful to be able to pass environment values to a
custom command without having to roll your own wrapper script. However,
because the command must be run by the build too, I believe a wrapper of
some sort is unavoidable (though on POSIX platforms, 'env' can possibly
serve this purpose).
Bonus points for supporting '{PRE,AP}PEND ENVIRONMENT' which would
automatically use the platform-appropriate PATH separator to
prepend/append a specified value to an environment variable (omitting
the separator if the variable is empty).
However, to do this, I think you would need to teach CMake a new command
mode, e.g.:
cmake -E env VAR1=VALUE VAR2:=PREPEND_VALUE VAR3+=APPEND_VALUE \
command args
I think this would be a nice feature to have, though.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Default generator
On 2014-04-17 07:56, Peter Kümmel wrote: Is there a way to configure the default generator for command-line cmake calls? If you're using bash: 'alias cmake=cmake -GNinja' (for example)... I'm not sure how folks would feel about having a different default built into the cmake binary itself (and anyway this could only help you if you build your own cmake), so probably it is going to be some environment thing anyway. In which case it is probably just as easy to use an alias, or write a wrapper script, or similar... -- Matthew -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Dependency resolution for add_custom_command calls?
On 2014-04-09 12:08, SF Markus Elfring wrote: I try to generate some files mainly by calls of the command add_custom_command. One of them should start with the action to copy a source file into the build directory. But I wonder why this step is not written into a generated make file. I would appreciate your advices. CMake drops unused dependencies / rules from the generated build script. Do you have a target that depends on the output file? -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] multi-line strings... is this expected?
On 2014-03-27 13:54, Matthew Woehlke wrote:
I have¹ a CTest like:
execute_process(...)
set(expected
...text...
...text...
)
string(REGEX MATCH ${expected} match ${out})
This works great... *IF* the script file has UNIX line endings. I'm
wondering if that is expected? It seems that CTest must be processing
the script in binary mode in order for the string to contain '\r'
characters...
For the record: no. It turns out the line endings is actually a) a red
herring (although the problem was a platform difference in a way), and
b) not actually an issue (on further investigation, both CMake 2.8.x and
3.0 seem to be behaving as expected in this respect).
Can anyone spot the problem above? :-)
It turns out that what is *actually* happening is that this:
string(REGEX MATCH ${expected} match ${out})
...strips any ';'s from ${out}. And incidentally, the work-around I was
using ('string(REPLACE \r expected ${expected})') does likewise, so
that the combination results in neither string containing ';'s, which
then can match. I was only seeing issues on Windows because the relevant
';'s are path separators, which are of course ':'s on other platforms
and so are not affected.
Quoting the argument to REGEX MATCH is the actual correct fix :-).
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
[CMake] multi-line strings... is this expected?
I have¹ a CTest like:
execute_process(...)
set(expected
...text...
...text...
)
string(REGEX MATCH ${expected} match ${out})
So, basically, I'm checking that the process outputs a certain set of
lines, and taking advantage of multi-line strings in CTest script for
convenience and readability.
This works great... *IF* the script file has UNIX line endings. I'm
wondering if that is expected? It seems that CTest must be processing
the script in binary mode in order for the string to contain '\r'
characters...
(I don't need the obvious work-around². I'm asking if this is expected
and e.g. if I should file a bug report...)
I haven't tested exhaustively but this may not affect all versions of
CMake. (Noticed on 2.8.11.1.)
(¹
https://github.com/commontk/AppLauncher/blob/master/Testing/CMake/AppLauncher-Settings-TestEnvironment.cmake)
(²
https://github.com/mwoehlke-kitware/AppLauncher/tree/test-multi-line-string-fixes)
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Variable Containing MSVC and MATCHES
On 2014-03-12 16:25, Marek Vojtko (Firaxis) wrote:
I know that MSVC is a CMake keyword and it is therefore not a good
idea to use the string MSVC as the value for any variable, e.g.
set( compiler MSVC ), because if you aren't careful and interpret
such a variable without surrounding it with quotes (e.g. ${compier}
rather than ${compiler}) you will get 0 or 1 depending on whether
you are using a Visual Studio generator or not. So far so good.
Actually, no. There is actually no difference between quoted and
unquoted expansion. (This is a long-standing issue that tends to trip up
even experienced people. The general consensus seems to be that we'd
like to do something about it, but it's difficult due to implementation
details.)
However, I was caught off guard by the fact that the MATCHES
directive (for regex matching) inside an IF() statement is apparently
interpreting the strings passed to it.
Right. Variables in if() are subject to implicit expansion. Quotes make
no difference.
Consider the following code:
if( MSVC11 MATCHES MSVC[0-9]+ )
message( STATUS MSVC11 matches MSVC[0-9]+ )
endif()
If either MSVC11 or MSVC[0-9]+ is the name of a variable, it will be
expanded. (If the RHS is subject to expansion at all, which I would
suspect it is, but am not 100% sure without testing. Similarly if
implicit expansion is restricted to identifiers or not, which I suspect
it isn't. And yes, MSVC[0-9]+ really is a valid name for a variable in
CMake :-(.)
(Note: *substrings* of arguments aren't implicitly expanded, but I
suspect you have a variable named MSVC11.)
Putting either the string or the regex or both into variables doesn't help
either.
Yes and no. If you rewrite to *rely* on implicit expansion, it would
help. However, the result of an explicit expansion is still subject to
implicit expansion.
The only thing that prevents MSVC from being interpreted is putting
extra quotes into both the string and the regexp, i.e. \MSVC11\
MATCHES \MSVC[0-9]+\.
This is roughly how I usually deal with the issue. Note that the quote
itself isn't special, it's just that you don't have a variable named
'MSVC11'. You could equally write:
if(#MSVC11 MATCHES #MSVC[0-9]+)
...or any other set of non-special characters used to reduce the
likelihood (e.g. autotools likes 'x').
If this is by design, i.e. not a bug, what are the reasons for this?
I believe this is so that you can write e.g. 'if(VAR STREQUAL VALUE)',
which is arguably more natural. Unfortunately, both the LHS and RHS are
really just strings in both cases.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Quick Question: add_custom_target( xxx ) add_custom_command( TARGET xxx ... )
On 2014-03-10 18:48, J Decker wrote: *shrug* there's no build targets... it's just a update/package/uninstall/install script for android apk targets... Turned out to work pretty good other than... configure_file() I had to emit a 1 line script and call 'cmake -P StupidConfigure.cmake' Yes, that's annoying. Maybe such a script should be distributed with CMake? (I don't think it would work well as a command; you still need to be able to pass -D's to set the replacement values, and at that point there probably isn't enough difference between '-E configure_file' and '-P $CMAKE_ROOT/Modules/ConfigureFile.cmake' to justify how much more effort is required to implement the former, vs. the latter just means adding a very short script to CMake's distribution. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to merge dependencies of a static lib with itself?
On 2014-02-28 05:47, Shobhit Shrivastava wrote: I am working on creating an SDK from an existing product's code base and use it as an independent static library. The issue I am facing is that the older product, let's say MM, used to link with all the dependencies in the executable but I have to provide one monolith SDK lib that contains all its dependencies within itself. I have struggled but couldn't find the way to achieve that in CMAKE. I'm not sure if it is possible in CMake to produce a static library that contains the objects from other static libraries. (I'm not even 100% sure it's possible in general, on Windows... I believe with AR-type libraries you could unpack the dependencies and repack their contents into your own library. Ugly, but doable.) However, if your downstream is also using CMake, you shouldn't need to; just provide exported targets for MM and make sure that the interface link libraries for MMlib include all of its dependencies. CMake will then take care that anything linking to MMlib will also pick up the interface dependencies. set_target_properties( MMLib PROPERTIES LINK_FLAGS /LIBPATH:Path_To_MM3PLib1 ) Don't do this; it's not portable. Set the interface link libraries instead. set_target_properties( MMLib PROPERTIES IMPORTED_LOCATION (Path_To_MM3PLib1) ) This won't do what you want; you're telling CMake that the library to link for the MMLib target is a third-party target, and not the MMlib library. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] New EVIS parser moving forward (3.1)
On 2014-02-21 16:34, Ben Boeckel wrote:
Other than varname, I don't really see a huge burden to not allowing
implicit dereferencing and it is more consistent at that point. In fact,
I'd be willing to say in varname that we *only* support implicit
dereference, but it may be too hard to detect:
if (${var})
and actually help users to fix such cases.
I expect the above to test the variable whose name is stored in 'var'
:-). And probably something is wrong if there is no such variable. So
that's probably an argument for forcing a dereference there (unless the
input is a truth-value).
--
Matthew
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Latest UseJava.cmake
On 2014-02-21 13:48, Allen Byrne wrote:
One is the issue with, http://public.kitware.com/Bug/view.php?id=14655, the
CMAKE_JAVA_TARGET_OUTPUT_DIR doesn't override OUTPUT_DIR.
Pedantic: if OUTPUT_DIR is given, it should override
CMAKE_JAVA_TARGET_OUTPUT_DIR. I think maybe you didn't mean to suggest
otherwise, but the above can be read that way.
If OUTPUT_DIR is *not* given, CMAKE_JAVA_TARGET_OUTPUT_DIR should be
used. IIUC this is what is not working for you? I wonder if this is an
unexpected behavior in cmake_parse_arguments (setting it to empty if not
specified rather than leaving it along)? I seem to recall there being a
discussion about that semi-recently...
I disagree with the
issue being minor, because if you have a lot of JARs, it can be really
annoying and error prone to set that everywhere. We just set the
CMAKE_JAVA_TARGET_OUTPUT_DIR at the top of our root CMakeLists.cmake file.
As a work-around, you could write a wrapper function, but your
disagreement is reasonable. Patches welcomed.
Could MANIFEST be added to the options in:
cmake_parse_arguments(_add_jar
VERSION;OUTPUT_DIR;OUTPUT_NAME;ENTRY_POINT;MANIFEST
SOURCES;INCLUDE_JARS
${ARGN}
)
Yes. (IIRC I only left it out because (a) it wasn't present previously,
(b) I didn't need it myself and (c) I am lazy :-).) Again, patches welcomed.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Branches on next
On 2014-02-11 23:03, Ben Boeckel wrote:
On Tue, Feb 11, 2014 at 19:16:49 -0500, Matthew Woehlke wrote:
On 2014-02-11 17:54, Ben Boeckel wrote:
Parsing in CMake is split into separate sections: the part which parses
the lines into CMake's command calls and the part which expands
variables (which is why ${cmd}(${args}) isn't allowed).
Right; I'd figured that much out on my own, and my own parser AFAICT
operates in a similar manner to CMake itself... it doesn't try to
tokenize variable substitutions (I didn't need that, and it would
have made the API non-trivially more complex), although it does choke
if it seems things like '${foo\n'. From what I can tell, the CMake
command parsing pass does also?
Probably worth a test. The new parser will see:
${foo
}
and happily lookup the foo\n variable. The old parser may have choked.
Hmm... that's an interesting and perhaps undesirable behavior change.
AFAICT, the old parser, on encountering a substitution ('${', '@',
'$ENV{', '$CACHE{'), would consume '[[:alnum:]+-._/]' until it found a
matching '}' or '@'. If it found '@' or '$' it would try to consume the
substitution according to the same rules. So yes, the old parser does
reject '${foo\n}' (also '${foo~}', etc.). (Did you check that it isn't
the first stage parser that rejects these?)
As an exception to the above, spaces are allowed inside '$ENV{}' (and
maybe '$CACHE{}'?)... (Interestingly, bash won't let you set such an
environment variable... though /usr/bin/env will...)
FWIW, variables named as such can still come in through CMakeCache.txt
and probably the command line as well, so maybe there's some value here.
If it's wanted, I can tighten up the new implementation (it's also the
perfect release version to start rejecting junk like ';' or ' ' in
variable names, but it is probably too late in the release cycle at this
point).
Yeah... I have definitely wanted that (rejecting setting variables that
don't match the above rules) before :-).
I think I even mentioned that at some point as 'things I'd like to see
in 3.0'.
--
Matthew
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Branches on next
On 2014-02-11 23:03, Ben Boeckel wrote: On Tue, Feb 11, 2014 at 19:16:49 -0500, Matthew Woehlke wrote: On 2014-02-11 17:54, Ben Boeckel wrote: ExpandVariablesInString is the part which takes a string which may have variables in it and dereferences them. Yes, that's why your changes are probably not all that helpful to understanding CMake's parsing... one must first understand the initial parse pass, which I assume is still in lex (unless you rewrote it too and forgot to mention it ;-), which I doubt). That code isn't even on the radar for expensive code. It probably could be replaced with smaller code other than lex/yacc, but it's not worth the time if performance is the goal (removing lines, however…). Anything other than comments and blank lines is always in the form: command ( argstring ) newline which is pretty fast (the parser is also set up once per file; the EVIS lex/yacc parser was set up and torn down for *each* expansion which is generally per-line which contains any of @$\\). Related: does the first pass then completely ignore these characters (and also genex's AFAICT?) and only perform argument splitting based on whitespace and ''? I'm wondering, since I don't try to tokenize expansions anyway, if I can just get rid of that part of my parsing without harm... -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Run clean before automatically re-running cmake?
On 2014-02-12 11:35, Abe Bachrach wrote: The Makefile that cmake generates includes a rule to automatically re-run cmake if any of the input CMakelists.txt files change. Currently, if you change the name of an executable target (or library), it will leave the old file in the output location, and then after re-running cmake, the Makefile will not have any record of it, so running make clean won't remove it. I would rather have the rule call make clean before re-running cmake so that such stray outputs are not left around. Is there any way to accomplish this? What you really want is to record the old list of output files, re-run CMake, then remove any files on that list that no longer have rules to generate them. If you do a complete 'clean' you will delete and have to rebuild more than is necessary (which might even be nothing e.g. if CMake is being re-run because you added a debugging message). While that's probably hard to impossible¹ with 'make', I mention it because this feature (as described above) has at least been discussed for ninja², which does have the ability to implement it. (I'm not sure if it actually has been implemented or not, though.) (¹ Use of recursive makefiles here doesn't help; probably each makefile would have to implement this logic, and each parent would have to know how to deal with directories that no longer exist in the build.) (¹ http://martine.github.io/ninja/) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] push of LinkOptionsCommand topic branch
On 2014-02-08 06:10, Stephen Kelly wrote: 3) Assuming you still have no local changes, git reset --hard origin/LinkOptionsCommand Worth adding: If you *do* have local changes, you can (before running the above) set them aside with git stash and (after running the above) restore them with git stash pop. At worst, the forced push will have changed things so much that your changes can no longer be applied. If this happens, your stash will not be discarded and can be used to see your changes in their original context (and will also prevent your original version of the branch from being garbage-collected from your local clone for as long as the stash exists). Note also that reset --hard will discard any uncommitted changes! -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Preparing for CMake 3.0-rc1
On 2014-02-07 13:57, Brad King wrote: There is one more change I'd like to make as part of the change to the 3.0 version number. I propose that we drop the fourth version component and use only two components for the feature level. I guess this will mean that minor release are much more frequent than historically? (About as frequent as patch release in the 2.x series, I guess?) Future feature releases will then be numbered 3.1, 3.2, ..., 3.9, 3.10, 3.11, ... Out of curiosity, does this mean that 3.x will drop the convention of odd-numbered minor versions being developmental? (Actually, I can't recall ever actually seeing an odd-numbered minor version...) -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Using a toplevel CMakeList.txt to build all sub projects at once.
On 2014-02-06 01:14, PCMan wrote: We're migrating from gtk+ to Qt and autotools to CMake and encountered some issues. There are many small modules or components in our project. Each of them has their own CMakeLists.txt and can be built separately. However, it's hard to build so many projects manually. So we'd like to create a toplevel CMakeLists.txt to build them all at once. However, the small projects depend on each other. For example, our project layout look like this: libqtxdg - a base lib required by others liblxqt - a library depends on libqtxdg lxqt-config - a tool depends on liblxqt and libqtxdg. To build lxqt-config, liblxqt and libqtxdg need to be installed first. So simply adding them using add_subdirectoyy() won't work. This sounds like a classic superbuild problem. As an alternative, you could make sure that all of your sub-projects build CMake package configuration files with modern exported targets¹, and then conditionally do a find_package for your dependencies if not being built from the root build. Then each sub-project uses its dependencies by target name, which in theory should make transparent whether they're being built all from the same root build or independently. (And you won't need to install each sub-project before building the next.) (¹ Even if you don't go with this overall solution, using exported/imported targets is good practice that I would strongly encourage you to pursue anyway, if you aren't already doing that.) Even worse, two of our components are still automake-based. The cmake ExternalProject_Add() command did not solve the problem that some of them needs to be installed first before others can be compiled. For this you will need to use a superbuild, i.e. your dependee projects must also be built via ExternalProject_Add(). If the dependency projects aren't huge, it might be better to just port them to CMake. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to read and compile dynamically-generated list of cpp files
On 2014-02-03 11:44, gimmeamilk gimmeamilk wrote: I have a custom tool that processes a given list of IDL files and produces a number of .cpp and .h files as output. I want to add those files to the list of things to compile in my CMakeLists, and also model the dependencies those files have on the IDL. To keep things simple, I will state that any change to any of the IDL files should trigger a regeneration of all cpp/h. I have a custom command that takes care of running the generator tool and listing all the IDL files as dependencies. My issue is getting the subsequent list of cpp/h files into cmake at build-time. It is not possible to infer from the name of the IDL files what cpp files will be generated. My generator tool will, however, output the list of generated files to a text file. My usual approach to problems like these is to figure out a way to compute the list of output files *without* actually generating them (ideally by the generation tool having a mode to do that), and to then arrange (1) for that to happen at configure time, and (2) for configuration to depend on the input file(s). (For example, generating Python bindings with Shiboken is a similar problem.) Alternatively, you can create an external project that you configure and build as part of your build step. (This might work strangely on e.g. MSVC, however.) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Documenting command signatures
On 2014-02-03 14:44, Stephen Kelly wrote: Additionally, sphinx is not the only tool processing the rst. The kate editor also does syntax highlighting of the blocks. It should (but currently does not) highlight the 'invalid' cmake code as invalid. I guess you mean that in a '..code-block:: cmake' block, kate should apply the CMake HL rules? (What about other languages; I guess the same argument would apply to e.g. C++, Python, etc?) (Or do you mean that the CMake HL also doesn't mark the previous example as invalid? ...which it doesn't.) Additionally, it is not actually valid cmake code. While true, I think (Brad or someone can correct me if I'm wrong) the point is to support CMake reST extensions (automatic linking?) in the block. -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] AStyle or similar code beautifier
On 2014-01-31 02:01, Rob McDonald wrote: I'm interested in adding a code beautifier to my project. I'm looking at AStyle, but am open to others. Implementing a FindAStyle.cmake is pretty trivial. Likewise, implementing custom targets is pretty straightforward in the simple case. However, I thought there might be some canonical/idiomatic examples of this sort of thing. Any pointers to projects that do this particularly well? Are there any other code beautifiers that already have CMake support? By CMake support, do you mean that can beautify CMake script? Or that have an existing find module? (For a program like this I'm not sure I'd bother with a find module; often, find_program is all you really need.) As far as recommended C/C++ beautifiers, these days you might want to look at clang-format... parsing C++ is getting harder and harder with C++11 and later; as such it stands to reason that a tool that is backed by a well maintained, full-blown C++ parser is likely to be beneficial. I do use astyle for some of my own projects, but I've found that I have to do a non-trivial amount of additional pre- and post-processing to get good results. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Reverse logic
On 2014-01-29 19:09, Rob McDonald wrote:
I feel like this is a really dumb question, but I've got myself wrapped
around the axel
I'd like to use a negative conditional on a variable that may or may not be
defined... say USE_SYSTEM_FOO
So, I'd like to do something like this...
IF( NOT ${USE_SYSTEM_FOO} )
# Build my own FOO
ENDIF()
However, this does not work as desired. On the other hand, the following
version does have the desired behavior (shouldn't these be the same?).
IF( ${USE_SYSTEM_FOO} )
ELSE()
# Build my own FOO
ENDIF()
I tried a couple of combinations with DEFINED thrown in. They didn't work
as desired either. I didn't chase after a compound conditional like the
following simply due to ugliness
IF( NOT DEFINED ${USE_SYSTEM_FOO} OR NOT ${USE_SYSTEM_FOO} )
# Build my own FOO
ENDIF()
Expanding somewhat on JC's reply... do you realize you wrote e.g.
'if(NOT DEFINED ON)' here? ${NAME} means before evaluating anything
else, replace '${NAME}' with the value of the variable 'NAME' (or
nothing, if 'NAME' is unset).
Dereferencing is automatic in this context (especially 'DEFINED', which
operates on a variable name). So as JC wrote, you will probably have
better success omitting the dereference.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] RFC: add version to project() call
On 2014-01-29 09:58, Brad King wrote: I reverted the 'AddVersionToProjectCommand' topic from 'next' and replaced it with a 'project-version-variables' topic that adds a policy: Help: Format project command and variable documentation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dcc project: Add optional LANGUAGES keyword http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=16d040c9 project: Manage VERSION variables http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e142c5a write_basic_package_version_file: use PROJECT_VERSION http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41d2f2c4 The key is that project() only accepts VERSION when the policy is set to NEW. After release this will be automatic because one would need cmake_minimum_required() to specify a high enough version to understand the new project() signature and that would set the policy to NEW. Once the policy is set to NEW then we can freely clear variables when project() is not given a VERSION. Can one use project(VERSION) and later set the policy to OLD to get the old, don't-unset-the-variables behavior from that point onwards? -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: add version to project() call
On 2014-01-28 11:16, Jean-Christophe Fillion-Robin wrote: On Tue, Jan 28, 2014 at 9:10 AM, Brad King wrote: So our options are (1) Design new behavior in a way that requires a change to the project to activate. (2) Add a policy. The policy should only trigger when the project() command is about to unset a PROJECT_VERSION variable that was set by user code and not by a previous project() command. I would vote for (2), that way people using the latest and greatest of CMake won't have to enable any variable and it will work out of the box. This is also the case with (1), but (1) has the advantage that a project wishing to use the new feature that also contains a nested subproject that is not aware of (and would be broken by) the new feature can avoid breaking its nested project. Note that (as I understand it, anyway) the change to activate in (1) is using project(VERSION). IOW, with (1), until you either use project(VERSION) or manually set the variable (though it's hard to imagine why you would ever need to do the latter), you get the old behavior. Once you do either, you get the new behavior... unless you subsequently unset the variable, in which case you go back to the old behavior. (Also see Brad's reply.) I suppose with (2), requiring CMake = 3.0 would give you the new behavior unless you override the policy. I'm not in favor of this as I don't see any significant advantage over (1), but it can break nested projects that aren't expecting the new behavior. (If someone can present a strong reason why a policy would be better, that might change my mind.) -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools
On 2014-01-28 01:11, Andrew Hundt wrote: On Mon, Jan 27, 2014 at 3:30 PM, Matthew Woehlke wrote: I didn't look at it yet, but to be optimally useful I would hope that an implementation of generating doxygen documentation would: What we have won't be optimally useful, but it is very useful. I think if it is integrated the additional steps to reach optimal usefulness could be added over time. What's important is to not design the interface in a way that precludes adding features that are known/expected to be wanted :-). If you can avoid that trap, then there is no problem adding features incrementally. - implement two-step generation of tag files followed by the actual documentation - allow the user to provide a list of library names to be used as input tag files (assuming those targets use the same mechanism to generate documentation) - implement the above in a manner that allows the user some mechanism to define 'custom' targets with their own tag file(s) for external documentation - allow for circular linking (this is why tags and doc need to be separate steps; the tags have no dependencies, but the docs depend on the referenced tags; splitting the two avoids creating dependency cycles) These steps seem like a fairly complicated and specialized use case rather than a typical one. Perhaps I am mistaken? The ability to declare virtual dependencies is probably not unusual (I'd be surprised if there aren't at least a fair number of projects that would like to be able to link their own doc to Qt's doc, for example). Requiring an extra tag file for Qt is a bit unusual, though given the deficiencies in Qt's tag file (e.g. did you know it doesn't provide links for enum values?) I could imagine that is more because no one else has made the effort to extract the missing tags. Having circular tag dependencies is probably somewhat unusual. FWIW, the above is basically a description of the features of the 'generate doxygen documentation' implementation that tends to get copied around projects I'm working on. In particular, I have a project where I want to be able to link to Qt documentation, but due to deficiencies in how Qt generates its tag file, I actually need to generate my own supplementary tag file. I want to be able to use this just by listing Qt as a documentation dependency. The current version of the doxygen component wraps the support provided in a normal doxyfile and also provides several filters which allow a few extra languages to be documented, including the CMake language itself. That's clever. (Although with CMake 3.0 it would be better for CMake stuff to extract CMake's sphinx documentation system into a separate project and use that, as reST has become the preferred standard for CMake documentation.) Here is the full documentation of the doxygen component http://opensource.andreasschuh.com/cmake-basis/apidoc/latest/DocTools_8cmake.html#a6a37a66eb28f7969ef27b004f8faaa3a The main thing I don't see is tag file support. In any multi-library project that doesn't generate monolithic documentation, tag file support is not an optional feature. For my use, tag file support via target dependencies is pretty much a must have. I would also encourage you to consider what parameters are likely to be set project-wide and provide for them to default to a well-known variable (i.e. that could be set in the root CMakeLists.txt). For example, DOXYFILE, OUTPUT, HTML_EXTRA_STYLESHEET... -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Preparing for CMake 3.0.0-rc1
On 2014-01-27 16:58, Stephen Kelly wrote: Though I still don't like the behavior in the topic with project() commands without a specified VERSION and the CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND variable etc. I don't see why all the complexity is needed. From what I understand, the reason it was added is related to using add_subdirectory to add a self-contained/standalone project to host buildsystem. These VERSION variables are not alone in 'conflict possibilities' in that case. The 'sub-project' already may not use CMAKE_SOURCE_DIR Huh? Of course it can; it just needs to know that CMAKE_SOURCE_DIR != the sub-project's source dir. (In fact, testing this is probably the canonical way to determine if a project is embedded or not.) The reason for handling project(VERSION) specially was so that the parent project can start using project(VERSION) but arrange that the behavior of project() won't suddenly change within the subproject, in case the subproject is already using variables with the same names as the version variables that project() would otherwise newly unset. and there are other constraints which we don't have listed/documented anywhere. There are existing reasons why ExternalProject should be used instead of add_subdirectory in such cases. These VERSION variables can just be another reason. The 'host' buildsystem would itself have to set the VERSION, so it can ensure that that actually works with its sub-directory projects. There should not be special behavior with these VERSION variables. Or if there really should be, the reason should be in the commit message. I haven't looked at the actual commits; it may be their messages could be improved. I don't think it's so hard to avoid gratuitous breakage of nested projects however that it isn't worth doing so. And in fact, I believe it isn't just nested projects that would break, but any project that was using the same variable names as project(VERSION) would set... We really don't want the behavior change that, without any modification to CMakeLists.txt, project() suddenly unsets variables. (I suppose there is a policy argument that could be made there, but using CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND instead gives us reasonable behavior implicitly, and allows for projects nesting other projects to avoid breaking the nested projects.) That said, I'm assuming the behavior is as described in http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9108 and preceding, and NOT as described in http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9113 which is overkill. -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools
On 2014-01-27 14:48, Andrew Hundt wrote: On Thu, Jan 23, 2014 at 4:14 AM, Stephen Kelly wrote: Andrew Hundt wrote: I'm not well versed with the guts of git but are there any good ways to do some cleanup? If you have to ask, the details probably not something worth discussing here. Adding a commit removing them is not going to help. My previous paste showed that some of the biggest files are already deleted in the current tree. The level of my question my have been underestimated, because I was referring to git commands that strip data from the history. I created an issue to take another look at the size, thanks for the feedback. Possibly :-). I'd tend to agree with Stephen that this isn't the best place to get into a discussion of git history rewriting. But I'll also drop https://help.github.com/articles/remove-sensitive-data as a possible place to start looking. So far, out of what you listed, the documentation related stuff is most interesting to me as an upstream trying to find upstreamable (or generally useful) stuff in BASIS, or trying to find the gaps in cmake which are suitable for closing in cmake itself. Great, I too believe the basis_add_doc(), basis_add_doxygen_doc(), and basis_add_sphinx_doc() functions and related files would be perfect candidates to put in the Modules folder of CMake itself after whatever other minor tweaks are necessary. I didn't look at it yet, but to be optimally useful I would hope that an implementation of generating doxygen documentation would: - allow the user to specify the doxyfile.in (probably as a well-known variable; most projects will want to set it once) in addition to having a default one - implement two-step generation of tag files followed by the actual documentation - allow the user to provide a list of library names to be used as input tag files (assuming those targets use the same mechanism to generate documentation) - implement the above in a manner that allows the user some mechanism to define 'custom' targets with their own tag file(s) for external documentation - allow for circular linking (this is why tags and doc need to be separate steps; the tags have no dependencies, but the docs depend on the referenced tags; splitting the two avoids creating dependency cycles) In particular, I have a project where I want to be able to link to Qt documentation, but due to deficiencies in how Qt generates its tag file, I actually need to generate my own supplementary tag file. I want to be able to use this just by listing Qt as a documentation dependency. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Does a ctested build work with make -j
On 2014-01-27 17:12, Bill Hoffman wrote: On 1/27/2014 1:42 PM, John Cary wrote: It seems that after configuring with ctest enabled, make -j4 does 4 builds at once make ExperimentalStart ExperimentalBUild -j4 does only one build at a time. Is this behavior expected? Is there a way to get back to parallel builds when using ctest for the build? You want to add the -j to this cache variable: MAKECOMMAND What would be the difference in this context between MAKECOMMAND and CMAKE_MAKE_PROGRAM? I was just reading somewhere¹ that prefers the latter... (¹ https://github.com/Slicer/Slicer/commit/38905c9) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] RFC: add version to project() call
On 2014-01-15 16:25, Alexander Neundorf wrote:
On Wednesday 15 January 2014, Alexander Neundorf wrote:
And, to actually produce the breakage, at some place the VERSION argument
must have been added.
With the current state of my branch, this could be worked around by
unsetting the guard variable:
project(Foo VERSION 1.2.3)
unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
add_subdir(B)
This way B would be protected from that change in behaviour.
I could also add more logic, to try to detect if PROJECT_VERSION has been set
manually, e.g. project() could reset PROJECT_VERSION only if it has the same
value as ${${ParentProjectName}_VERSION}. Then it would only break if there
was a manual set(PROJECT_VERSION ...) before a project() call without VERSION,
and if that manually set version was the same as the version in the parent
project.
IMHO your last suggestion (very good idea, btw!) is more than adequate,
especially given the original weakness of my objection (which was
always more along the lines of did you consider this case, and should
we worry about it?).
--
Matthew
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Searching once
On 2014-01-15 11:11, Williams, Norman K wrote: You want the load_cache command: [snip] An *installed* project (what Al mentioned in his original e-mail) probably doesn't have a cache... this would only work if using the build-directory version of the dependency project. The solution I proposed is probably better, as it can be used with both a built or installed dependency (assuming that the installed version references other installed versions of its own dependencies and/or the builds of the same are still available). (OTOH if that last part isn't true, the transitive dependencies just won't be used, with either technique.) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] RFC: add version to project() call
On 2014-01-14 10:37, Brad King wrote: On 01/13/2014 01:38 PM, Alexander Neundorf wrote: does this require a policy now ? Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a project(Foo) call in a subdir, which would now unset Foo_VERSION_MAJOR. The same for PROJECT_VERSION_MAJOR, but this is maybe less likely. I don't think project(Foo) needs to affect Foo_VERSION_* when no VERSION argument is given (but should handle empty VERSION ). It should still handle PROJECT_VERSION_* to ensure consistency with PROJECT_NAME. That may need a policy, but it will be tricky because we need to know if the value came from a previous project() call or a user set() in order to know when to trigger compatibility. Perhaps project(... VERSION ...) can set some cmMakefile variable internally that says the project knows about versions so it is okay project(Foo) calls to unset them in subdirs. Then we won't need any policy because there is no change in behavior without modifying the project to add at least one VERSION to a project() command. While that sounds good for 99.9% of cases, what about the case of project A that includes project B, where B is not updated, but A decides to start using project(...VERSION...). Now if B was using PROJECT_VERSION internally, it is broken. (Note that I'm implying that B is e.g. a separate repository that may not be as easy to update/fix as A.) That's an edge case though... not sure it's worth worrying about, but just saying... @Daniel, there is a CMAKE_PROJECT_NAME? I've always used just PROJECT_NAME... (Is PROJECT_NAME deprecated?) Anyway, while *hopefully* no one is setting e.g. CMAKE_PROJECT_VERSION there's still risk that they are. -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: add version to project() call
On 2014-01-14 14:11, Daniel Pfeifer wrote: 2014/1/14 Matthew Woehlke mw_tr...@users.sourceforge.net: @Daniel, there is a CMAKE_PROJECT_NAME? http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:CMAKE_PROJECT_NAME http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:PROJECT_NAME The documentation for both variables is misleading. As far as I understand it, PROJECT_NAME is the name of the current project, while CMAKE_PROJECT_NAME us the name of the top-level project. Ah, I see. I always use PROJECT_NAME as a way of not repeating the name of the target being built (this is in a project that generally has one library or executable per directory, and calls project() for each of them). In that case, I'd think CMAKE_PROJECT_VERSION would not be the correct thing to set (except maybe for the very first project() seen). Else I think we'd risk making this even more confusing ;-). -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: add version to project() call
On 2014-01-14 18:00, Alexander Neundorf wrote: On Tuesday 14 January 2014, Matthew Woehlke wrote: While that sounds good for 99.9% of cases, what about the case of project A that includes project B, where B is not updated, but A decides to start using project(...VERSION...). Now if B was using PROJECT_VERSION internally, it is broken. (Note that I'm implying that B is e.g. a separate repository that may not be as easy to update/fix as A.) You mean CMakeLists.txt: project(Foo VERSION 1.2.3) add_subdir(B) B/CMakeLists.txt: set(PROJECT_VERSION 4.5.6) project(Bar) Indeed. In that case, PROJECT_VERSION will be unset afterwards. Exactly. I wanted to point it out, but as that's probably unusual, I would be okay ignoring that case. If it would be B/CMakeLists.txt: project(Bar) set(PROJECT_VERSION 4.5.6) everything is fine. ...until B/C/CMakeLists.txt also calls project() :-). Basically, you (can) get into trouble if you update your project to use project(VERSION) and also have an external sub-project that tries to use PROJECT_VERSION. However, as much as folks¹ occasionally bleat about this use case (having an embedded external project), I suspect it's not actually very common², and anyway there is only a problem when the sub-project *also* uses PROJECT_VERSION (which I suspect is also rare in general, and more so the intersection of the two). Again, given the above, I've no objection to breaking that case, which may well only exist in the hypothetical sense with no 'in the wild' instances actually existing. (¹ Myself included; this thread being a case in point.) (² ...though I do know offhand that ParaView does so with VTK.) -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Searching once
On 2014-01-14 18:47, Al Niessner wrote: [snip] Is it possible to have a dependent project use configuration from a previously installed project? - IF the dependent project creates a ProjectConfig.cmake, and - IF said ProjectConfig.cmake sets the necessary variables referencing where its versions of dependencies can be found, and - IF the dependee project finds the dependent project before any other dependencies ...then I think yes. The second is a little unusual though; is the dependent project under your control? (You can also have e.g. a 'USE_DEPENDENCIES_FILE' for the dependent project if you don't want to force that projects versions of its own dependencies on downstream users. Which probably you shouldn't. Same general idea, though; the dependent project has to provide the information and the dependee has to use it.) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] RFC: add version to project() call
On 2014-01-10 11:01, Jean-Christophe Fillion-Robin wrote:
Would it make sense to have project(Foo VERSION 1.2.3) set the variables:
${PROJECT_NAME}_PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)
That way, the variable would remain even if project is called with VERSION
in sub directory.
How is that different? Do you mean to drop the PROJECT_VERSION_{...}
entirely? That doesn't seem desirable for symmetry with the other
PROJECT_{...} variables.
I think I'm with Brad; set the PROJECT_VERSION_{...} and
${PROJECT_NAME}_VERSION_{...} (note; no extra literal 'PROJECT') as
usual. Always. Whether or not VERSION was specified (i.e. unset the
corresponding variables in such case).
Folks that use the PROJECT_{...} forms hopefully know what they are
doing, otherwise people are hopefully using the ${PROJECT_NAME}_{...}
forms instead.
Related: Do these affect the version properties of libraries? (Because
OTOH if it does, I can imagine wanting to say VERSION once at the root
and have it inherit downwards unless overridden. Maybe though that's a
reason for it to not do so.)
--
Matthew
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: add version to project() call
On 2014-01-10 15:15, Alexander Neundorf wrote:
On Friday 10 January 2014, Matthew Woehlke wrote:
Related: Do these affect the version properties of libraries? (Because
OTOH if it does, I can imagine wanting to say VERSION once at the root
and have it inherit downwards unless overridden. Maybe though that's a
reason for it to not do so.)
I thought about that too.
Even without it, with the patch you now already have a standard form:
set_target_properties( PROPERTIES VERSIOn ${PROJECT_VERSION} )
Automatically doesn't really work, or at least it would have to be switched
on:
set(CMAKE_USE_PROJECT_VERSION_FOR_LIBRARIES TRUE)
and then that property would automatically use ${PROJECT_VERSION}.
The problem with that is that it doesn't work if I use an unversioned
project somewhere, when what I want is to use the version of the project
from a parent directory. Unfortunately I can't think of a way to make
that work properly that doesn't risk breaking things if Project A
doesn't use it, but is built as a child of Project B which does (i.e.
you don't want A to use B's version).
Hence my disinclination to try to address that just now :-).
(The least evil option I can come up with offhand is to accept
'INHERIT' as the version and then always use the current-project version
by default. At least that way, e.g. in the above example A would
continue to get no version, so you haven't broken BC. You'd still have
to explicitly set the project version on every project to use automatic
versioning, even if it is 'INHERIT', hence why it's not a perfect solution.)
--
Matthew
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --help-custom-modules compatibility
On 2014-01-08 11:26, Brad King wrote: On 11/20/2013 07:22 PM, Stephen Kelly wrote: The solution is still to re-implement the --help-custom-modules myman.1 command-line behavior as a special case with warnings. Alex and Steve will have to work out who takes responsibility for that. In order to more gracefully degrade behavior I've made this change: cmake: Implement placeholder --help-custom-modules compatibility http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b1772946 Now it generates the requested file without error but the content is just a placeholder explaining that the functionality was dropped. It still produces a warning of course. Since you mentioned it, I was wondering if this is related to a feature I was asking about, but I don't understand how it works; it seems to only ever generate a short boilerplate text. Is this meant to take a CMake module that is not part of the CMake distribution and extract and format the documentation from the same? Because that is a feature I really wish CMake 3.0 would provide. (I know you (Brad) previously mentioned that you don't want to in order to avoid committing to any sort of compatibility guarantees with respect to the same. But it still seems to me that such decision makes it unnecessarily hard for third parties to provide documented CMake modules.) -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --help-custom-modules compatibility
On 2014-01-08 12:57, Brad King wrote: On 01/08/2014 12:00 PM, Matthew Woehlke wrote: Since you mentioned it, I was wondering if this is related to a feature I was asking about, but I don't understand how it works; it seems to only ever generate a short boilerplate text. Is this meant to take a CMake module that is not part of the CMake distribution and extract and format the documentation from the same? The old documentation system exposed this feature through the old --help-custom-modules option. The new documentation system does not. This commit is about making old builds not totally break. Because that is a feature I really wish CMake 3.0 would provide. (I know you (Brad) previously mentioned that you don't want to in order to avoid committing to any sort of compatibility guarantees with respect to the same. But it still seems to me that such decision makes it unnecessarily hard for third parties to provide documented CMake modules.) Anyone could fork CMake's Utilities/Sphinx infrastructure and provide it as a separate distribution with support and compatibility guarantees. I just do not want to provide it with CMake and constrain CMake's own documentation from evolving just to support external documents. The compatibility issue in this thread is a perfect example of why. From my perspective, that's sort-of the point here... CMake used to provide for generating documentation from external modules. Now it doesn't. And it seems that KDE is also feeling that pain. I'm not convinced that's a good thing. I get that you don't want to make things harder for developers, but doing so at the expense of making things harder for users doesn't seem like the best trade-off. I'm also not sure I'm convinced by the compatibility argument. If you can't guarantee compatibility, then don't. Projects that want to use CMake to generate documentation for their CMake modules simply must use the version of CMake their documentation was written for to do so. (And update as necessary to meet the previous condition. Or fork the documentation system anyway.) -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] documenting a CMake 'use' file
On 2013-12-19 11:21, Brad King wrote:
On 12/18/2013 12:13 PM, Matthew Woehlke wrote:
Does this mean one cannot e.g. use the CMake extensions and/or link to
topics in CMake's documentation (provided a known location of the same)?
Correct. Sphinx does not support magic cross-referencing to external
documents. Generating such links would require folding the document
into the build process of CMake itself. Without that the links have
to be spelled out like any other external hyperlinks (http://...).
If that's really true, that's a pretty big drawback of docutils vs. e.g.
doxygen, which has very good support for external references.
Considering that docutils is supposed to be the de-facto standard for
documenting Python, which has all sorts of external modules, I'd be
surprised if there isn't a solution to this problem already existing.
Even if not, from what I know of reST, it wouldn't be all that difficult
to create one. (At worst, you'd need to introduce a new interpreted text
role for external links, but that's not exactly the end of the world.
And if you reuse doxygen's tagfile format, suddenly you can link to
doxygen-generated C++ doxygen from reST :-). Again, assuming that hasn't
already been done...)
So a file that comes in a project needs to be documented with the
documentation of the project. Every project has that problem with
all its file types.
Sure. I just feel like this should be solvable like:
find_package(CMakeDocUtils)
include(${CMakeDocUtilsUseFile})
cmake_generate_documentation(...)
...where ideally CMakeDocUtils is provided by CMake itself (albeit free
to rely on being able to find other external tools, e.g. Python).
Other projects will have to do their own thing.
If they want to copy and re-use the infrastructure out of the
CMake source tree they are free to do so but will have to maintain
it themselves.
This places a significant maintenance burden on projects and leads to
their being umpteen copies of the CMake reST additions. For small
projects, this could even end up being more code that the project
itself! I fail to see how this is in any way other than a Bad Thing.
Another approach is to use sed+rst2html to extract
and process .rst markup from inside .cmake file comments.
Do you really anticipate that the syntax for declaring documentation is
going to change? I would think that, at the very least, something to
extract the reST text from a CMake module should be provided by CMake.
(Again, I'll assert that such utility does NOT need to be self-contained
and is free to depend on e.g. Python being available.)
From the perspective as a user wanting to do this, the question is if I
spend a *lot* of effort reinventing the wheel in my own project, which
may initially get the job done but incurs an ongoing maintenance burden
(and/or rapidly bitrots), or do I spend that effort taking CMake's
existing documentation support and making it available to external
users, so that it benefits *everyone* and distributes the maintenance
burden?
Hopefully that helps to understand my perspective.
Thanks,
--
Matthew
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] documenting a CMake 'use' file
On 2014-01-08 15:35, Brad King wrote: On 01/08/2014 01:52 PM, Matthew Woehlke wrote: On 2013-12-19 11:21, Brad King wrote: Sphinx does not support magic cross-referencing to external documents. If that's really true, that's a pretty big drawback of docutils vs. e.g. doxygen, which has very good support for external references. I can't say for sure it is not possible. Perhaps there is a way to export Sphinx Domain objects for reference by external documents whose build configuration references a specific publication URL of the upstream objects, but I'm not familiar with it. Neither am I :-), but I would be surprised if there isn't some implementation somewhere. I will try to look into this some time and will get back to you if I find anything. This places a significant maintenance burden on projects and leads to their being umpteen copies of the CMake reST additions. Ideally someone would create a dedicated CMake reST documentation project like the CMakeDocUtils package in your example. I debated whether or not to suggest that in the previous mail due to not knowing how it would work out with the CMake project itself. But... CMake's copy could be a downstream client just like any other project that wants to document CMake domain objects. ...since it seems that CMake would be amenable to using this, then I agree, this is probably the best solution. I think we are on the same page now; thanks for a productive discussion! With this approach projects could provide documented modules even if they do not build with CMake (e.g. Qt5). That's a good point :-). Do you really anticipate that the syntax for declaring documentation is going to change? Yes. The new documentation system is very young and will likely change as it matures. To be clear, I meant *only* the '#.rst' syntax (i.e. the code to extract the reST markup from a CMake module). I would not expect *that* to change again? Stuff within the reST domain, sure, I can see that changing. -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] define_property deprecated?
On 2013-12-18 11:52, Brad King wrote: On 12/12/2013 01:19 PM, Matthew Woehlke wrote: Loosely related: is there a way to make export() and install(EXPORT) set these properties for exported targets? Not of which I'm aware. You can have your package configuration file add them after loading the imported targets, but that would be a (centralized) workaround. For now I probably just won't support importing wrapped libraries. This would probably be a useful feature to add. I can see it being useful in any case where a project is sort-of building their own language/bindings/etc. on top of CMake (e.g. UseJava could possibly benefit also, to name at least one other). -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] documenting a CMake 'use' file
On 2013-12-18 11:52, Brad King wrote: On 12/10/2013 04:46 PM, Matthew Woehlke wrote: Why is the copyright notice *after* the documentation? In the old documentation system the extractor only supported docs in the leading comment so the notice *had* to be later. Now it is just a convention. Can we change that? :-) ...or at least change the documentation to make it clear that it is a convention and not / no longer mandatory? (For UseShiboken.cmake, I'm going to leave the copyright first... if that means the doc - which is RST anyway - can only be extracted with CMake ≥ 3.x, then that'll just have to do ;-). I'm not comfortable with the leading doc effectively hiding the copyright statement and wouldn't be in the least surprised if upstream were to reject having it follow the initial doc.) Thanks for the clarification, -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] documenting a CMake 'use' file
On 2013-12-18 11:52, Brad King wrote: On 12/10/2013 04:57 PM, Matthew Woehlke wrote: Thanks. Are there any guidelines on documenting the parameters of CMake functions/macros? I didn't see that in the mentioned document. No convention has been established so there is none to document yet. We can see if any dominant form emerges. * ``VAR``: Output variable into which the result will be placed. * ``SEP``: String used to join adjacent tokens. * ``ARGN``: Tokens to be joined. I suggest using a definition list instead. Like this? :``GENERATE_FLAGS``: (List) Additional options to pass to Shiboken. That's what I ended up using... maybe should have followed up to mention that :-). Thanks. Related; is there a way to turn a CMake module file (that is outside of CMake's module directory) into (e.g. HTML) documentation? No, and I don't want there to be a way to do this with cmake. It will limit our ability to refactor the internal document generation in the future. Does this mean one cannot e.g. use the CMake extensions and/or link to topics in CMake's documentation (provided a known location of the same)? Maybe it would help if I rephrase the question: I have a CMake module that is going to be provided by another project (i.e. will not live in the CMake repository). It has RST documentation. I would like to be able to generate HTML from that. How would you recommend to do so? I expect this is going to be not an unusual problem... -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Set alias in cmake script
On 2013-12-18 04:19, Stefan wrote: I'm not sure if this is possible or not, but I'm trying to set an (environment) alias in my cmake script: alias makefast=make -j $(cat /proc/cpuinfo | grep -c processor) You can't do that as such; the [alias] command would need to run in the context of the parent shell process, and that's not possible (not in any sane manner, at least). The closest you could get would be to write in your .bashrc a function 'cmake' that called 'command cmake $@' and then sets your alias. Other comments: I'd multiply this by about 5/4; general experience seems to be that you want the number of jobs to be a bit higher than the actual number of CPU's in order to keep them busy when jobs are waiting on disk I/O. Also, have you tried ninja¹? IME it's faster than make, and defaults to #CPU's + 2 jobs unless you tell it otherwise (so you wouldn't need 'makefast', just 'ninja'). (¹ http://martine.github.io/ninja/) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
[cmake-developers] cmake build does too much work
I've been working on a project lately that isn't *that* massively large, but has an unusually high number of library and executable targets. One thing that's been bugging me is that any trivial change in a lower level library causes more than a hundred targets to be relinked, for no good reason I know of. Now, I *do* get that relinking is good if the library ABI changes. However, that's not the case here, and I am wondering if it would be possible for CMake to generate an additional, intermediary step after library linking to somehow export a file representing the ABI of the library (with overwrite checks to not modify the file if the ABI has not changed), and to use *those*, rather than the actual libraries, as the dependencies for targets linking to the libraries. I think this could produce a significant speed-up for incremental builds in some cases, as it would allow the build to short-circuit the relink of many targets when it turns out a library's ABI has not changed. Does this sound like something CMake could/should do? (I'm thinking something like running objdump on the resulting library with suitable arguments and doing a copy_if_different on the output. I guess this would only apply to shared libraries, and probably should be an optional feature.) -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake build does too much work
On 2013-12-11 17:40, Bill Hoffman wrote: On 12/11/2013 5:13 PM, Matthew Woehlke wrote: I've been working on a project lately that isn't *that* massively large, but has an unusually high number of library and executable targets. One thing that's been bugging me is that any trivial change in a lower level library causes more than a hundred targets to be relinked, for no good reason I know of. Now, I *do* get that relinking is good if the library ABI changes. However, that's not the case here, and I am wondering if it would be possible for CMake to generate an additional, intermediary step after library linking to somehow export a file representing the ABI of the library (with overwrite checks to not modify the file if the ABI has not changed), and to use *those*, rather than the actual libraries, as the dependencies for targets linking to the libraries. I think this could produce a significant speed-up for incremental builds in some cases, as it would allow the build to short-circuit the relink of many targets when it turns out a library's ABI has not changed. Does this sound like something CMake could/should do? (I'm thinking something like running objdump on the resulting library with suitable arguments and doing a copy_if_different on the output. I guess this would only apply to shared libraries, and probably should be an optional feature.) There is this property: http://www.cmake.org/cmake/help/git-master/variable/CMAKE_LINK_DEPENDS_NO_SHARED.html Yes, but that can lead to a broken build if the ABI does change. (Hi, Stephen. I still oppose making the above on by default due to the possibility of broken builds. The difference here is that we are actually doing extra work in order to determine if a relink is necessary of if it is *safe* to skip it. IOW, I still choose correctness over performance; the difference is that the proposed technique would let us have both :-).) The other option sounds interesting but hard to implement in a cross platform manner. Agreed, but even if it only worked on some platforms it could be a significant benefit to them. It's the sort of feature that can just be ignored if not supported with no loss in correctness (only performance). Actually because of its .lib files I wonder if maybe Windows either already doesn't have this problem, or at least would be much easier to provide this feature there. (I'd be mainly interested in Linux.) Hmm, come to think of it, if this were to be implemented, I wonder if it is faster for the ABI stamp to be an actual dump of the ABI, or a checksum (e.g. md5 / sha256) of the ABI dump... The latter would trade the extra cost computing the checksum for I/O; not needing to write the ABI dump to disk at all if it can be read via a pipe, and then only needing to read and possibly write a few bytes for the 'stamp' file. Actually, I suppose the build tool could also do this, but then the benefit is only realized by users of that build tool. (On the other hand, all users of that build tool would realize the benefit, and not just users of CMake.) Still, this now feels worth cross-posting to ninja... -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake build does too much work
On 2013-12-11 17:13, Matthew Woehlke wrote: I've been working on a project lately that isn't *that* massively large, but has an unusually high number of library and executable targets. One thing that's been bugging me is that any trivial change in a lower level library causes more than a hundred targets to be relinked, for no good reason I know of. Now, I *do* get that relinking is good if the library ABI changes. However, that's not the case here, and I am wondering if it would be possible for CMake to generate an additional, intermediary step after library linking to somehow export a file representing the ABI of the library (with overwrite checks to not modify the file if the ABI has not changed), and to use *those*, rather than the actual libraries, as the dependencies for targets linking to the libraries. I think this could produce a significant speed-up for incremental builds in some cases, as it would allow the build to short-circuit the relink of many targets when it turns out a library's ABI has not changed. Does this sound like something CMake could/should do? (I'm thinking something like running objdump on the resulting library with suitable arguments and doing a copy_if_different on the output. I guess this would only apply to shared libraries, and probably should be an optional feature.) FYI, the ninja folks mentioned that GYP already does this for Linux/Mac/Win... maybe we (CMake) could borrow their work? -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake build does too much work
On 2013-12-11 19:21, Ben Boeckel wrote: On Wed, Dec 11, 2013 at 17:13:00 -0500, Matthew Woehlke wrote: Now, I *do* get that relinking is good if the library ABI changes. However, that's not the case here, and I am wondering if it would be possible for CMake to generate an additional, intermediary step after library linking to somehow export a file representing the ABI of the library (with overwrite checks to not modify the file if the ABI has not changed), and to use *those*, rather than the actual libraries, as the dependencies for targets linking to the libraries. I think this could produce a significant speed-up for incremental builds in some cases, as it would allow the build to short-circuit the relink of many targets when it turns out a library's ABI has not changed. While the tool I posted in the other message is a possibility, how would you deal with inline functions changing? Same with template implementations? I don't think this is relevant? In these cases, a header is changing, which will (hopefully) lead to the source files using that header being rebuilt, which will cause the library to relink anyway. (And if the sources *aren't* rebuilt, I don't think relinking will help?) Whether or not the sources of library B have correct dependencies on the headers of library A is, I believe, orthogonal to this problem, which is *only* about link-level dependencies. IOW the only rule affected would be 'libb.so: liba.so'. Which build systems actually have that level of granularity? Does XCode or VS track external dependencies on the file level? I don't *think* make and ninja do so, since after a GCC upgrade, my trees don't all of a sudden do a full rebuild (and after upgrading from Fedora N to N+1, nuking build trees is usually on the menu due to new soversions of libraries shifting around; a simple rebuild misses this). I would expect the behavior for external dependencies would not change; they would either trigger rebuilds or not the same as they do currently. (Since of course we cannot rely on having 'ABI stamp files' for any external libraries...) I'm *mainly* having problems within a single CMake project, which is what this would affect. It might have some downstream effect due to fewer libraries within the project changing to trigger downstream rebuilds, but that would be more incidental. -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] documenting a CMake 'use' file
On 2013-11-22 15:49, Brad King wrote: On 11/22/2013 03:24 PM, Matthew Woehlke wrote: In particular, I am wondering if it is possible, and if so, what recommendations there are if any, to document functions 'doxygen style', i.e. the documentation immediately preceding the function definitions, rather than all at the top. See the cmake-developer.7 manual Module Documentation section. Why is the copyright notice *after* the documentation? It seems like it should rather be first. (In almost all cases I have seen copyright notices they are the very first thing in the file so that they are prominent. Having it after may mean it is not visible until scrolling down some pages...) -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] documenting a CMake 'use' file
On 2013-11-22 15:49, Brad King wrote: On 11/22/2013 03:24 PM, Matthew Woehlke wrote: In particular, I am wondering if it is possible, and if so, what recommendations there are if any, to document functions 'doxygen style', i.e. the documentation immediately preceding the function definitions, rather than all at the top. See the cmake-developer.7 manual Module Documentation section. Thanks. Are there any guidelines on documenting the parameters of CMake functions/macros? I didn't see that in the mentioned document. So far I'm doing this: .. command:: sbk_cat Concatenate strings in a list into a single string:: sbk_cat(out , a b c d e) Parameters -- * ``VAR``: Output variable into which the result will be placed. * ``SEP``: String used to join adjacent tokens. * ``ARGN``: Tokens to be joined. Related; is there a way to turn a CMake module file (that is outside of CMake's module directory) into (e.g. HTML) documentation? -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Converting cmake_parse_arguments to a builtin command
On 2013-12-06 14:51, Daniele E. Domenichelli wrote: Are you sure you don't want the command to be renamed to parse_arguments? The only commands containing cmake looks strictly related to cmake, and the arguments parsing does not look that much related... FWIW, I was sort-of hoping it would be. If so, CMakeParseArguments.cmake can be left with a simple stub to call the new version. As a bonus, the new version could itself take named arguments instead of positional with a flag whether or not to skip empty (default = keep) with the compatibility wrapper instead specifying to skip, and no policy would be needed (if you want the new behavior, just use parse_arguments). -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Minor regression in --version results for CMake 2.8.12.1 (A FALSE ALARM)
On 2013-12-05 02:36, Alan W. Irwin wrote: Sorry, this turned out to be a false alarm. Despite which cmake telling me I was using cmake-2.8.12.1 [snip] ...which is, of course, why you should always use type in bash rather than which :-). type, being a shell built-in, will tell you what bash will *actually* run, hashing - and shell builtins, and functions, and aliases - included. -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] [CMAKE] Getting compilation date through CMake
On 2013-12-05 15:46, Fraser Hutchison wrote:
If you can specify CMake version 2.8.11 as a minimum, you could use
the string(TIMESTAMP ...) command instead:
string(TIMESTAMP _output %d/%m/%Y)
Bear in mind that these only execute when CMake runs (i.e. at configure time)
rather than at build time, so strictly-speaking you're not actually grabbing the
compile date.
Of course you could put that in a CMake script and execute it with e.g.
'${CMAKE_COMMAND} -p ${CMAKE_CURRENT_SOURCE_DIR}/get_date.cmake' in a
custom command :-). Then it would truly be the compile date. (Needless
to say, the script would need to write the date into some generated
source file, e.g. with configure_file.)
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get all targets a target depends on
On 2013-11-29 11:34, Dominik Bernhardt wrote: On 2013-11-29 17:26, Matthew Woehlke wrote: On 2013-11-29 03:07, Dominik Bernhardt wrote: is it possible to get a list of all targets on which a particular target depends on. The only idea I have so far is to query the LINK_LIBRARIES target property. However that would only allow to get the libraries I'm linking with and for example no custom targets. Any ideas how to accomplish this task? I guess you want to make use of this information in CMake, and are not just curious? you are absolutely right. It's not just for information. I have a lot of targets that I import and I would like query all dependent targets of my applications to figure out which DLLs are needed to run the application. I would use this information to either set the PATH environment or copy the DLLs to my binary directory I'm not sure this can be made to work correctly in all cases. If you have e.g. imported libB which has a private depencency on libA, and are trying to build exeC linked to libB, libA won't be reported as a dependency of libB (and may not even be exported), but is still required to run exeC. That said, given your use case, I'm not sure why you need to know about other than link libraries? How would a custom dependency create a runtime link dependency? -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Making cmake automatically pick up changes to directory contents.
On 2013-12-02 12:58, bi...@billw.mail1.co.uk wrote: I just finished converting a large project from VC project files to Cmake generated ones and am using file GLOBing to generate the file lists for builds. This is working fine and I don't see the benefit to explicitly specifying every file. I know the docs recommend not using GLOB, but the only reason given is that cmake won't do a rebuild when new files are added. This seems like a limitation of the build system not a good reason. More like a design choice made for various reasons; a major one (as Bill alludes to) being performance. So is there any good way to cause a CMake rebuild of a project when the contents of the directory change? I am thinking something like outputting the directory listing to a file (i.e. dir /b/s filelist.txt) and adding that file as some sort of dependency to the project. But I don't know exactly how this would be done in practice. Any ideas or canonical methods? Idea: don't do that :-). Besides what Bill mentioned, if you're working on a project with more than one instance of the source tree (i.e. you are using VCS¹ and/or have more than one developer), explicitly listing files helps with 'forgot to add' errors since other builds will explicitly try to build a file that doesn't exist, thus making such mistakes obvious, rather than failing at some other point because a source file is missing. (¹ I recommend to - and do - use VCS even for personal projects. With most DVCS's e.g. git, it's really easy to do so, and having a history is invaluable, especially if the project later grows. Plus it's ever so much easier to work on a project from multiple machines :-).) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get all targets a target depends on
On 2013-11-29 03:07, Dominik Bernhardt wrote: is it possible to get a list of all targets on which a particular target depends on. The only idea I have so far is to query the LINK_LIBRARIES target property. However that would only allow to get the libraries I'm linking with and for example no custom targets. Any ideas how to accomplish this task? I guess you want to make use of this information in CMake, and are not just curious? If you just want to know for your own information, you could use the Ninja generator; ninja has the ability to output a dependency graph as a dot file. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
[cmake-developers] documenting a CMake 'use' file
Now that CMake is using RST for documentations, is there a good guide for how to document modules that mainly provide new functions? In particular, I am wondering if it is possible, and if so, what recommendations there are if any, to document functions 'doxygen style', i.e. the documentation immediately preceding the function definitions, rather than all at the top. And/or, what parts of a CMake module are extracted for documentation and is there a way to say 'ignore comments after this point'? Any pointers are appreciated. Thanks, -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] building a library named 'general'
On 2013-11-19 19:07, Michael DiCuccio wrote: Suppose you have a library named general: - add_library(general foo bar) - and then try to link it into an application: - add_executable(myapp baz) target_link_libraries(myapp general) - cmake complains about the fact that 'general' is a reserved keyword, and I have found no way to force or finagle linkage against a library named 'libgeneral'. Name the target something else (e.g. 'libgeneral') and modify its OUTPUT_NAME? (See set_target_properties and the OUTPUT_NAME property.) If all you need is to produce a 'libgeneral.so', that may suffice. If you also need the target name to be 'general'... -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Invalid/Reserved target names
On 2013-11-15 04:05, Nils Gladitz wrote: I would like to hijack/extend Stephen's changes in 05f5fde0eb83c0e49aab3214f28a098861aa3313 to also disallow target names that have been implicitly reserved by some of the generators. This list might not be complete but I assume it would be at least: all, help, clean, edit_cache, rebuild_cache, test, package, package_source, PACKAGE, ZERO_CHECK Would anyone be opposed to this? Could I extend the existing policy, should I create a new one or would it be ok without any policy even? I haven't done so yet, but I've considered once or twice creating a 'clean' target in case the generator is ninja. Possibly someone has already done that. Maybe only disallow target names that the generator actually uses? (Or should we teach CMake to make a 'clean' target for ninja? :-) That could probably be done separately, but if 'clean' is disallowed unconditionally it feels like that should be on the radar of things to do.) -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja jumping progress indicator
On 2013-11-11 03:15, Nils Gladitz wrote: Could output of the ninja progress indicator be omitted for when it reruns cmake somehow? It outputs 1/1 and then goes on to report the actual progress e.g. 1/916 ... What else can you do? Until you re-run CMake, there is no way to know how many edges need to be executed. Even if ninja were to show the maximum possible number of edges, that could be too small e.g. because you've added a bunch of new targets since the last build. That said, I also don't see what CMake could possibly do to affect this... The initial 1/1 confuses QtCreator which does not allow for the progress indicator to jump around this way: https://bugreports.qt-project.org/browse/QTCREATORBUG-10332 They do not seem to want to work around this. Is there anything we could do in CMake instead? If by they you mean Qt Creator, well... that's unfortunate, because it's clearly their problem. (Maybe you could use a different IDE? ;-) I happen to like KDevelop...) Anyway, they seem to be looking at the progress wrong; will comment in the bug report. -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] PROJECT_SOURCE_DIR ...
On 2013-11-10 14:12, Witold E Wolski wrote:
And [project_{SOURCE,BINARY}_DIR] are the same as
CMAKE_BINARY_DIR, or CMAKE_SOURCE_DIR.
So why one would use the ${PROJECT}_BINARY_DIR variables?
Not necessarily. Consider:
src/CMakeLists.txt
project(A)
src/b/CMakeLists.txt
project(B)
src/b/tests/CMakeLists.txt
...etc. Now, e.g. B_BINARY_DIR can be different from both
CMAKE_BINARY_DIR and CMAKE_CURRENT_BINARY_DIR.
Additionally, your entire project might be included by some other
CMakeLists.txt such that (continuing with the above example)
A_BINARY_DIR != CMAKE_BINARY_DIR. So it's good practice when defining
project-specific macros to use project_{SOURCE,BINARY}_DIR where
project is the project you declare at the top level directory of your
project to refer to the top level directory of your project. (And only
use CMAKE_{SOURCE,BINARY}_DIR when you really mean the source/build root
and don't care if that's your project's top level directory or not.)
Basically, you can be more confident that you know where in your tree
project_{SOURCE,BINARY}_DIR refers than you can of
CMAKE_{SOURCE,BINARY}_DIR.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments
On 2013-11-06 13:57, Brad King wrote:
On 11/06/2013 01:32 PM, Alexander Neundorf wrote:
Adding proper named argument handling to cmake_parse_arguments() itself is
somewhat complicated since it can't make use of cmake_parse_arguments() ;-)
Since the need for this is so common, perhaps we should provide a
C++-implemented command to do it, e.g. cmake_command_options().
We would need to carefully design the interface here first of course.
FWIW, I prefer the name [cmake_]parse_arguments :-).
Is there not already a C++ implementation something like this? (Or else
how do the existing C++ commands do argument parsing?) If it is C++, I
guess it would be possible for it to not have the limitation of being
unable to parse its own arguments? (Actually, in either case, it seems
that the implementation should be able to have all the 'real work' in a
helper that is called once to parse arguments to the command itself,
then again to parse the arguments the user wants to parse.)
In any case, it would be nice if we could reimplement
cmake_parse_arguments so that it has the same signature but the
implementation would newly just wrap the new C++ version.
What if we had something like:
parse_arguments(
PREFIX _
FLAG_OPTIONS ...
VALUE_OPTIONS ...
LIST_OPTIONS ...
ARGS ...)
...where everything after ARGS is no longer considered an argument to
parse_arguments itself. Also, 'parse_arguments(... IN LISTS ...)'
(instead of using 'ARGS'), taking names of list variables containing
arguments to be parsed (similar to 'IN LISTS' of foreach).
{FLAG,VALUE,LIST}_OPTIONS would accept one or more strings containing
names of argument keywords, subject to recursive list expansion (should
be safe - keywords should not contain ';' - and avoids breakage if
option name lists are given in quoted variable expansions, which could
easily happen by forgetting to remove quotes when porting to the new
signature).
...and then of course cmake_parse_arguments can readily accept other
options to modify its behavior e.g. KEEP_EMPTY (and/or SKIP_EMPTY if
keeping becomes - or may be, depending on policy - the default).
--
Matthew
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 14:36, Alexander Neundorf wrote: I tried the following a few times in the past and noticed everytime that it does not work: $ cd src src/ $ mkdir build src/ $ cd build src/build/ $ cmake-gui -DSOME_VARIABLE=some_value .. I'd like that to work. Would it work with your proposal ? Yes. Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. True. (But what if that's what you want?) The biggest problem is, what if you run cmake-gui without specifying a build directory? In that case, whatever comes up initially is as likely as not *not* the directory you want to apply options to. What about having an option (e.g. a combo box) when to apply command line options? - At startup (only initial / specified on command line build directory) - New projects (when no CMakeCache.txt exists yet, but also at startup) - Unconfigured projects (per my original proposal) - Always (i.e. when selecting a different build directory) The default could be 'new projects' if no build directory is specified on the command line (probably you are giving common rather than project specific options in this case), otherwise 'at startup' (more chance options are project specific). -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 14:36, Alexander Neundorf wrote: On Tuesday 05 November 2013, Jean-Christophe Fillion-Robin wrote: Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both UI. It would accept the same set of options: [...] -G generator-name = Specify a makefile generator. -T toolset-name = Specify toolset name if supported by generator. Not sure about these two. I have to select them anyway when starting configure, I don't see much value in overriding this from the command line. Specifying them on the command line would allow you to skip the GUI dialog to select them. -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 15:14, physhh . wrote: On Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke wrote: On 2013-11-05 14:36, Alexander Neundorf wrote: Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. True. (But what if that's what you want?) Could you give me a use case where u actuall don't want this? As already stated are the command line parameters the default values. If I dont' want to remove an entry by default I won't pass that parameter. If I want to remove an entry (but not by default) I will do it with the gui itself - That's what the gui is for? The use case is invoking cmake-gui by hand from a command line for a specific project (i.e. specifying the build directory also on the command line). As I see it, folks that are used to cmake/ccmake tend to want cmake-gui to work more like that. Whereas folks that are used to doing everything from GUI's and hardly if ever touch a command line want it to work like we're suggesting. Both points of view are IMO valid (though I tend towards greater sympathy for the latter in this case). (Personally, I'd say I'm middle of the road; I use a CLI plenty¹ - and TBH, ccmake much more than cmake-gui - but I (try to) understand and respect the non-CLI use case.) (¹ ...though not nearly as much as some people I know. I do prefer kwin and kdevelop over ratpoison and vim/emacs, thank you ;-).) -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 09:25, David Cole wrote:
Matthew Woehlke wrote:
- What should happen with a -D option if there is not initially a
build directory selected?
It should add UI entries even though there is no build directory
selected, and set them according to the -D values. Then, the -D values
should be forgotten about and never applied again during that session,
regardless of future user actions.
Also, you could require that for -D args to work properly, the current
directory *is* the binary directory at startup time (just like cmake and
ccmake). If you're passing -D arguments to the gui program, then you
have control over its launching point, and can set the current directory
to be whatever you like.
If launched without a build directory, you could choose the last known
build directory (if there is one) just like cmake-gui does now.
If no build directory, no -D args.
[...]
I think you're vastly over complicating the solution to a very simple
problem.
If you read physsh's question that lead to this:
When should the new variable be added? On startup is not really
possible because it might be the case that your src/binary directory
is not set properly.
...it seems very explicit that your proposal is inadequate for his use case.
Besides, I don't think the parallel holds: cmake-gui != ccmake.
In ccmake, there is no concept of choosing / changing the build
directory - one *must* run it with $PWD == ${CMAKE_BINARY_DIR} - so it
makes sense to only apply -D/etc. to the initial build directory.
This is very much not the case with cmake-gui; it might be launched from
a desktop / launcher menu shortcut where all bets as to $PWD are off,
and anyway it may not even start with $PWD as the build directory.
The ability to change the build directory after launching, which is
unique to cmake-gui, is IMHO very much worth handling -D/etc. options
differently for that reason.
Again, looking at physsh's comments, I think we should be considering
the case of someone that wants to always pass the same -D/etc. arguments
'by default'. One might conceivably (expect to be able to) do this by
modifying the cmake-gui shortcut to include the desired options. For
that to work, cmake-gui would need to apply the options to any
newly-configured project, even if it wasn't the initially selected
project. (For that matter, one might conceivably want to configure
several projects, or at least several build directories, in one
'session', with the options applied to all of them.) I think this is a
very reasonable use case that should be supported, and I tried to
address that in my proposal.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 17:40, David Cole wrote: I would simply like to point out, with all due respect, that in the non-CLI use case, it is IMPOSSIBLE to pass command line parameters. 1. I can modify my shortcut / .desktop file (which I previously stated as a use case for the feature). 2. I can launch cmake-gui from the run / launcher dialog. In both cases, I'm not using a (full) CLI, but I can still pass command line arguments. (The latter is admittedly a little CLI-like, but its working directory is still poorly defined and probably you are not specifying a build directory in that case.) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-04 15:47, David Cole wrote: My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it on configure but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? On startup is the only time it does make sense. After that, the user should be in charge, and the command line settings should not be re-applied again after a user makes an edit. You don't need the src/binary directories set properly necessarily in order to add a cache entry to the UI. There are two mostly separate issues here. As far as the bug, the ccmake behavior is (IMO, but seems generally shared) is just wrong. physhh's questions (above) don't apply to this case because there is no concept of interactively selecting the build directory in ccmake. So fixing this is, if not easy, at least easy to understand how it should behave. As far as cmake-gui, there are no backward compatibility issues because right now it just doesn't support -D at all. It does however get more complicated... - What should happen with a -D option if there is not initially a build directory selected? - What should happen if the wrong build directory is initially selected and subsequently changed? It seems non-desirable here to forget -D (etc.) entirely at that point. ccmake and cmake-gui *should* behave (in *my* opinion) as follows: - on startup, load the CMakeCache.txt values (if there are any) from the previous run - then apply the -D arguments so that any -D arguments given on the command line overwrite previous cache entries (just like command line cmake does already) - then put the user in charge and wait for user input I suppose if I were writing the patch, I would have cmake-gui remember whatever -D/-U/etc. options are given and apply them to any build directory when it is selected, after loading the cache (if any). But *don't* pass them on the cmake (except inasmuch as the initial cache will contain them, modulo any changes the user made in the mean time). IOW, if I specify a -D to cmake-gui, change that value, then change to some other build directory, that -D would reset to the value from the command line. This is consistent with the current behavior that any other changes to the cache of the initial build directory are also lost. Hmm... a corner case comes to mind, however; if I configure build directory A after changing a -D value, then switch to build directory B, then back to A, I probably don't want to reapply the -D. So maybe cmake-gui would keep track of what build directories have been configured in that instance and not apply -D/etc. to them. (However, it's probably not very common for that to happen.) Make sense? -- Matthew -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-02 07:58, David Cole wrote: physhh wrote: The question is: What is the expected behavior? ccmake and cmake-gui are interactive programs meant to prompt the user to fill in the cache values properly before typing 'c' or clicking 'Configure'. -D is a convenient way to give cache values an initial value that is different from their natural 'default' values. Using -D with ccmake and cmake-gui makes total sense, but it should only be used by the program to set the initial value that users see in the UI. After that point, the user should be in charge, and if he sets something different in the UI, the user value should win. I think Matthew's bug report is correct: the UI value should be used and then stored in the cache for subsequent runs. The -D values to ccmake and cmake-gui should only be used for initializing UI entries. Therefore, they should *NOT* be passed to the internal CMake instance used for configuring. My thoughts exactly. Thanks, David. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Proper way to export a library
On 2013-11-02 13:38, Cyrille Faucheux wrote:
[...] from what I understood from Matthew first answer (implicit compile
flags [...] for imported tagets), I was under the impression that I could
get MYPROJECT_STATIC automatically defined when linking another program
against a static version of my library (through its imported target).
Yes and no. *You* have to set the flag as part of your library's
interface compile definitions. But once you do that, cmake should export
that, and anyone linking to your library (via imported target) should
automatically pick up the flag.
I've looked the documentation of target_compile_definitions, but it seems
to be about compiling the library, not linking against its imported target.
Am I right?
No; at least not entirely in the case of 't_c_d({PUBLIC|INTERFACE})'. A
PUBLIC definition is used both to compile your library and by anyone
linking to it. An INTERFACE definition is used *only* by other targets
linking to it.
See also the INTERFACE_COMPILE_DEFINITIONS property and note in the
t_c_d documentation how t_c_d affects that property.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-01 10:47, physhh . wrote: What I'm looking for: If cmake is used directly from the command line, it's possible to pass a bunch of options. This is nice because with this it's possible to use default settings - even if the cache get deleted. ccmake accepts e.g. -D options to set CMake cache variables. It... does appear that cmake-gui does not. That seems like a bug (or at least a missing feature that one would naturally expect to exist). I would like to see a feature which makes it possible to pass command line options to cmake-gui which get forwarded to cmake when it gets called. To make this work the cmake-gui could look for parameters which look like forward-* (where the * is a cmake option name) and pass it to cmake. I'm not sure a forward option makes sense... what would it mean to forward e.g. -P or -E? Rather, I think cmake-gui should just accept directly those options that make sense, e.g. -D, -U, -C, -G, -T and probably -W[no-]dev, the same way that ccmake does. (Besides, these should affect cmake-gui even before cmake is invoked, so merely forwarding them is actually insufficient.) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-01 11:39, physhh . wrote: that's interesting. I'm currently at a windows only machine so i can't check out ccmake but can only lookup the source. It appears that ALL parameters get forwarded to cmake - at least that's what cmCursesMainForm.cxx:52 this-CMakeInstance-SetArgs(this-Args); looks to me. Why do you think that a simple forward is not enough? ccmake seems to do it exactly that way? I don't know enough of the guts to know how values initially specified in ccmake / cmake-gui get passed to CMake. Where you could get into trouble is, say, you pass -DBOOST_ROOT=/some/ptah, realize you've made a mistake (e.g. 'ptah' - 'path') and fix it in the gui before running cmake. Now does cmake see the original value or the corrected value? That's where it *might* go sideways. But it might also be perfectly safe to just pass them through, e.g. if the corrected value is passed also as a -D argument later in the list. However, what I was mainly getting at is that cmake-gui should also process the -D, etc., as I am pretty sure ccmake does, so that it can display those values and/or make appropriate use of the arguments. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-01 17:35, physhh . wrote: I've tried to implement it in the same way as CCMake seem to do it. Because I can't compare it = Could somone with access to ccmake test this: - Start CCMake with -D foo=123 - Configure - Question: Is foo displayed in the variable list? Yes. - Add/Edit foo to some other value - Configure - Question: Was foo overwritten with 123? Yes. Repeatedly (i.e. if I configure, then change it, it still gets overwritten). And I'm going to have to call that a bug; it's hard to imagine how it is desired behavior. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
