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
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 m
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 notifica
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 funct
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 inc
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,
Davi
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 fa
Sorry for the mis-statement. I stand corrected.
However, it is true that there are many find modules with some
differences in approach, and if you are using one, you need to read up
on the individual documentation of that particular find module.
Especially if you need to know how to tell it how to
That's correct:
find modules do what they want, and most do not pay attention to
CMAKE_PREFIX_PATH.
It's better to use a config file, but when you have to use a find
module, you have to dig in and figure out the right way to use each
one.
On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey
wrote:
Is there a ZLIBConfig.cmake file which find_package is searching for?
(i.e. -- somewhere under that directory does that file exist?) On
Windows the case won't matter, but on Linux, a find_package(ZLIB will
expect a case-sensitive match on a ZLIBConfig.cmake file.
If ZLIBConfig.cmake exists, it nee
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 AM, Robert Dailey wrote:
CMAKE_PREFIX_PATH:
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 wrote:
>>
>> On 8/15/17, Daniel Pfeife
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 t
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, but
>> After my find_package(OtherProj) call, which is a super build which
>> defines lots of imported targets, I want the target to be named gtest
>> to match its library name, but OtherProj has named it googletest.
>
> Why isn't there a standard name? Should upstream provide the imported
> target? Ha
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 OtherProj::g
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 12:3
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é.
> With the attached patch it is possi
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,
Last I did with it is seen here:
https://github.com/dlrdave/CMake/tree/add-targets-to-get-cmake-property?files=1
I abandoned it because of lack-of-time on my part, and the implementation is
hacked into cmState... And I didn't have time to wade through and figure out
what was being refactored ar
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 wrote:
>> The part that proba
Sounds to me like lapack should conditionally set CTEST_TEST_TIMEOUT only if
it's not DEFINED already. With such code in the project, callers could define
it on the command line with -D, or directly in a ctest -S script, and the
passed in vale would "win" since in this case, the project would NO
The principle "most local setting wins" should be followed.
If a script is called without --timeout cmd line param, CTEST_TEST_TIMEOUT
applies, if set. Otherwise default timeout value.
If a script is called with --timeout cmd line param, then that **is** the
timeout value, and CTEST_TEST_TIMEOU
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 the
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 p
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 wrote:
> On Fri, Dec 4, 2015 at 11:32 PM, David Cole > wrote:
> > Makes sense.
> >
> > Can I inject my own "#include " into
> > th
Makes sense.
Can I inject my own "#include " into
the generated stream, or otherwise inject something into it?
Specifically, for me, I want to include some, but not ALL VTK headers
for a VTK-based project.
Thanks for working on this.
Let me know if you want me to be a Visual Studio tester for y
Right, I was talking about the pch-binary.
Why would CMake even need to generate a header file for pre-compiled
headers? Why not just allow the user to say which of his header files
should be the one to use for precompiled headers?
I have a project I work on which is a VS-only non-CMake based pro
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 wrote:
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
> while checking on the sig
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
> installations it would
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 incorrect
values with 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 wrote:
> On 07/17/2015 06:05 PM, David Cole via cmake-developers wrote:
>> Attach
t; option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake
> script file which tests/shows this feature.
>
> Stefan Kislinskiy
> ____________
> Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von
> David Cole via cma
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
On
It's exactly what I am concerned about:
You're asking to change the behavior of something for EVERYONE to
solve a problem which you have encountered. If you change it the way
you have proposed, you will cause problems for others. It has worked
the way it is now since ExternalProject_Add was introd
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
Isn't simply **not listing** GIT_SUBMODULES sufficient?
On Friday, August 14, 2015, Konstantin Podsvirov
wrote:
> In the next CMake we obtain the following useful thing:
>
>
> http://www.cmake.org/cmake/help/git-master/release/dev/ExternalProject_init_selected_submodules.html
>
> But how to dis
One thing to consider before embarking on modifying CMake for
"required environment" purposes is that it might be just as simple to
"force" (or at least strongly encourage) your project developers to
use the proper environment for running the whole build.
You could, for example, have an initial "e
Thanks for the comments. I'll incorporate these into my next iteration...
On Mon, Jul 20, 2015 at 9:30 AM, Brad King 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
You're welcome. The key to using it effectively, of course, is using it at
the very bottom of the top level CMakeLists.txt file. It can only report on
the targets defined so far, so if you put it in the middle somewhere,
targets may be defined after you use it, and you'll miss them...
D
On Satu
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 it out over the weekend.
Cheers,
David C.
On Fri, Jul 17, 2015 at 3:0
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 get_property.
While it's relevant, and I think
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...?
To implement TARGETS for get_cmake_property, I would look to see what
logic is used by "if(TA
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 wrote:
> On Thu, Jul 16, 2015 at 13:27:12 -0400, David Cole via cmake-developers wrote:
>> This woul
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 wrote:
> On Wed, Jul 15, 2015 at 9:10 AM, Brad King wrote:
>> On 07/10/201
Correct -- it's typically used as an **initial** cache only, in a
clean build tree.
Actually, I'm not sure what happens on subsequent (2nd and later)
runs... It may be that the cache has precedence, and the -C file has
no effect on subsequent runs unless you use "FORCE" in it... But I'm
uncertain.
You don't. It's just another way to specify the command line
arguments, but as a single command line argument instead of dozens or
hundreds.
It's a mechanism for you to avoid the command line length limit.
Wasn't that your question...?
On Mon, Jul 13, 2015 at 2:01 PM, Robert Goulet
wrote:
> Hi
You could use the -C command line option to pass in the name of a file
containing initial cache values. See the "-C " 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 set(... CACHE ...)
n 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 t
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
wrote:
> Sounds reasonable,
>
>
>
> my choice was motivated by the file extension of the C# source files (.cs)
> and that it is shorter. But as Fortran se
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
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 wrote:
> @kgt: Thank you for this great hint. :-)
> I had overlooked this button in Visual St
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 ev
Can you change your CMake minimum required version to 3.3?
On Wed, Jun 10, 2015 at 10:11 AM, Arunava Nag 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 for compilers if
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
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 bu
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 wrote:
> This one:
> https://github.com/Kitware/CMake/blob/master/Tests/CMakeTestMultipleCo
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:
https
I realize that sometimes dependencies are necessary.
But.
There's a very strong argument to be made that projects should not
have "a lot" of external dependencies.
If you really need to tell an ExternalProject "build this external
project the same way as the main one," you should probably write
Why wouldn't you just write your own "toolchain wrapper" file which
has all the variables you speak of, but also includes the "real"
toolchain file, and then use the wrapper as your CMAKE_TOOLCHAIN_FILE
value ... ?
D
On Sun, Apr 26, 2015 at 7:32 PM, Andrey Pokrovskiy
wrote:
> Hi,
>
> I'm usin
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 wrote:
> On 04/24/2015 02:40 PM, Nils Gladit
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 wrote:
> Ah~, so it's a hidden feature? OK, I will give a try.
>
> Th
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 s
Great -- thanks for checking. This proposed change looks reasonable to me...
On Fri, Apr 17, 2015 at 12:27 PM, Andrey Pokrovskiy
wrote:
>> does the external project's configure step re-run when you edit only the
>> CMAKE_CACHE_ARGS for it?
>
> Yes. Verified with the following example:
>
>
>
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
wrote:
> In current implementation of ExternalProject_Add generator express
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 peopl
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 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 have CMakeCach
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 th
If this change fixes the problem... then the problem must be that the
midl tool is being run from the wrong directory when it fails. Or that
midl is being run at the same time for two different projects both
trying to write output into the same directory simultaneously? (But
wouldn't this latter on
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 wrote:
> Hi!
>
> I sometimes dream o
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
some
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 backward
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 care
e:
> > 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
have platform differences. As long 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 wrote:
> On Thu, Dec 11, 2014 at 14:41:36 -0500, David Cole via cmake-dev
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 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 stri
On Mon, Nov 24, 2014 at 3:10 PM, Rolf Eike Beer wrote:
> David Cole wrote:
>> Eike,
>>
>> The changes you made in this commit:
>>
>> http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec36e1c2afe7c8258588d
>> d51a9fe75b7fb523206
>>
>> appear to have introduced a change in behavior such that th
Eike,
The changes you made in this commit:
http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec36e1c2afe7c8258588dd51a9fe75b7fb523206
appear to have introduced a change in behavior such that the test is
running recursive dependency checks instead of just direct dependency
checks.
Evidence:
look at what's going on.
>>>
>>> -Original Message-
>>> From: Brad King [mailto:brad.k...@kitware.com]
>>> Sent: Friday, November 14, 2014 08:38
>>> To: David Cole
>>> Cc: cmake-developers@cmake.org; Gilles Khouzam
>>> S
ware.com]
>> Sent: Friday, November 14, 2014 08:38
>> To: David 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:
>
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,
38
> To: David 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
Hi,
The VSWinStorePhone tests are failing on my dashboard submissions:
http://open.cdash.org/viewTest.php?onlyfailed&buildid=3570369
http://open.cdash.org/viewTest.php?onlyfailed&buildid=3570163
I just upgraded that machine to Windows 8.1 and Visual Studio 2013,
and these dashboards run in a VS
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 c
These are the earliest CDash results available for CMake:
http://open.cdash.org/index.php?project=CMake&date=2014-07-09
(they're discarded after 120 days...)
On Thu, Nov 6, 2014 at 5:27 PM, Rolf Eike Beer wrote:
> Am Donnerstag, 6. November 2014, 12:44:12 schrieb Brad King:
> > On 11/06/2014 12
I would prefer a name that begins with UPDATE_ if it only affects the
update step.
D
On Wed, Nov 5, 2014 at 6:57 PM, Daniele E. Domenichelli <
daniele.domeniche...@gmail.com> wrote:
> On 05/11/14 17:39, Brad King wrote:
> > Would the name "UPDATE_INDEPENDENT" or "UPDATE_DISCONNECTED"
> > make m
I would say yes, too.
On Tue, Oct 28, 2014 at 3:27 AM, Daniel Pfeifer
wrote:
> 2014-10-27 21:33 GMT+01:00 Ben Boeckel :
>
>> On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote:
>> > Trying to bring a bit more attention to this:
>> >
>> > Fedora is pushing to have higher resolution ico
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
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 wrote:
> I thought it would be interesting to install my own local dart server
> to learn how to use CTest as a dart client. Howeve
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
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
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, wrote:
>
>
>
>>
>> It should not be an error for 'codesign
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 f
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 except
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:
http://www
> 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 e
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 "Conf
...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 reinvent
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:
http://www.cmake.org/gitweb?p=cm
1 - 100 of 108 matches
Mail list logo
