a custom target can do literally anything, it's just a buildsystem wrapper
for running arbitrary executables; or often not even that, and is just a
collection of custom commands. There is nothing CMake automatically does
with the properties [INTERFACE_]INCLUDE_DIRECTORIES set on a custom
On Tue, Sep 19, 2017 at 11:34 AM, Ivam Pretti
> I would like to know what are the advantages or difference when compared
>> to GCC compiler.
> I understand from the topic you mean compared to cmake; but the two are
> two different things
> gcc is a compiler
OK, I can see there's quite a few voices against and none for. Idea
Thanks everyone for input.
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
Kitware offers various services to support the CMake
Thanks for the quick response, Brad.
On 11 April 2017 at 17:52, Brad King <brad.k...@kitware.com> wrote:
> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> > Currently, adding a new source file to a CMake-controlled project
> > means doing two things: creating the fil
I'd like to implement a feature for CMake which I miss there, and I'd like
to get approval for the idea & design before proceeding.
Currently, adding a new source file to a CMake-controlled project means
doing two things: creating the file on disk, and adding it to the relevant
from your description, it seems like you might be looking for the CMake
The idea is that you create a "superbuild" CMake project which consists of
ExternalProject_Add calls and related
I'd like to express my concerns about the proposed change. CMake strongly
discourages using `file(GLOB)` to find source files, since file additions
then do not automatically trigger a buildsystem regeneration. So
well-behaved projects, which do not feed such outputs to add_*() commands,
On 6 April 2016 at 09:51, Yves Frederix
> So, basically, a prerequisite for the above
> to work is that CMake behaves nicely for the following as well:
> add_library(test_lib STATIC existing_file_$.cpp)
> At this moment CMake supports generator
I am afraid this behaviour is by design, so that ALL_BUILD can be the first
target in the generated solution and thus the Startup project by default.
However (speaking to the wider list audience), I would really appreciate an
option to override this "by design" behaviour. For projects
I'd like to voice my opinion as a somewhat advanced CMake user here.
For me, one of the strongest points of CMake is the fact that its project
specification is procedural rather than declarative. In my current job, for
example, we have a significant framework built in CMake which handles
On Tue, Jan 5, 2016 at 1:33 PM, Daniel Pfeifer
> Generators for Xcode and Visual Studio have to generate more files.
... and they have to process all configurations (Debug, Release,
MinSizeRel, RelWithDbgInfo) during the generation stage, instead of just
On Thu, Jul 9, 2015 at 7:35 PM, Clifford Yapp cliffy...@gmail.com wrote:
2. Second we maintain global lists of all exec, library, and custom
targets. This allows us to run timestamping build targets that run at
the very beginning and very end of the build process, by setting up
On Tue, Jun 30, 2015 at 9:21 AM, Stuermer, Michael SP/HZA-ZSEP
About the language:
Would it be ok to name the language in CMake CS instead of CSharp? I
did everything as CS so far...
If I may provide an outsider's comment on this point, I
we've been hit by #14894 (http://public.kitware.com/Bug/view.php?id=14894)
in our project when using CMake 3.0.2. According to Mantis, it's fixed in
3.0, but neither tag v3.0.0 nor v3.0.2 seem to contain the fix. v3.1.0 does
contain it. Would it be possible to update the Fixed in version
I am only a CMake user, not a developer, but I wholeheartedly support
adding the CONFIG keyword to add_custom_*(). While variations in COMMAND
can be handled by generator expressions, variations in OUTPUT can't (see
e.g. bug 12877). Thus, adding the CONFIG keyword would kill two (very
I hope I don't derail the conversation, but since there's now discussion of
providing a new interface and perhaps behaviour-changing parameters for
cmake_parse_arguments(), I'd like to mention another behaviour switch I
would find useful.
I maintain a CMake framework for a large
I've created a small patch with a few minor documentation
enhancements, mainly things I was looking for in the docs but didn't
find them there. I hope you find it useful.
Description: Binary data
Powered by www.kitware.com
Visit other Kitware
On Wed, Nov 7, 2012 at 8:40 PM, David Cole david.c...@kitware.com wrote:
Replies requested. Short replies only. Read on. Just a short reply
with bug numbers or links to the bugs is all we need here.
Example one-line reply:
On Tue, Nov 13, 2012 at 4:55 PM, Brad King brad.k...@kitware.com wrote:
On 11/13/2012 09:18 AM, Brad King wrote:
On 11/12/2012 08:25 AM, Petr Kmoch wrote:
Fixed (that is, works for me) and rebased to 3b7abfd.
no sense to run the tests when using msbuild. Shall I send
you a patch to disable the tests for it? And if so, on what commit should I
On Wed, Oct 17, 2012 at 12:53 PM, Brad King brad.k...@kitware.com wrote:
On 10/17/2012 3:24 AM, Petr Kmoch wrote:
I'm a bit confused. We
On Tue, Nov 6, 2012 at 2:31 PM, Brad King brad.k...@kitware.com wrote:
On 11/06/2012 08:22 AM, Petr Kmoch wrote:
I verified that the tests fail when CMAKE_MAKE_PROGRAM points to msbuild,
because 'cmake --build' does not operate on the .sln in such case.
FYI, a recent issue was filed
On Tue, Oct 16, 2012 at 5:26 PM, Brad King brad.k...@kitware.com wrote:
On 10/16/2012 11:04 AM, Brad King wrote:
I tested it locally on VS 6, 7.1, 8, 9, 10, and 11 all with
spaces in the path. I need to investigate the failures on
the dashboard to identify the problem.
I tried submitting my first patch recently (Issue 0013587) and I have a few
follow-up questions regarding best practices:
1) Looking at the dashboard, I apparently forgot to quote a path somewhere
in the test and it failed on spaces. What is the preferred way for me to
provide a fix for the
I have a question about tests of CMake itself. I'd like to create a new
feature patch and I would definitely want to supply tests with it. Is there
a standard mechanism (perhaps something like the macro check_cmake_test())
to test that a generated buildsystem (specifically, Visual Studio
Mail list logo