Re: [cmake-developers] why can target_include_directories() not be applied to custom targets?

[Petr Kmoch]

Hi Drew,

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 command.

Note that if you need the properties set for some reason (i.e. if your
custom command/target code uses them for something), you can still set them
just fine using set_property() or set_target_properties(). However, I
expect this to be a very rare thing to do, so I think it's OK
target_include_directories() actually errors out on custom targets. IMO
it's much more likely that a non-custom target was intended.

(Note that I am just an ordinary CMake user, so the above is in no way
"official.")

Petr

On 7 July 2018 at 21:27, Drew Parsons  wrote:

> Commit 510fdcb18801076e2041eaae2941375eecc93ec2 at
> https://gitlab.kitware.com/cmake/cmake/commit/
> 510fdcb18801076e2041eaae2941375eecc93ec2
> prevents custom targets from using target_include_directories().
>
> This makes no sense to me.  A custom target is still a target. It needs
> to be compiled, it uses -I flags.
>
> Can you explain the ban on applying target_include_directories() to
> custom targets?
>
> Drew
>
> --
>
> 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 Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake-developers
>
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] GCC x cmake

[Petr Kmoch]

On Tue, Sep 19, 2017 at 11:34 AM, Ivam Pretti 
wrote:

> 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
> cmake is a build system that uses compilers
> it'd be more meaningful to say make v cmake...
>
> so there is no comparison... definatly an apples and steak comparison (or
> orange would at least be fruit)
>

I think it's even more accurate to say CMake is not a buildsystem either,
but a *generator* of buildsystems. How it works:

CMake generates a buildsystem (such as Makefiles, build.ninja, a Visual
Studio .sln file). Then a build tool (such as make, ninja, Visual Studio,
XCode) interprets that buildsystem to issue compilation commands. These
commands are executed by a compiler (such as gcc, clang, cl).

I fully agree with comparing GCC to CMake being an apples to steaks
comparison (and I'm stealing that phrase for future use) :-)

Petr
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Feature suggestion: auto-create missing files

[Petr Kmoch]

OK, I can see there's quite a few voices against and none for. Idea
scratched.

Thanks everyone for input.

Petr
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Feature suggestion: auto-create missing files

[Petr Kmoch]

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 file on disk, and adding it
> > to the relevant CMakeList add_library() or add_executable() call.
>
> I view this as a matching pair with an implicit sanity check.
>

I sometimes have very deep directory hierarchies (files are 3+ directory
levels below the CMakeLists.txt), with interface header, implementation
header, and implementation source in three different paths down that
hierarchy. Adding one class means adding three very similar lines of CMake
code, and then having to navigate three separate directory paths for adding
the files.


>
> > switch from current behaviour of "error out if source file is not found"
> > to "create empty source file if it's not found."
>
> So a typo in the `CMakeLists.txt` file leads to silent creation of a
> source file instead of an error message?
>

That's why I would make it strictly opt-in. We could even get rid of the
initialisation variable and keep it under full control of the project.


>
> That said, I can see how the proposed feature might be useful when
> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
> reconfigure, and open the new (now existing) file to edit in the IDE.
>

Yes, I'm coming from an IDE background (VS, to be precise). It would be
quite helpful there. I've bounced the idea with other people in my team,
and they agreed it would be useful.


>
> > Is this something that would be acceptable into CMake? Any comments?
>
> I'd like to hear more opinions from others before considering it
> upstream.  It feels like a pretty personal workflow right now, and
> can be implemented in CMake code already (perhaps with the `SOURCES`
> target property to avoid separate lists).
>
> If this were to be done I'd first like to see a policy introduced to
> get rid of the magic extension guessing we do now.  Without knowing
> the full file name with confidence we wouldn't be able to create it.
>

I'm perfectly fine waiting for broader comments. As to extension guessing,
right now the creation happens after that step in my prototype code, and
simply uses the name verbatim as supplied. I'm perfectly willing to create
such a guess-disabling policy, though. I've never used the guessing
functionality anyway.

Petr
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Feature suggestion: auto-create missing files

[Petr Kmoch]

Hi all,

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
CMakeList add_library() or add_executable() call. To me, this feels like
one operation too many. As a result, nearly all of my personal projects
using CMake end up with some sort of wrapper/pre-call which processes file
lists and creates any missing files before the list is passed to the
add_*() call.

I'd like this behaviour to become an option in CMake itself: allow the user
to switch from current behaviour of "error out if source file is not found"
to "create empty source file if it's not found." I've prototyped the
creation itself and it works, but I'd like to discuss the interface for
enabling this functionality. I was considering an inherited boolean
property on individual source file level, plus a variable which would
pre-initialise the property if set. This way, projects could control it on
the finest scope possible (or on broader scopes, since the prorepty would
recurse to directory & global level), while still providing a simple way to
set it centrally.

As far as naming is concerned, I was considering CREATE_SOURCES_IF_MISSING
for the property, and CMAKE_CREATE_SOURCES_IF_MISSING for the variable.

Is this something that would be acceptable into CMake? Any comments?

Thanks.

Petr
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Build multiple CMake projects

[Petr Kmoch]

Hi Jerry,

from your description, it seems like you might be looking for the CMake
module ExternalProject:
https://cmake.org/cmake/help/latest/module/ExternalProject.html

The idea is that you create a "superbuild" CMake project which consists of
ExternalProject_Add calls and related infrastructure, specifying
dependencies between the projects etc. Building this "superbuild" will then
result in acquiring, building, and installing the individual external
projects, in proper order.

Petr


On 24 March 2017 at 19:35,  wrote:

> Hi,
>
> I have some CMake projects which depend on each other. They provide Config
> scripts (all generated with the help of CMakePackageConfigHelpers) and the
> CMake projects find there dependencies with find_package(). Even the
> transitive dependencies are correctly modelled (exported to the Config
> scripts with find_dependency).
>
> The setup in general is fine. The only drawback is that I have to build
> and install them manually in the correct order. For example A depends on B
> depends on C, I have to build+install first C, than B, then A ...
>
> The number of projects are getting more and more and it's getting harder
> to build them.
>
> So my question:
> a) Is there a CMake way to generate a dependency graph and build them in
> the correct order, i.e., the same as CMake does within a project with the
> targets but this time on project level?
> b) What possiblities are provided by CMake to support this?
> c) Are there tools you can recommend?
>
> jerry
> --
>
> 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 Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] cmFileCommand: sort list of files from glob command

