Re: [cmake-developers] Future of ccmake and cmake-gui and internationalization

On Thu, Aug 17, 2017 at 2:27 AM, Eric Wing wrote: >> Hi Eric: >> >> My opinion is your point about size is weak because IUP normally depends on >> a big suite of graphical libraries in the GTK+ case or a big set of >> system libraries such as GDI/GDI+/Uniscribe or

Re: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test?

On Mon, Oct 3, 2016 at 2:25 PM, Brad King <brad.k...@kitware.com> wrote: > On 10/03/2016 12:14 PM, Clifford Yapp wrote: >> so what we need is not actually the test names themselves, >> but a list of the executables used to run tests that are also defined >> as build ta

Re: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test?

On Mon, Oct 3, 2016 at 11:21 AM, Brad King <brad.k...@kitware.com> wrote: > On 10/03/2016 11:17 AM, Clifford Yapp wrote: >> One of the functions we are wrapping in our build with CMake's "_" >> prefix debugging mechanism is add_test. Looking at why we do that, it

[cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test?

One of the functions we are wrapping in our build with CMake's "_" prefix debugging mechanism is add_test. Looking at why we do that, it should be possible to avoid wrapping if we can get access in CMake to the list of all test build targets defined with add_test. Essentially, we need to add them

Re: [cmake-developers] Listing all targets

On Mon, Sep 14, 2015 at 1:47 PM, Stephen Kelly wrote: > Brad King wrote: > >> On 09/14/2015 11:46 AM, David Cole wrote: >>> (1) I see how I can easily move "COMPONENTS" from >>> cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty >>> because I can access the

Re: [cmake-developers] Listing source-tree files encountered

On Mon, Jul 20, 2015 at 4:42 PM, Ben Boeckel ben.boec...@kitware.com wrote: For testing these properties, what would you suggest? They're intended to report local configure-time absolute paths, which can't be hard coded... is it enough to check them to make sure they're not empty or is there

Re: [cmake-developers] Capturing messages to log files

On Mon, Jul 20, 2015 at 9:36 AM, Brad King brad.k...@kitware.com wrote: On 07/18/2015 03:45 PM, Clifford Yapp wrote: Am I correct that cmSystemTools::Message is the gateway through which all of the console output from CMake exits? If so, perhaps the simplest thing to do is simply allow

Re: [cmake-developers] Listing source-tree files encountered

On Mon, Jul 20, 2015 at 9:33 AM, Brad King brad.k...@kitware.com wrote: That looks good to me. Please extend the patch to also do BINARY_DIR for completeness and also to update the documentation to cover the new properties. The Tests/RunCMake/get_property test should be updated to cover

Re: [cmake-developers] Listing source-tree files encountered

With David's patch and the above SOURCE_DIR property, it looks like the necessary pieces are now present for target + source processing. A quick test: get_cmake_property(target_list TARGETS) list(SORT target_list) foreach(targ ${target_list}) get_target_property(ttype ${targ} TYPE) if (NOT

Re: [cmake-developers] Listing source-tree files encountered

On Sat, Jul 18, 2015 at 5:30 AM, Florent Castelli florent.caste...@gmail.com wrote: I've used that once and you end up with the relative path to the sources from the CMakeLists.txt. If you're in another CMakeLists.txt, then you can't use the paths directly. I tried a few properties but I

Re: [cmake-developers] Capturing messages to log files (was: Wrapping functions in CMake)

On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote: On 07/09/2015 01:53 PM, Clifford Yapp wrote: Actually, thinking about that, what's really needed is not an in-memory log but a way to specify log files, since an unexpected crash or exit is not a situation under which

Re: [cmake-developers] Listing source-tree files encountered

On Sat, Jul 18, 2015 at 1:49 PM, Clifford Yapp cliffy...@gmail.com wrote: On Sat, Jul 18, 2015 at 5:30 AM, Florent Castelli florent.caste...@gmail.com wrote: I've used that once and you end up with the relative path to the sources from the CMakeLists.txt. If you're in another CMakeLists.txt

Re: [cmake-developers] Listing all targets (was: Wrapping functions in CMake)

On Fri, Jul 17, 2015 at 6:05 PM, David Cole dlrd...@aol.com wrote: Attached is a patch file of my first attempt. I can iterate some more on this (better testing, add docs, clarify existing docs, address anybody's comments, submit to stage) next week. Attached now in case anybody wants to try

Re: [cmake-developers] Listing source-tree files encountered

On Fri, Jul 17, 2015 at 11:50 AM, Brad King brad.k...@kitware.com wrote: On 07/15/2015 10:38 PM, Clifford Yapp wrote: Lists that contains a verbatim collection of all path specifiers, regardless of form, that are passed to the various add_* targets would be enough, I think - it'd then be up

Re: [cmake-developers] Listing all targets (was: Wrapping functions in CMake)

On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote: On 07/10/2015 03:42 PM, Clifford Yapp wrote: On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp cliffy...@gmail.com wrote: 2. Provide similar lists of all defined targets for the various types (e.g. CMAKE_EXECUTABLE_TARGETS

Re: [cmake-developers] Capturing messages to log files (was: Wrapping functions in CMake)

On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote: On 07/09/2015 01:53 PM, Clifford Yapp wrote: Actually, thinking about that, what's really needed is not an in-memory log but a way to specify log files, since an unexpected crash or exit is not a situation under which

Re: [cmake-developers] Listing source-tree files encountered (was: Wrapping functions in CMake)

On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote: On 07/09/2015 01:35 PM, Clifford Yapp wrote: 1. First, we need to maintain a list of all files in the source repository that are known to the build system. To do this we maintain a global list of files, define a custom

Re: [cmake-developers] [CMake] Problem with CMake 3.3.0-rc3

On Sat, Jul 11, 2015 at 5:07 AM, Stephen Kelly steve...@gmail.com wrote: Brad King wrote: Steve, please take a look. It looks like the cmState methods RemoveUserDefinedCommands and RenameCommand need to work better together. This needs to be fixed for 3.3. Fixed with

Re: [cmake-developers] Wrapping functions in CMake

On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp cliffy...@gmail.com wrote: 2. Provide similar lists of all defined targets for the various types (e.g. CMAKE_EXECUTABLE_TARGETS, CMAKE_LIBRARY_TARGETS, CMAKE_CUSTOM_TARGETS). Looking into the CMake sources, it seems like this information

Re: [cmake-developers] Wrapping functions in CMake

On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp cliffy...@gmail.com wrote: 3. Have one or a number of variables that will hold in memory all the text written out by message (CMAKE_MESSAGES, CMAKE_STATUS_MESSAGES, CMAKE_ERROR_MESSAGES, etc.) so the CMakeLists.txt file can create log files

[cmake-developers] Wrapping functions in CMake

A problem has arisen with CMake and BRL-CAD in 3.3, and it looks like it may relate to some command overriding BRL-CAD does in order to support some of our more advanced build features. The feature we are using to do this is an unsupported debug feature, and Brad King suggested moving over to