Re: [cmake-developers] productbuild: Installing to absolute system path or to user home path

According to the docs, the INSTALL command uses the absolute path if it is given as the DESTINATION, so it should work. https://cmake.org/cmake/help/latest/command/install.html Did you try using a double quoted string, instead of escaping the space with a backslash? I think this should work

Re: [cmake-developers] cmake-file-api and CTest

The return code indicates a stack overflow. Let's hope it is not intended. https://stackoverflow.com/questions/50562192/process-finished-with-exit-code-1073740791-0xc409-pycharm-error On Thu, Aug 22, 2019 at 7:16 AM Nagy-Egri Máté Ferenc via cmake-developers wrote: > > Hi! > > > > Someone

Re: [cmake-developers] Is email notification of a failed CMake dashboard possible?

Before you login, it's just a "login" link. Once you've logged in, it becomes a "My CDash" link. On Sun, May 26, 2019 at 2:34 PM Alan W. Irwin wrote: > > On 2019-05-26 11:07+1000 Craig Scott wrote: > > > Notifications for builds are controlled through CDash. You can adjust your > > CDash

Re: [cmake-developers] Preferred case for macro names?

I would just like to point out that some modules (ExternalData, ExternalProject, to name two specific examples) adopted the convention to prefix all their provided function names with the module name and an underscore: for example, ExternalProject_Add and ExternalData_Expand_Arguments. These

Re: [cmake-developers] Link element in C# project causing issues with binary dir

The code looks wrong like this, too: You shouldn't strip the source directory from the path of the file name unless the character after the source directory is "/" or "\\", should you? If the thing you're trying to end up with is a path name to the file under the source directory, then this is

Re: [cmake-developers] CMake build with static crt and static QtDialog not linking

I had a project where I had to do this in the main.cpp file to get it to link with static Qt on Windows: #ifdef _WIN32 #ifdef QT_STATIC Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin) #endif #endif Those unresolved externals you posted look familiar... Does this fix it? HTH,

Re: [cmake-developers] CTest script and many subprojects

I think your analysis is correct. You could try doing a ctest_submit after each ctest_test call. Not sure if you could get "correct" results with that technique. I run some scripts that do something similar without subproject involved, and it mostly works, but messes up the +/- tests passed and

Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

to find the exact one you already know you have... On Tue, Aug 29, 2017 at 11:49 AM, Brad King <brad.k...@kitware.com> wrote: > On 08/29/2017 11:33 AM, David Cole wrote: >> That's correct: >> >> find modules do what they want, and most do not pay attent

Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

ctory >> ("installed") because I have other libraries that get installed in >> that directory, each with their own directory to contain their >> installation files. If find_package() is appending to >> like it says it should, it should find each one of them witho

Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

t get installed in > that directory, each with their own directory to contain their > installation files. If find_package() is appending to > like it says it should, it should find each one of them without > switching the value of CMAKE_PREFIX_PATH. > > Am I misunderstanding som

Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey wrote: > On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >> On 08/29/2017 10:55 AM, Brad King wrote: >>> On 08/29/2017 10:48

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

This is great to see CMake continuing to evolve like this! What's next, a web page CMake UI connected to cmake server instances on multiple platforms? ;-) On Wed, Aug 16, 2017 at 6:05 PM, Daniel Pfeifer wrote: > On Wed, Aug 16, 2017 at 6:16 PM, Eric Wing

Re: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0

Alan, you had said in your original post: "Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0 source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it just does not exist." Try searching for "_CREATE_SHARED_MODULE" instead... it's combined in code with the name of

Re: [cmake-developers] [CMake] CPack install 3rd party shared libraries

Very nice example. Does CMake have a place to put examples like VTK does...? If so, where is it? And if not, it would be super useful to start one somewhere "official." However, one word of caution on the example. I know it was targeted at Linux, and perhaps for a very simple case it's proper,

[cmake-developers] Question about ALIAS targets