[Petr Kmoch]

Hi all.

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,
will now pay a performance penalty for a feature only introduced for the
sake of the ill-behaved ones.

In our setup, we have a large CMake-language framework built on top of
"vanilla" CMake (partly for historical reasons, but partly to support our
particular workflow), and we're always struggling with keeping the time of
CMake processing down. Adding unnecessary overhead would be bad news for us.

Can we instead make the feature optional? Even opt-out would be good
enough, even thought there technically already is an opt-in, namely
`list(SORT)` (which is even mentioned in the docs).

Petr

On 14 May 2016 at 12:30, Reiner Herrmann  wrote:

> file(GLOB ...) is often used to find source files. As it uses
> readdir(), the list of files will be unsorted.
> This list is often passed directly to add_executable / add_library.
> Linking binaries with an unsorted list will make it unreproducible,
> which means that the produced binary will differ depending on the
> unpredictable readdir() order.
>
> To solve those reproducibility issues in a lot of programs (which
> don't explicitely sort the list manually), this change sorts the
> resulting list of the file GLOB command.
>
> A more detailed rationale about reproducible builds is available at:
>  https://reproducible-builds.org/
> ---
>  Help/command/file.rst| 3 +--
>  Source/cmFileCommand.cxx | 1 +
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Help/command/file.rst b/Help/command/file.rst
> index 96ac6c7..a502134 100644
> --- a/Help/command/file.rst
> +++ b/Help/command/file.rst
> @@ -103,8 +103,7 @@ Generate a list of files that match the
>  and
>  store it into the .  Globbing expressions are similar to
>  regular expressions, but much simpler.  If ``RELATIVE`` flag is
>  specified, the results will be returned as relative paths to the given
> -path.  No specific order of results is defined.  If order is important
> then
> -sort the list explicitly (e.g. using the :command:`list(SORT)` command).
> +path.  The file list will be sorted.
>
>  By default ``GLOB`` lists directories - directories are omited in result
> if
>  ``LIST_DIRECTORIES`` is set to false.
> diff --git a/Source/cmFileCommand.cxx b/Source/cmFileCommand.cxx
> index 6b6b913..4efa550 100644
> --- a/Source/cmFileCommand.cxx
> +++ b/Source/cmFileCommand.cxx
> @@ -1026,6 +1026,7 @@ bool
> cmFileCommand::HandleGlobCommand(std::vector const& args,
>
>  std::vector::size_type cc;
>  std::vector& files = g.GetFiles();
> +std::sort(files.begin(), files.end());
>  for ( cc = 0; cc < files.size(); cc ++ )
>{
>if ( !first )
> --
> 2.8.1
>
> --
>
> 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 Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] add_custom_command() OUTPUT does not accept generator expressions, why?

[Petr Kmoch]

On 6 April 2016 at 09:51, Yves Frederix 
wrote:

> [...]
> 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 expressions in the source
> list, so this "should" work. It does not in practice, however:
>
>   CMake Error in CMakeLists.txt:
> Target "test_target" has source files which vary by configuration.
> This is
> not supported by the "Visual Studio 14 2015" generator.
>
> Intuitively I understand why this is not supported (different
> configurations share the same project file in VS, so which source file
> would the project point to?) Is this also a technical limitation
> though? Or do VS project files (and other multiconfig generator
> project files such as xcode) support this setup but was it merely not
> implemented yet?
>

I don't know anything about XCode, unfortunately. However,  Visual Studio
definitely supports a form of varying the source file list of the project
between configurations. That's because a source file can be marked as
_excluded_ from build for a particular configuration. So the solution CMake
could use would be to add all source files from all configurations into the
project, but mark them as excluded from [in]appropriate configurations.

Petr
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] BUG: ALL_BUILD not added to the PREDEFINED_TARGETS_FOLDER

[Petr Kmoch]

Hi Taylor,

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 which actually
use the generated solutions in the IDE for development and debugging
(instead of just building it), ALL_BUILD is useless as a startup project
anyway, and it brings an inconsistency to the Solution Explorer (not to
mention the fact that it pushes to the fore a CMake feature which is not
really necessary in VS, irritating "entrenched" Visual Studio users).

Would a patch introducing such an override option be considered acceptable?

Petr

On Mon, Mar 14, 2016 at 8:58 PM, Taylor Braun-Jones 
wrote:

> For the Visual Studio generator, the ALL_BUILD is not added to the
> PREDEFINED_TARGETS_FOLDER ("CMakePredefinedTargets").
>
> Tested on Windows 10 with Visual Studio 2013 using the following
> minimal CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.5)
> project(foobar)
> set_property(GLOBAL PROPERTY USE_FOLDERS ON)
>
> Targets like ZERO_CHECK, INSTALL, and RUN_TESTS work for me; just not
> ALL_BUILD.
>
> Thanks,
> Taylor
> --
>
> 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 Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

