> I don't know what auto-linking is and why that would not interact
> well with IMPORTED targets.
Auto-linking is "header files telling the linker what libraries to link
to" (via "pragma comment lib" in the MS compilers):
http://en.wikipedia.org/wiki/Auto-linking
http://msdn.microsoft.com/en-us/l
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:
http://public.kitware.com/gitweb?p=stage/cmake.git;a=commitdiff;h=5201fb2e62fb06609
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:
7z|tar\\.bz2|t
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 www
> 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.
It makes sense. But what IDE are you referring to? Eclipse? Some other
concrete example? Or just "any IDE and this feature should work
everywhere CMake works...?"
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitw
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
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_EQUAL )
if( STRING_MATCHES )
...i.e., not mentioning anywhere for these operators.
D
--
Powered by w
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
...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 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
> 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 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
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
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
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
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
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
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
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
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
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
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 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
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
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
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,
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:
>
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
>> 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
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
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
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
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:
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
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:
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
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
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
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 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
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
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
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
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
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
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
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:
>
>
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ...)
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
1 - 100 of 108 matches
Mail list logo