Is there a good reason why this error must be an error? CMake Error at CMakeLists.txt:23 (add_library): add_library cannot create ALIAS target "MyProj::gtest" because target "OtherProj::googletest" is IMPORTED. The line of code is: add_library(MyProj::gtest ALIAS

Re: [cmake-developers] Debugging issues with enable_language(CSHARP)

Have you looked into https://github.com/Kitware/CMake/blob/master/Modules/CMakeDetermineCSharpCompiler.cmake ? Send steps to reproduce the problem you're seeing... Maybe somebody else here has encountered the same thing and worked through it already. HTH, David C. On Wed, Mar 22, 2017 at

Re: [cmake-developers] [CMake 0015749]: Make the URL option of ExternalProject_Add to accept lists

Looks like you could also use a list of paths if you express them in "file://..." form. Local files can also be expressed as URLs. David C. On Wed, Jul 13, 2016 at 4:18 AM, Schmertmann, Lars wrote: > Hello there, > > I try to continue the work from André. >

Re: [cmake-developers] Patch to only consider build dependencies between files in the source directory

Brad's point with "/" or null terminator was that the directory name **must** be the directory itself, or a sub-directory of the one in question. i.e. if it's "my/src" then it should either be exactly "my/src" or "my/src/someSubDir" , not "my/srcSiblingDir" On Fri, Mar 18, 2016 at 11:52 AM,

Re: [cmake-developers] C# support ready for review

Seems to me like C# support should work just fine with other generators: ninja, nmake, and UNIX Makefiles included. Especially with mono on Linux/Mac. David > On Mar 7, 2016, at 2:12 PM, Brad King wrote: > >> On 02/25/2016 05:51 AM, Stuermer, Michael SP/HZA-ZSEP

Re: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd)

I agree with Brad, the --timeout command line parameter should only set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test TIMEOUT properties should be left as is for this change. A **new** --timeout-scale with well defined / documented interactions with the global variable and

Re: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd)

e with good projects. David > On Dec 17, 2015, at 2:42 PM, Ben Boeckel <ben.boec...@kitware.com> wrote: > >> On Thu, Dec 17, 2015 at 13:54:08 -0500, David Cole wrote: >> I agree with Brad, the --timeout command line parameter should only >> set/override the variable CTEST

Re: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd)

d -D cmd line params since 3.0 or so. David > On Dec 17, 2015, at 6:38 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > >> On 2015-12-17 13:54-0500 David Cole wrote: >> >> I agree with Brad, the --timeout command line parameter should only >> set/over

Re: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd)

Thanks, Ben. That was gonna be my 2 cents, too: If I set a test property to have a 1, 5 or 10 second timeout, then I want the test to timeout if it takes any longer than that. I do this on tests which must execute quickly even in a loaded CPU scenario. I would not want the global timeout to take

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

Yes, that looks like it should work. I'll pull your branch and give it a try sometime in the coming week. Thanks, David On Friday, December 4, 2015, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote: > On Fri, Dec 4, 2015 at 11:32 PM, David Cole <dlrd...@aol.com > <javascript:;&

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

With Visual Studio, you definitely **need** separate pch for each CONFIG. Every pch is going to include headers which have Debug/Release differences in them, and it is not safe to mix and match compiler output from separate configs together. D On Friday, December 4, 2015, Daniel Pfeifer

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

egarding these two questions: >>> - Do we want to support different pch per CONFIG? I think no, but I >>> might be wrong. >>> - Do we want to support different pch per LANGUAGE? I first thought >>> yes, but I am no longer certain about that. > > On Fri, De

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

dio tester for you. D On Fri, Dec 4, 2015 at 5:28 PM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote: > On Fri, Dec 4, 2015 at 9:19 PM, David Cole <dlrd...@aol.com> wrote: >> Right, I was talking about the pch-binary. >> >> Why would CMake even need to generate a h