[Petr Kmoch]

Hi all.

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 a lot
of unique setups we have (which were largely inherited from a previous
inhouse buildsystem). Yes, the end result of our framework is that the
CMakeLists consist mostly of declarative commands from our framework, but
the implementation of these commands is heavily procedural. I am convinced
that if CMake didn't give us the procedural power required to make this
work, we couldn't have adopted it. (I had previously tried emulating bits
of this setup in a more declarative system and failed miserably).

Of course (having written much of this framework I'm talking about above),
I know all too well that a better front-end language would do a world of
good for CMake. I also understand that taking a more declarative approach
could help that, and I'm not opposed to such a change in principle.
However, please take care not to throw the baby out with the bathwater and
nerf the expressiveness of what can be done with CMake (in a procedural
way).

If I understand Brad's suggestion correctly, it would amount to a (possibly
empty) procedural step being used to generate a declarative description of
the buildsystem. This would work well in our scenario, I believe, as long
as that procedural step could be sufficiently modularised on the client
side.

I fully support introducing an alternative input language to CMake and
taking all steps necessary for this to happen, but please do this in a way
which will not restrict what CMake is capable of doing.

Petr

On Fri, Jan 8, 2016 at 5:30 PM, Brad King  wrote:

> Hi Charles,
>
> Thanks for your efforts in exploring this topic.  CMake's current language
> grew incrementally out of something that was not originally intended as a
> programming language.  The cmState refactoring Stephen Kelly has started
> is a huge step toward enabling alternative languages, but there is a long
> way to go.
>
> A few general thoughts:
>
> * One rule we have for CMake is to never expose any public SDK of the C++
>   implementation structures.  We want to be able to rewrite them
> arbitrarily
>   at any time.  Therefore any solution that needs to access the C++
>   structures must be integrated into CMake upstream and expose
> functionality
>   only through other languages or file formats.
>
> * The cmState infrastructure builds on a "snapshot" design with a goal of
>   being able to "fork" configuration/generation temporarily and then revert
>   back, and to be able to re-start configuration from the middle.  These
>   goals may be incompatible with any language whose implementation we do
>   not fully control unless it is allowed to execute only in isolated and
>   independent snippets.  These are not hard goals, but it is a trade-off
>   to keep in mind.  Stephen may be able to elaborate more on the snapshot
>   approach if needed.
>
> * A problem with the current design is that the entire configuration
> process
>   is logically serial making parallel evaluation hard or impossible.  In
>   many cases each add_subdirectory can be processed independently, but this
>   will require semantic changes to allow.
>
> On 01/04/2016 02:41 AM, Charles Huet wrote:
> > I'm trying to be as declarative as possible, because really like how
> readable
> > simple QML programs are, and I think it would be perfect for a
> buildsystem.
>
> Ideally most of the specification (sources, libraries, executables, etc.)
> should be in a pure format that can be evaluated without side effects (e.g.
> declarative or functional).  This rules out both Python and Lua, but the
> specification format does not have to be the main entry point.  There could
> be some imperative configuration step that does system introspection and
> then loads the pure specification and evaluates it as needed for the
> specific
> environment.
>
> If we're going to go through the effort to provide an alternative input
> format,
> I think we should strive for this approach because it will be more
> flexible in
> the long run.  A pure specification format will allow easy loading/saving
> by
> other tools, IDEs, etc., without having to process any imperative logic.
>
> > Actually, I'm directly using the cmMakefile, because I did not want to
> wrap all
> > the commands, and it seemed backwards to me to wrap them.
>
> Yes.  Any alternative format should be processed directly into the
> structures
> used by the generators.  The cmState work has separated the generate-time
> representation quite a bit from the configuration-time
> (cmake-language-specific)
> representation, but I think there is still further work needed to finish
> that.
>
> >> Having said all that, Brad favors Lua I believe, and he favors a
> different
> >> approach 

Re: [cmake-developers] Profile Cmake scripts

[Petr Kmoch]

On Tue, Jan 5, 2016 at 1:33 PM, Daniel Pfeifer 
wrote:

>
> 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
one being processed for single-config generators like Makefiles or Ninja.

Petr
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Wrapping functions in CMake

[Petr Kmoch]

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
 target dependences for the beginning and ending timestamp targets.
 The ending time stamp target must depend on every other build target,
 and the beginning timestamp is depended on by every other build
 target.  To do this, as far as I know, we need lists of all build
 targets so we can set this up with the add_dependencies command.


In our project suite setup, we need a list of all existing targets as well.
Having access to it from CMakeLists would be invaluable.

Petr
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] C# support?

[Petr Kmoch]

On Tue, Jun 30, 2015 at 9:21 AM, Stuermer, Michael SP/HZA-ZSEP 
michael.stuer...@schaeffler.com wrote:

 [...]

 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 would suggest
against this. For me, CS does not intuitively associate with C# - I
wouldn't know it means C# unless I read it somewhere stated explicitly.
C, CXX, Fortran are all obvious to me, CS is not.

Then again, I have never used C#, so it might just be general unfamiliarity
on my part, in which case feel free to ignore this post.

Petr
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Issue #14894 fixed version

[Petr Kmoch]

Hi all,

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 field in
Mantis?

Petr
-- 

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 Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] add_custom_command changes, was [Introductions and questions]

[Petr Kmoch]

Hi.

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
annoying) birds with one stone.

I have rather complex CMake framework at work, and this option would
simplify it *tremendously.* So far, I've been working around it with
EXCLUDE_FROM_DEFAULT_BUILD_CONFIG, but it's painful.