Re: [cmake-developers] Fwd: Cmake stucks

What OS? What version of CMake? What version of VTK? Did you download CMake, and if so, from where? Or did you build CMake yourself? On Tue, Nov 24, 2015 at 7:27 AM, Constantinus Spanakis wrote: > Hello, i tried to configure VTK using Cmake, but every time it stucks >

Re: [cmake-developers] Specifying a VS installation path explicitly

A simple source tree grep for "HKEY" (or even just "HK") will point you to all the places CMake has registry key references in its source code... On Tue, Oct 27, 2015 at 10:38 AM, Johannes Asal wrote: > If it was actually using registry entries only for locating the VS

Re: [cmake-developers] generator expression for path slash conversion

Unfortunately, "pushd" is an inappropriate command to use when the argument is quoted. It works just fine with "/" characters if the argument is quoted... For example: C:\Users\davidcole>pushd C:\Windows\System32 C:\Windows\System32>pushd C:/dev The syntax of the command is

Re: [cmake-developers] Listing all targets

the list of all available CMake targets, which may be different than what the project had set into the property. Thanks for any feedback, David C. On Mon, Jul 20, 2015 at 9:30 AM, Brad King <brad.k...@kitware.com> wrote: > On 07/17/2015 06:05 PM, David Cole via cmake-developers wrote: >

Re: [cmake-developers] Making kwsys a proper library

Honestly, KWSys has always seemed like a boost-avoidance mechanism from an outsider's perspective. Perhaps it should be replaced with boost equivalents in projects that need to be packaged for Fedora. I assume all the boost libraries are already packaged/available. Fuel for the fire, ;-) D

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

with globally making this change to the existing tokens is that there could be some external tool/program that is EXPECTING to get CMake paths, not native paths. Who knows? I am guessing that is what David Cole was concerned about. Maybe the right answer is to introduce some NEW tokens while leaving

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

But some existing replacements require forward slashes, we can't just to native path everything blindly. I think you will have to special case the bits which do need native paths. On Wednesday, August 19, 2015, Kislinskiy, Stefan s.kislins...@dkfz-heidelberg.de wrote: Hi, I would like to

Re: [cmake-developers] Listing all targets

Thanks for the comments. I'll incorporate these into my next iteration... On Mon, Jul 20, 2015 at 9:30 AM, Brad King brad.k...@kitware.com wrote: On 07/17/2015 06:05 PM, David Cole via cmake-developers wrote: Attached is a patch file of my first attempt. I can iterate some more on this (better

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

On Saturday, July 18, 2015, Clifford Yapp cliffy...@gmail.com wrote: On Fri, Jul 17, 2015 at 6:05 PM, David Cole dlrd...@aol.com javascript:; 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

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

Are you saying there should be a named GLOBAL property with this information in it...? It seems like more of a fit to get_cmake_property. On Fri, Jul 17, 2015 at 10:14 AM, Ben Boeckel ben.boec...@kitware.com wrote: On Thu, Jul 16, 2015 at 13:27:12 -0400, David Cole via cmake-developers wrote

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

, Jul 17, 2015 at 14:16:34 -0400, David Cole wrote: get_cmake_property is more like strictly well-pre-defined, read only (ish), built-into CMake properties. Note there is no set_cmake_property... What docs are you looking at that you think have a bug...? Help/command/get_cmake_property

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