Petr


On Wed, Jan 29, 2014 at 11:54 PM, Steve Wilson ste...@wolfram.com wrote:


 On Jan 24, 2014, at 3:25 PM, Steve Wilson ste...@wolfram.com wrote:

  The first item I would like to see merged back to the project is issue
 9974 in the Mantis tracker (CMake should support custom commands that can
 vary by configuration).   I am the author of the original set of patches
 submitted in that report.   I did not have time to follow up on that Mantis
 issue as responses developed, but can follow up now.

 In looking back through my changes for this issue and updating the changes
 for the current sources, I've realized that generator expressions in custom
 commands might be sufficient for my needs (my build system was initially
 designed in 2009 and hasn't been significantly updated for new features
 such as generator expressions).   However there is one bug (14353) that
 prevents them from being fully useful.   My proposed changes for
 add_custom_command would be the following:

   add_custom_command(OUTPUT output1 [output2 ...]
  COMMAND command1 [ARGS] [args1...]
  [COMMAND command2 [ARGS] [args2...] ...]
  [MAIN_DEPENDENCY depend]
  [DEPENDS [depends...]]
  [IMPLICIT_DEPENDS lang1 depend1
   [lang2 depend2] ...]
  [WORKING_DIRECTORY dir]
  [COMMENT comment] [VERBATIM] [APPEND]
  [CONFIG Debug | MinSizeRel | Release | RelWithDebInfo
 | ...])

   add_custom_command(TARGET target
  PRE_BUILD | PRE_LINK | POST_BUILD
  COMMAND command1 [ARGS] [args1...]
  [COMMAND command2 [ARGS] [args2...] ...]
  [WORKING_DIRECTORY dir]
  [COMMENT comment] [VERBATIM]
  [CONFIG Debug | MinSizeRel | Release | RelWithDebInfo
 | ...])


 The addition of course here is the CONFIG keyword that takes a
 configuration argument.   When add_custom_command() has a CONFIG argument,
 all of the commands in the custom command only get executed if the build is
 configured in the requisite configuration (or is selected in an IDE
 configuration).


 Currently generator expressions in custom commands cannot work for this
 kind of usage because of bug 14353.   In 14353 generator expressions that
 have a space character (i.e. more content than just one word/command) don't
 parse correctly and thus make complex custom commands that vary by
 configuration impossible to construct.

 Is there a need for the add_custom_command() version with CONFIG?

 While the generator expressions make short add_custom_command() usages
 work quite nicely I could see the case where the generator expression
 syntax might become unwieldy for larger custom commands that have many
 COMMAND statements.I personally would not want to write:

 add_custom_command(...
 COMMAND $$CONFIG:...:...
 COMMAND $$CONFIG:...:...
 COMMAND $$CONFIG:...:...
 ...
 )

 repeatedly, while having to embed my command inside the generator
 $$CONFIG:...:... syntax.   My build systems have custom commands for
 Unix/Windows/etc... that require careful attention to make sure the commands
 execute correctly in the platform specific command interpreters and the
 $$ syntax would just be an extra confusing layer to have to maintain.
   Even though most usage cases would be fine with the generator
 expressions, I would still find the add_custom_command() with the CONFIG
 keyword useful for use with long custom commands.

 However, if everyone else thinks there is really no need for this form of
 add_custom_command, then I would stop working on re-integrating my changes
 into the source tree and work on 14353 instead.

 Opinions?

 --

 Powered by www.kitware.com

 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

-- 

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:

Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments

[Petr Kmoch]

Hi all.

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 collection of projects at work,
and this framework provides several functions which (naturally) use
cmake_parse_arguments() internally. My users (and myself when I first saw
it) were quite surprised that repeating the leading keyword for multi-value
parameters overwrites values instead of appending them. What I mean:

function(foo)
  cmake_parse_arguments(arg   MULTI ${ARGN})
  foreach(item IN LISTS arg_MULTI)
message(STATUS ${item})
  endforeach()
endfunction()

foo(MULTI x y MULTI z w)

The above code outputs 'z' and 'w'. I originally expected it to output all
of 'x' 'y' 'z' 'w'. I would certainly welcome an option to switch the
behaviour to the latter one.

Petr

On Wed, Nov 6, 2013 at 9:01 PM, Matthew Woehlke matthew.woeh...@kitware.com
 wrote:

 On 2013-11-06 13:57, Brad King wrote:

 On 11/06/2013 01:32 PM, Alexander Neundorf wrote:

 Adding proper named argument handling to cmake_parse_arguments() itself
 is
 somewhat complicated since it can't make use of cmake_parse_arguments()
 ;-)


 Since the need for this is so common, perhaps we should provide a
 C++-implemented command to do it, e.g. cmake_command_options().
 We would need to carefully design the interface here first of course.


 FWIW, I prefer the name [cmake_]parse_arguments :-).

 Is there not already a C++ implementation something like this? (Or else
 how do the existing C++ commands do argument parsing?) If it is C++, I
 guess it would be possible for it to not have the limitation of being
 unable to parse its own arguments? (Actually, in either case, it seems that
 the implementation should be able to have all the 'real work' in a helper
 that is called once to parse arguments to the command itself, then again to
 parse the arguments the user wants to parse.)

 In any case, it would be nice if we could reimplement
 cmake_parse_arguments so that it has the same signature but the
 implementation would newly just wrap the new C++ version.

 What if we had something like:

 parse_arguments(
   PREFIX _
   FLAG_OPTIONS ...
   VALUE_OPTIONS ...
   LIST_OPTIONS ...
   ARGS ...)

 ...where everything after ARGS is no longer considered an argument to
 parse_arguments itself. Also, 'parse_arguments(... IN LISTS ...)' (instead
 of using 'ARGS'), taking names of list variables containing arguments to be
 parsed (similar to 'IN LISTS' of foreach).

 {FLAG,VALUE,LIST}_OPTIONS would accept one or more strings containing
 names of argument keywords, subject to recursive list expansion (should be
 safe - keywords should not contain ';' - and avoids breakage if option name
 lists are given in quoted variable expansions, which could easily happen by
 forgetting to remove quotes when porting to the new signature).

 ...and then of course cmake_parse_arguments can readily accept other
 options to modify its behavior e.g. KEEP_EMPTY (and/or SKIP_EMPTY if
 keeping becomes - or may be, depending on policy - the default).

 --
 Matthew


 --

 Powered by www.kitware.com

 Visit other Kitware open-source projects at http://www.kitware.com/
 opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] Documentation tweaks

[Petr Kmoch]

Hi all,

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.

Petr


0001-Enhnance-documentation.patch
Description: Binary data
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Bug fix requests for the *next* release of CMake...

[Petr Kmoch]

http://public.kitware.com/Bug/view.php?id=8996

On Wed, Nov 7, 2012 at 8:40 PM, David Cole david.c...@kitware.com wrote:

 Hi all,

 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:

   http://public.kitware.com/Bug/view.php?id=13571

 Please move specific discussions into the bugs themselves or start a
 new thread to talk about it... Replies on this thread should just be a
 collector for bug numbers.

 We are aiming for approximately quarterly releases from now on,
 scheduling them every 3 to 4 months. The next release of CMake will
 likely be version 2.8.11, scheduled to have an rc1 release candidate
 on Wed. January 9, 2013 -- just 9 weeks from today.

 If you have a particular issue that you think should be fixed for
 inclusion in 2.8.11, please bring it up within the next two weeks.
 Ideally, each issue will be discussed as needed on the mailing list to
 come to any consensus about what should be done to fix it, and then an
 entry in the bug tracker may be used to keep it on the radar screen,
 and to track activity related to it. You can see what's already on the
 roadmap for this release here:

   http://public.kitware.com/Bug/roadmap_page.php?version_id=103

 Patches are always welcome. Patches that include testing of any new
 features, or tests that prove a bug is really fixed on the dashboards,
 (basically any patch with testing) is preferred over a patch with no
 testing. Also, if you are *adding* code, then you also probably need
 to add *tests* of that code, so that the coverage percentage stays as
 is or rises.

 Please discuss issues here as needed, and add notes to existing issues
 in the bug tracker that you are interested in seeing fixed -- we will
 be looking at the mailing list and activity in the bug tracker to help
 prioritize the bug fixes that will occur in the near future.


 Thanks,
 David Cole
 Kitware, Inc.


 P.S. - as a nice summary of what we accomplished in the CMake 2.8.10
 release, see here:
 http://public.kitware.com/Bug/changelog_page.php?version_id=100 -- it
 currently lists 58 issues that we resolved: nice job, everybody!

 (Many of those were specifically addressed because somebody asked for
 it right here on the mailing list... Don't be shy!)
 --

 Powered by www.kitware.com

 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] EXCLUDE_FROM_DEFAULT_BUILD testing