by if(TARGET and use the same list it uses as the value returned here. Should I work on a patch/branch, or is somebody here already working on it? D On Fri, Jul 17, 2015 at 1:54 PM, Ben Boeckel ben.boec...@kitware.com wrote: On Fri, Jul 17, 2015 at 12:18:18 -0400, David Cole wrote: Are you saying

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

:03 PM, David Cole dlrd...@aol.com wrote: I think the see also is relevant because it points to another way to get to a whole different set of properties. Perhaps what they're looking for when they stumble upon get_cmake_property is actually target properties, which are only accessible via

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

This would best be added as a TARGETS variant of the existing http://www.cmake.org/cmake/help/v3.3/command/get_cmake_property.html command. (In my opinion...) David C. On Thu, Jul 16, 2015 at 11:42 AM, Clifford Yapp cliffy...@gmail.com wrote: On Wed, Jul 15, 2015 at 9:10 AM, Brad King

Re: [cmake-developers] cmake.exe parameters and system command line length limit

. I'd have to do some code analysis or experimentation to figure it out. D On Tue, Jul 14, 2015 at 9:34 AM, Robert Goulet robert.gou...@autodesk.com wrote: Ah ok this means the -C option is in addition to the cmake cache, and not replace it? -Original Message- From: David Cole

Re: [cmake-developers] cmake.exe parameters and system command line length limit

...@autodesk.com wrote: Hi David, That option looks interesting. How do we populate it with the other CMake cache values that are originally set by CMake and not by our command line options? Thanks. -Original Message- From: David Cole [mailto:dlrd...@aol.com] Sent: Monday, July 13

Re: [cmake-developers] cmake.exe parameters and system command line length limit

You could use the -C command line option to pass in the name of a file containing initial cache values. See the -C initial-cache section at the top of this documentation section: http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#options The format of the file is just a bunch of

Re: [cmake-developers] A policy for Policies

wrote: On Tue, Jun 09, 2015 at 11:24:03 -0400, David Cole via cmake-developers wrote: Is there a single example of a policy wherein the OLD behavior has actually been removed? Technically, yes. CMP0053 as NEW ignores CMP0010's setting and treats it as NEW (because the new parser doesn't

Re: [cmake-developers] C# support?

Yes, please do spell it out as CSharp. CS could mean about a billion things... On Tue, Jun 30, 2015 at 5:19 AM, Stuermer, Michael SP/HZA-ZSEP michael.stuer...@schaeffler.com wrote: Sounds reasonable, my choice was motivated by the file extension of the C# source files (.cs) and that it is

Re: [cmake-developers] C# support?

The C# compiler, csc.exe, takes all its arguments at once in one call to build a library or executable. Listing all the sources, and its references (other libraries it depends on) all at once. You can do it as command line arguments, or as contents of a response file, or a combination or arguments

Re: [cmake-developers] [CMake] Virtual folders in Visual studio get expanded on reload

I think I have seen this behavior in pure (non-CMake-generated) VS projects... Perhaps it's simply a Visual Studio issue, and has nothing to do with CMake. D On Fri, Jun 12, 2015 at 7:55 AM, Roman Wüger roman.wue...@gmx.at wrote: @kgt: Thank you for this great hint. :-) I had overlooked this

Re: [cmake-developers] File Building issue

Can you change your CMake minimum required version to 3.3? On Wed, Jun 10, 2015 at 10:11 AM, Arunava Nag arunavos...@gmail.com wrote: Hello, Facing an issue while building in cmake 3.3.0. Need some help. cmakelist file code extract cmake_minimum_required(VERSION 2.8) project(AMFIO) #Flags

Re: [cmake-developers] A policy for Policies

So, when you're saying: ...but still supporting the OLD stuff with a warning if no one tried explicitly to set things to use OLD, they just had a working build system. You're effectively saying we will never remove the OLD behavior for any policies, ever? If that's the case, then why bother

Re: [cmake-developers] A policy for Policies

Is there a single example of a policy wherein the OLD behavior has actually been removed? Contributing to the problem is this: despite the policy mechanism, OLD behavior is never actually removed. Therefore, people know they can just set OLD and move on. The first policy was introduced in CMake

Re: [cmake-developers] NMake Batch-Mode Rules (was: Inquiry on contribution to NMake generator)

CMake + Ninja is definitely the best move you can make for giving your developers the minimum possible build time on Windows. NMake is basically useless, its underlying code hasn't been updated in years, and it does absolutely nothing to try to take advantage of multiple cores. Fastest Windows

Re: [cmake-developers] Unittests with reconfiguration

This one: https://github.com/Kitware/CMake/blob/master/Tests/CMakeTestMultipleConfigures/RunCMake.cmake It doesn't change anything in between CMake configures, but it does 7 altogether, with the expectation that the output will not change beyond the 1st / 2nd configures. Sample output here:

Re: [cmake-developers] Unittests with reconfiguration

This chunk in the CMakeLists file is what sets up the arguments for that test script: https://github.com/Kitware/CMake/blob/master/Tests/CMakeLists.txt#L1132 D On Mon, Apr 27, 2015 at 7:16 AM, David Cole dlrd...@aol.com wrote: This one: https://github.com/Kitware/CMake/blob/master/Tests

Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add

. I'm saying that right now CMake is not very convenient for projects with a lot of external dependencies. And specifying toolchain and it's options is a one aspect of it (not the most important, though). On Sun, Apr 26, 2015 at 5:36 PM, David Cole dlrd...@aol.com wrote: Why wouldn't you just

Re: [cmake-developers] [CMake] cmake 3.1.1 does not generate x64 profile for visual studio

We really shouldn't have removed the explicit mention of the Win64 suffixed generator names in the list of generators in --help ouput... That was a mistake. We should put it back. On Fri, Apr 24, 2015 at 5:29 AM, Xi Shen davidshe...@gmail.com wrote: Ah~, so it's a hidden feature? OK, I will

Re: [cmake-developers] [CMake] cmake 3.1.1 does not generate x64 profile for visual studio

Excellent. Thanks for the pointer... I had not seen that recent commit. Seems we had a shared this should be explained better so we don't get so much email about it brain wave pattern. Happy Friday, D On Fri, Apr 24, 2015 at 9:04 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 04/24/2015

Re: [cmake-developers] ExternalProject can't have interface library as a dependency

To avoid this entirely, you can just use add_dependencies ( http://www.cmake.org/cmake/help/v3.2/command/add_dependencies.html ) instead of adding it as a DEPENDS to your ExternalProject_Add call. The reason ExternalProject_Add queries to see if the other thing is an ExternalProject or not is to

Re: [cmake-developers] [PATCH] ExternalProject_Add: Allow generator expressions in CMAKE_CACHE_ARGS

With this change, does the external project's configure step re-run when you edit only the CMAKE_CACHE_ARGS for it? (It did with the *.in / configure_file approach...) On Fri, Apr 17, 2015 at 12:55 AM, Andrey Pokrovskiy wonder.m...@gmail.com wrote: In current implementation of

Re: [cmake-developers] [PATCH 0/9] Xcode: Generate stable project files

Nice!! I agree with Eike: perhaps you could start the patch series by putting the verbose explanation in the text of the first commit, and explain the following 8... commits all help to minimize the diffs between CMake generated project files and Xcode native project files. I love it when people

Re: [cmake-developers] Generating buildsystem metadata from CMake

I favor documenting the existing format, too. Note added to issue with my vote. D On Wed, Apr 1, 2015 at 4:26 PM, Stephen Kelly steve...@gmail.com wrote: Anton Makeev wrote: Not only do we reed it, we also have the UI that allows user to interact and the cached values. That means we’ll

Re: [cmake-developers] A CMAKE_EMULATOR variable

What does CMAKE_EMULATOR emulate? From its name, it sounds like it emulates CMake. But from your description, I'm thinking that doesn't make sense... Because you actually run CMake and pass it CMAKE_EMULATOR. So it must be emulating something else while running CMake? I'm guessing it emulates

Re: [cmake-developers] Feature request in CMake-gui: Open project file button

There is a similar (old) feature request in the bug tracker for a build button: http://public.kitware.com/Bug/view.php?id=8260 See the commentary there when considering adding a button to cmake-gui... D On Thu, Feb 5, 2015 at 4:54 AM, Paul Anton Letnes p...@letnes.com wrote: Hi! I

Re: [cmake-developers] Cmake 2.8.8 -- can't find curses.h

This is a pre-built Linux binary that should work on that system, and should include ccmake: http://www.cmake.org/files/v2.8/cmake-2.8.8-Linux-i386.tar.gz If you can't run it, it's probably because you're on an x64 box, and you need the run the 32-bit exes and libs library -- hopefully

Re: [cmake-developers] DragNDrop: Easier custom dmg layouts

This looks pretty reasonable to me. From Rob's initial email, I thought it sounded like there was some sort of backward compatibility problem, but looking through the code, it seems like everything should all work the same for projects that aren't changing. Was I misunderstanding about

Re: [cmake-developers] OpenBSD and srand()/rand() changes

Looking at our own internal test suite usage of RANDOM_SEED leads to the conclusion that we do not verify the sequences produced when actually using RANDOM_SEED.. So, from our point of view, we don't really care about what effect RANDOM_SEED has for our test suite. But I think we do still

Re: [cmake-developers] OpenBSD and srand()/rand() changes

Sie: On Thu, Dec 11, 2014 at 14:41:36 -0500, David Cole via cmake-developers wrote: Yes, setting an explicit seed should make subsequent calls to random be deterministic... Well, *we* want that, but I don't think that OpenBSD is making an *awful* decision here. Even if you want

Re: [cmake-developers] OpenBSD and srand()/rand() changes

as the expected test results account for any differences that do exist, the goal can still be satisfied: predictable results. thx, D On Sat, Dec 13, 2014 at 1:05 PM, Ben Boeckel ben.boec...@kitware.com wrote: On Thu, Dec 11, 2014 at 14:41:36 -0500, David Cole via cmake-developers wrote: Yes

Re: [cmake-developers] OpenBSD and srand()/rand() changes

Yes, setting an explicit seed should make subsequent calls to random be deterministic... On Wed, Dec 10, 2014 at 9:50 AM, Rolf Eike Beer e...@sf-mail.de wrote: Am 10.12.2014 15:38, schrieb Ben Boeckel: Hi, It appears[1] as though OpenBSD has changed srand and rand which we use in CMake for

Re: [cmake-developers] Failing CMake WinStorePhone tests

gotta have the latest update of VS for the WinStorePhone tests to work. Does that match your expectations? Thanks, and sorry for the temporary noise David C. On Tue, Nov 18, 2014 at 4:20 PM, David Cole dlrd...@aol.com wrote: I just put VS 2013 Professional on it within the last two weeks

Re: [cmake-developers] [PATCH v5 0/4] Add continue keyword

Putting continue, break or return inside of a macro definition is a practice that should itself be discouraged... (I know, people will probably still have cases of it, but it doesn't seem like that's what any sane person would label a good practice, let alone a best practice...) On Tue, Nov 18,

Re: [cmake-developers] Failing CMake WinStorePhone tests

over to the test script. -Original Message- From: David Cole [mailto:dlrd...@aol.com] Sent: Friday, November 14, 2014 10:42 To: Gilles Khouzam Cc: Brad King; cmake-developers@cmake.org Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests I was hoping you'd say

[cmake-developers] Failing CMake WinStorePhone tests

Hi, The VSWinStorePhone tests are failing on my dashboard submissions: http://open.cdash.org/viewTest.php?onlyfailedbuildid=3570369 http://open.cdash.org/viewTest.php?onlyfailedbuildid=3570163 I just upgraded that machine to Windows 8.1 and Visual Studio 2013, and these dashboards run in a VS

Re: [cmake-developers] Failing CMake WinStorePhone tests

Cole Cc: cmake-developers@cmake.org; Gilles Khouzam Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests On 11/14/2014 11:27 AM, David Cole via cmake-developers wrote: Should I expect these tests to pass using Ninja, or is that beyond the scope of the WinStorePhone support

Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

I just looked at the diff, not the surrounding code, so forgive the question if it's obvious when inspecting the code.. but here's a question about your change before we push it into RC 2: Is objectSources guaranteed to contain the same set of objects as mapping? If so, I wonder why the code

Re: [cmake-developers] GCC HPPA linker errors

These are the earliest CDash results available for CMake: http://open.cdash.org/index.php?project=CMakedate=2014-07-09 (they're discarded after 120 days...) On Thu, Nov 6, 2014 at 5:27 PM, Rolf Eike Beer e...@sf-mail.de wrote: Am Donnerstag, 6. November 2014, 12:44:12 schrieb Brad King: On

Re: [cmake-developers] cmake-gui icons

I would say yes, too. On Tue, Oct 28, 2014 at 3:27 AM, Daniel Pfeifer dan...@pfeifer-mail.de wrote: 2014-10-27 21:33 GMT+01:00 Ben Boeckel ben.boec...@kitware.com: On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote: Trying to bring a bit more attention to this: Fedora is

Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

What is the main use case for locking files and directories from the CMake language? I feel slightly uncomfortable, without being able to put my finger on exactly why, with the prospect of adding this to CMake... Behavior when there's a lock that still exists (by bug/mistake) after CMake is done

Re: [cmake-developers] Any ideas for accessing the Dart source code?

Consider using CDash instead. It was Dart's drop-in replacement... and is actively maintained today. www.cdash.org On Tue, Oct 7, 2014 at 6:46 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: I thought it would be interesting to install my own local dart server to learn how to use CTest as

Re: [cmake-developers] Improving the version selection behavior of EXACT

How about IN_RANGE and/or IN_SET options? Where IN_RANGE takes two version numbers (low and high) and does the equivalent of: if ( (NOT ver VERSION_LESS low) AND (ver VERSION_LESS high) ) Or possibly even IN_RANGES with multiple ranges... And IN_SET takes a list of explicit version numbers

Re: [cmake-developers] kwsys SystemTools::RelativePath()

Is the result of RelativePath guaranteed to be a directory name, or is it possibly a file name? If a directory, then perhaps . makes sense and wouldn't negatively impact anything (other than cosmetically) if changed. But if a file, then . doesn't make as much sense. . to me implies it is the

Re: [cmake-developers] Support of codesign

Maybe it shouldn't even be a CPack thing. Maybe it should be an install time step so that all CPack generators will contains signed binaries if codesign is used... D On Mon, Sep 29, 2014 at 9:55 AM, clin...@elemtech.com wrote: It should not be an error

Re: [cmake-developers] [CMake] Windows rpath emulation

What is the problem that this feature is trying to solve? It seems unnecessary to me as a first-class feature of CMake. I must be missing something... But if you do pursue something like this, it seems to me that install(TARGETS ...) should install all files including the wrapper. Is this only

Re: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison

I like the cmake_policy(SET CMP0053 NEW) solution, too. We should make a concerted effort to encourage module maintainers to do this before the 3.1 release for as many modules as possible. D -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

The rule is (roughly): after the first release candidate for a given release, no more new features for that particular release. Only continuing work to complete new features in rc1 and fixing regressions reported from previous versions should go in subsequent release candidates. Possible

Re: [cmake-developers] Gold standard find module?

I would say there are no gold standard find modules. The gold standard is a project config file, like Qt5 has. From http://www.cmake.org/cmake/help/v3.0/manual/cmake-qt.7.html : the Qt 5 libraries are found using Config-file Packages shipped with Qt 5 Also, search this page for Config

Re: [cmake-developers] Gold standard find module?

In this case just the one. I'm not that ambitious as I'm just volunteering my time to various FOSS projects and still have to maintain a day job to pay the bills! :-) In that case, I would recommend just getting it into shape so that it works best for you. (But then, that's the way we've

Re: [cmake-developers] Alternate if() without implicit variable expansion

I was also thinking about setting up an alternative testing infrastructure parallel to RunCMake which runs cmake in script mode rather than performing configuration/generation. This already exists in a form in the Tests/CMakeTests/*TestScript* tests. An example:

Re: [cmake-developers] Alternate if() without implicit variable expansion

...I would prefer to combine into something more compact.The other infrastructure I don't think I have touched but optically it looks very noisy.Having something that takes away repetitive tasks, more compact and easier on the eye would be nice. I agree. That would be nice. Feel free to

Re: [cmake-developers] Alternate if() without implicit variable expansion

Another approach might be to add STRING_EQUAL and STRING_MATCHES (or similarly unambiguous names) operators that do not do the variable lookup. The documentation would start with: if(string STRING_EQUAL string) if(string STRING_MATCHES regex) ...i.e., not mentioning variable anywhere for these

Re: [cmake-developers] Changing the regex used for INFO strings

Looks good to me. Why not merge it to 'next' for testing? Worst case, you can also revert it and merge again... D -- 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

Re: [cmake-developers] Extracting target metadata, IDE integration

Ok, how does it sound if we have a variable, such as CMAKE_EXPORT_COMPILE_COMMANDS? Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. I would prefer CMAKE_EXPORT_TARGETS_FILE, or some name that implies it is a filename value, with the value of the variable being the name of the file to generate.

Re: [cmake-developers] Extracting target metadata, IDE integration

The approach looks reasonable, but having it unconditionally spit out a file in cmGlobalGenerator regardless of generator is probably not what we want. Seems like it should be based on a variable, or be in a specific generator, or somehow have a limited scope. HTH, David C. -- Powered by

Re: [cmake-developers] LZMA support

Wow! Fantastic! Thanks to Daniel, great work on this contribution... This is a ton of tedious work, but it will be very useful. Thank you *very much*. Two minor comments -- in the commit at the tip of this topic:

Re: [cmake-developers] LZMA support

Thanks. Actually I think adding xz is incorrect anyway. We support compressed tarballs, not arbitrary compressed files. Therefore the list should be 7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip correct? Well, then it should be tar.bz2, too. And since this is a regex anyway:

[cmake-developers] Should try_run have a timeout value? [demo CMakeLists.txt in body of email]

# # CMakeLists.txt # # PROBLEM: # # This file demonstrates a problem with CMake 3.0 and Visual Studio # compiler x64 builds... If configured for a build with the x64 # compiler, CMake will hang until user intervention with a # cmTryCompileExec123...789.exe has stopped working # crash dialog. # #

Re: [cmake-developers] Should try_run have a timeout value? [demo CMakeLists.txt in body of email]

Would you also be satisfied if the crash dialog was disabled in the try_run()? That is done for ctest by cmCTest::BlockTestErrorDiagnostics(). Sure, as long as the try_run doesn't hang, and indicates failed run in the run result. I'm easy. D -- Powered by www.kitware.com Please keep

Re: [cmake-developers] Should try_run have a timeout value?

Nice literate programming! Thank you. -- 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

Re: [cmake-developers] [PATCH] Fix error in compiling C++ files generating by protobuf compiler when .proto files are organized in a directory hierarchy

Hi everybody there, Subject says it all. See the attached patch please. (Didn't care enough to leave hg for git to generate the patch. Sorry.) FILE_PATH is likely to contain C: or some other drive letter on Windows. It is therefore unsuitable for using to construct a sub-path underneath

Re: [cmake-developers] [PATCH] Fix error in compiling C++ files generating by protobuf compiler when .proto files are organized in a directory hierarchy

Maybe I'm missing something. Is it guaranteed that all callers of PROTOBUF_GENERATE_CPP will pass non-full-path names for the .proto source files? If so, then I retract my statement. But I don't think you can guarantee that. David C. -- Powered by www.kitware.com Please keep messages

  1   2   3   4   5   >