[Petr Kmoch]

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.
 
  Thanks.  Applied:
 
   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b777272b
   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1f8828c
   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e31d83b3
 
  I tweaked the first patch to avoid configuring anything into
  the test's build tree while configuring CMake itself.  This
  way the test directory can be deleted by hand without needing
  to re-run CMake before the test can pass again.

 I added one commit to fix parallel test invocations:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=739f1665

 -Brad


Thanks. I'm not that versed in CTest, so it's easy for me to fail to
consider something.

Petr
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] EXCLUDE_FROM_DEFAULT_BUILD testing

[Petr Kmoch]

Hi Brad.

Now that 2.8.10 is released, do you think you'd have time to come back to
my patch for per-config EXCLUDE_FROM_DEFAULT_BUILD?

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. This
means it makes 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
base it?

Petr

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 occasionally use MSBuild for driving builds at
  work, but we always feed it solution files. How do you run it so that it
  doesn't read them? And how does it then cope with project dependencies
 etc.?

 I haven't fully investigated yet, but all of the dashboard builds that
 failed the tests were using MSBuild as the tool.  Try building with
 CMAKE_MAKE_PROGRAM set to MSBuild.exe instead of devenv.exe and run
 the test.

 -Brad

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] EXCLUDE_FROM_DEFAULT_BUILD testing

[Petr Kmoch]

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 that may require cmake --build to read
 the .sln file:

  http://www.cmake.org/Bug/view.php?id=13623

 It has some overlap with your work in case you want to try fixing it.

  This means it makes 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 base it?

 Please rebase all your commits on master and squash the not-on-msbuild
 part into the same commit that adds the test.  Include a comment
 explaining why it can't run with MSBuild.


Yup, I'll do that.

Petr
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] EXCLUDE_FROM_DEFAULT_BUILD testing

[Petr Kmoch]

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.

 Since we're trying to keep the dashboard as clean as possible
 right now (to more directly test any changes meant to fix any
 regressions in 2.8.10-rc1) I'm reverting the change:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=69e305f2

 until after the final 2.8.10 release and when we've resolved
 these failures.  We can restore the topic later.


OK, I understand release candidate mode is not the time to add new features
:-)



 The problem is that MSBuild may be used as the build tool
 instead of devenv, especially for VS Express editions.  The
 MSBuild tool doesn't even read the .sln so this property does
 not make sense.  One option is to run the test only when the
 build tool is devenv.


I'm a bit confused. We occasionally use MSBuild for driving builds at work,
but we always feed it solution files. How do you run it so that it doesn't
read them? And how does it then cope with project dependencies etc.?

Anyway, the test only makes sense in cases where the property applies, so
if MSBuild doesn't honour the build/don't build settings in the .sln,
there's no point in running it with MSBuild.

Petr
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] Best practices questions

[Petr Kmoch]

Hi,

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 tests? A new commit normally continuing history of
the patch as I submitted it? Somehow incorporating changes which were done
(by Brad in this case) when merging to next? Something else?

2) Is there a code style document I could read somewhere? I now
understand line width is preferred at 79 columns max. and I believe I've
figured out brace indenting; anything else I should follow?

3) If I have an idea for a feature I'd like to add, how should I start?
Bring it up for discussion here, raise an issue in Mantis, just code the
patch and send it in, ...?

Thanks.

Petr
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] Testing that solution contains what it should

[Petr Kmoch]

Hi all,

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 solution)
contains what it should? If not, are there some test for this which I could
take insipration from?

I tried looking around in the test setup myself, but it feels quite
complicated. I found a test (SourceGroups) which I believe would require
similar functionality, but it doesn't seem to actually inspect the
generated solution (or I couldn't find how it does).

Thanks in advance for any help or pointers you can offer.

Petr
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers