[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-109-gd6e99fa

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  d6e99fa8345f07a72308b8b33f4a31aa7fe9a0fd (commit)
  from  c5d71b28ec2682ec160dd35015e90dd5b81a5605 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d6e99fa8345f07a72308b8b33f4a31aa7fe9a0fd
commit d6e99fa8345f07a72308b8b33f4a31aa7fe9a0fd
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sat Jun 11 00:01:07 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sat Jun 11 00:01:07 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 254d9de..a27d5e1 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 6)
-set(CMake_VERSION_PATCH 20160610)
+set(CMake_VERSION_PATCH 20160611)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] CMake and FindBoost cannot set the library variables

[Xi Shen]

Thanks a lot man~



On Sat, Jun 11, 2016 at 3:04 AM Roger Leigh  wrote:

> On 10/06/2016 13:50, Xi Shen wrote:
> > find_package(Boost REQUIRED COMPONENTS regex program_options)
> >
> > add_executable(winotify winotify.cpp)
> >
> > message(STATUS "xxx ${Boost_program_options_LIBRARY_DEBUG}")
>
> Try Boost_PROGRAM_OPTIONS_LIBRARY_DEBUG
>
> > message(STATUS "xxx ${Boost_INCLUDE_DIR}")
> > message(STATUS "xxx ${Boost_LIBRARY_DIR}")
>
> Try Boost_LIBRARY_DIRS
>
> Even easier: use the Boost::program_options interface target
>
>target_link_libraries(winotify Boost::program_options)
>
> and it will handle both the include dir and the library to link with
> transparently.  It's the way forward!
>
>
> Regards,
> Roger
> --
>
> 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
>
-- 

Thanks,
David S.
-- 

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

Re: [cmake-developers] Questions about coding conventions

[Daniel Pfeifer]

On Fri, Jun 10, 2016 at 3:43 PM, Brad King  wrote:
> On 06/10/2016 09:30 AM, Daniel Pfeifer wrote:
>> By looking at the CMake source code, there are some inconsistencies
>> regarding coding conventions. This is not a big problem and fixing
>> them probably does not have a high priority.
>> I would like to know what conventions to follow for new code.
>
> Please look at documenting this in CONTRIBUTING.rst once we resolve
> this discussion.

ok.

>> Formatting: No longer an issue. A .clang-format is provided and most
>> inconsistencies have disappeared.
>
> Yes, and thanks for all your work on that.
>
>> Braces around single conditional statements: This is currently not
>> consistent. Should they be avoided? Should they be required? We could
>> add the missing ones with clang-tidy. If we want them.
>
> The intention has been to use braces for all blocks even with single
> statements.  Due to lack of documentation and enforcement this has
> not been maintained consistently.

I have added some missing ones:
https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=a16bf141bc5d393b27d13d8235d95a1b034052c2

>> Naming conventions: Classes are named  cmLikeThis. Member functions
>> and member variables are named LikeThis. Local variables are named
>> likeThis. Members are always accessed with `this->`.
>
> Yes, though there are also many local variables named `like_this` too.
> I have no strong feelings on enforcing local variable name conventions.
>
>> So far it is pretty consistent. But how to name free functions and
>> macros? I have seen all kinds of variations.
>
> No convention was ever established for those.

I see. Any strong opinion whether a convention should be established?
I would assume UPPER_CASE for macros. Any prefix?
Any opinions about free functions?

>> `const T` or `T const` (also: `const T&` or `T const&`): Currently,
>> CMake uses both. I have not analyzed which one dominates.
>
> I prefer `T const` always, except for `const char*` specifically.

Good.

>> Passing and returning strings: We have `const char*`, `std::string`,
>> and `std::string const&`. Unifying this can affect performance.
>> Storing `const char*` in a `std::string` creates a (potentially
>> unneded) copy (assuming it is not null). `const char*` can distinguish
>> invalid from empty. Do we actually need this distinction?
>
> Last year we had a few cleanup passes done along those lines, but
> it is far from consistent everywhere.  There  are cases where we
> need to distinguish invalid from empty, like GetDefinition().  It
> would be nice to have an optional or something like that
> so we can keep the distinction but avoid using `const char*` all
> over.  Any change like this should be introduced gradually, as
> many of the related areas are performance sensitive.

So the convention would be to use `std::string` or
`cmOptional` as return values. Should `std::string
const&` be allowed as return value?
Arguments should be preferred as `const&` I assume.


Some other questions:

Can't `std::ifstream` and `std::ofstream` be used directly? It seams
that kwsys does some workarounds for Visual Studio 2005 and newer.
That surprises me. Workarounds are usually used for older, not newer
compilers.

I see that `#include ` is preferred over `#include
`. Are there old compilers supported that prohibit the latter
or was it just not changed yet?

cmStandardIncludes.h includes many standard headers. That is against
the idea of include-what-you-use. Is there a particular requirement or
was it just not cleaned up yet?

Should we begin using newer language features optionally by providing
macros like CM_OVERRIDE?
-- 

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] daemon-mode: Project structure

[Tobias Hunger]

Hi Stephen,

Am 10.06.2016 20:53 schrieb "Stephen Kelly" :
> > [== CMake MetaMagic ==[
> > {
> > # Reply header:
> > "cookie":"",
> > "type":"reply"
> > "inReplyTo":"project",
>
> Part of the design of the daemon is that messages that it sends can be
> 'spontaneous' - it watches for filesystem changes and can tell clients to
> re-read the buildsystem information.

That is currently not done or needed, but can be added.

> The inReplyTo does not fit that model.

It does. A filesystem change would be "type":"signal" or something instead
and will not have a inReplyTo (as it was not generated in reply to
something.

> Additionally, it appears to be
> redundant if you have a 'cookie'?

No, cookies are to attach user data to requests and that is entirely
orthogonal to what inReplyTo does.

> >
> > # Data:
> > "projects":
>
> What you call 'projects' appear to be 'targets' in CMake vocabulary. Is
that
> correct? Note that a project is something different in CMake vocabulary
(see
> the project command).

Actually that is exactly what is returned here.

> Note also that in CMake, targets (libraries, executables etc) have a
project
> name.  Conceptualizing this as 'a project is a group of targets' doesn't
> work well because of how CMake deals with multiple project() commands and
> the VS and Xcode structures it generates. See
>
>  cmGlobalGenerator::FillProjectMap()
>
> and how the result of that method is used. It is important that the daemon
> does not create a new claim of truth in this regard - the structure from
the
> daemon should be the same as the structure generated for those ide
projects.

Why?

I want the structure that *CMake* sees. What some unrelated program
generates out of that structure is irrelevant.



> > Is this the information you need for IDE integration?
>
> You might be packing too much into one protocol verb. Try this on LLVM and
> VTK for example to see how much data it is. Perhaps then compare with the
> gradual approach in my branch.

CMake itself is way below 100KiB.

A typical developer machine should be able to handle several 10MiB of JSON
data just fine. So I do not expect a problem there.

> In my branch I have
>
> * `buildsystem` - Get the targets (name, type, project) and backtraces
> * `target_info` - Get buildsystem properties for a target
> * `file_info` - Get buildsystem properties for a file in a target

I know. I did not like that, so I did it differently.

Basically I do want the really important information in one go instead of
requesting a little bit, iterate over the data, request some more, ...

In the end that is a lots of needless round trips and you send more data
over the wire, too, with all the protocol overhead.

> Getting the backtraces (instead of the location) for targets is important
-

I am aware of the importance of backtraces, but I do not see any use case
where this information needs to be available at the point the project
structure is requested.

An IDE can for example request backtraces for a target when/if needed and
does not need it right away to set up a project tree and code model.

A tool to run a static analyzer over all C++ files in a project will not
need backtraces ever.

This is why that information is not contained in the project structure at
all. Yes, we need to provide a way to retrieve backtraces for targets (and
other symbols), but not here.



The biggest part of your mail is about the history of the patch set and how
to collaborate further.

My cmake-daemon branch on github documents how I got from your branch to
mine.

I basically copied the cmServer* files from that branch on top of a fresh
CMake checkout when I started the new branch, removing all the Process*
functions and wiring up the server again. There was no change outside the
cmServer* files apart from the wiring to start the daemon.

Then I proceeded to add the Process* methods and other functionality back
in.

I did that to make review simpler for *other* reviewers. I had not expected
you to chime in at all. Don't get me wrong: I appreciate you experience,
your patience and your reviews! I just had not expected it. The impression
I got talking to you before is that you do not have the resources to push
this functionality forward at this time. In fact that is the *only* reason
I stepped up for this task.

This is why I wonder how working through your branch is supposed to
function within the resource limits on your side?

I do not want for this work to vanish into some obscure github branch
somewhere for weeks and month -- as it did so far. The CMake daemon is too
cool a feature for that!

Best Regards,
Tobias
-- 

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: 

[cmake-developers] [ANNOUNCE] New Modules and Ports at DaD's House

[Konstantin Podsvirov]

Hi guys! Hello developers!

My "DaD's Project" is based on CMake and QtIFW (specifically CPackIFW) 
continues its development:

http://dad.podsvirov.pro - the official "DaD's House" website now.

"DaD's House" is a resource where you can download the installers to install 
necessary dependencies
and immediately begin developing their projects.

Already declared support 40 the following modules:

Curses, ZLib, LibPNG, Jpeg, Libxml2, LibTIFF, Perl, OpenSSL, LibSSH2, cURL,
PCRE, PROJ, Expat, FreeType, SQLite, GEOS, GDAL, Boost, Qt, QtIFW,
CMake KDSoap, OSG, osgEarth, osgQtQuick, PostgreSQL, Apache.Apr, The 
Apache.AprUtil, Apache.Httpd, Protobuf,
gRPC, MapServer, Bullet, QCA, wxWidgets, LibXSLT, iconv, pgAdmin3, Wt, FreeGLUT.

Also available in 4 port:

 - Windows Visual C++ Compiler 12.0 32bit
 - Windows Visual C++ Compiler 12.0 64bit

and NEW

 - Windows 5.3.0 MinGW w64 32bit
 - Windows 5.3.0 MinGW w64 64bit

The last 2 ports have appeared recently and there are still large but 
interesting work.

All of this can be a good basis for your projects.
All this is a good basis for my personal growth.

I assess the status of the project as a Beta and write to lists for developers 
of basic technologies.

Open the curtain.

For each module I have a small CMakeLists.txt:

http://git.podsvirov.pro/?a=project_list;pf=dad/mod

These scripts help me to build the modules and create a repository of binary 
components.

There is a need to spread content. All available here:

http://download.podsvirov.pro

My server is small and weak. I need help in distribution. I need a mirror 
"main" module:

rsync://podsvirov.pro

If there are interested parties and you give me the address of the mirror, then 
I can add them to MirrorBrain setup
for more efficient distribution.

If you are interested in developing this technology or already use my 
installers, I would like to hear your opinion
and to get feedback.

Have a great weekend and good luck in development of your projects!

--
Regards,
Konstantin Podsvirov
-- 

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] Questions about coding conventions

[Daniel Pfeifer]

On Fri, Jun 10, 2016 at 5:19 PM, Tobias Hunger  wrote:
> On Fr, 2016-06-10 at 16:34 +0200, Daniel Pfeifer wrote:
>> If used consistently, it indicates that you are dealing with a member.
>> I personally prefer `this->` over `m_`. With semantic syntax
>> highlighting you probably don't need either of them. But then again,
>> you often look at code that does not have semantic highlighting (eg.
>> inside diffs).
>
> So you optimize for teletype terminals and punish everybody that has invested 
> in
> new stuff like screens with *color* in the last couple of decades:-/
>
> /me is trapped in 1995!

In 2016, semantic highlighting is the exception rather than the norm.
I expect that to remain that way for some years to come.
Git diff output, compiler diagnostics, github, the woboc code browser
are all very colorful. Yet, members are not highlighted anywhere.
-- 

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] Review request: extract-cmMessenger branch

[Daniel Pfeifer]

On Fri, Jun 10, 2016 at 8:17 PM, Stephen Kelly  wrote:
> Tobias Hunger wrote:
>> Forcing messages into one consistent format will be a pain, agreed, but
>> continuing to add messages in whatever form the developer likes at the
>> time of writing the code is even worse. CMake has a lot of different error
>> message styles!
>
> This is something my branch addresses in part, which is why I drew attention
> to it in the context of the daemon.
>
>> If you were to unify on e.g.
>>
>> CMake Error at FILE:LINE (OPTIONAL_EXTRA_INFO):
>> MULTILINE_MESSAGE_WITH_INDENT_ENDING_IN_TWO_NEWLINES
>>
>> then you will probably hit existing code paths in IDEs.
>
> I don't think that's possible for all messages (not all messages have file
> or line information).
>
> However, that's not a problem when messages are delivered through the
> daemon, so I suggest that
>
>  https://github.com/steveire/cmake/tree/extract-cmMessenger
>
> and the daemon itself are good places to direct your attention to improve
> this situation.

I have reviewed the branch and wrote some inline comments on github.
Overall, I confirm this is the right approach. So, "approval" from my side.
-- 

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] [ANNOUNCE] CMake Issue Tracker Moved

[Brad King]

Hi Folks,

CMake issue tracking is now hosted on Kitware's GitLab instance:

  https://gitlab.kitware.com/cmake/cmake/issues

The old mantis issue tracker will remain available as a read-only
reference.  All CMake issues from that tracker have been migrated
to the new CMake Issues page with their original numbers intact
and links back to the original mantis pages in their descriptions.
Further discussion of any issue should take place on its new page.

If you do not have an account on Kitware's GitLab instance, please
visit this page to register and sign in:

  https://gitlab.kitware.com/users/sign_in

If you have a GitHub Account (github.com) or a Google Account
you may optionally use the corresponding icon on the
"Sign in with" line instead of entering a user name and password.
Alternatively, you may register with a user name and password
first, and then visit your user settings Account page:

  https://gitlab.kitware.com/profile/account

and associate your GitHub or Google accounts in the "Social sign-in"
section.  We also encourage you to enable two-factor authentication.

For developers who could be assigned issues in mantis before, please
email me privately with your Kitware GitLab user name so I can add
you as a developer in the new CMake Issues page.

The issues on the new page have not been assigned automatically.
If an issue was assigned to you in mantis that you still wish to
have assigned to you, please manually self-assign on the new page.
Those issues that were open in mantis before the migration have been
Resolved as "moved".  One may use the old mantis query page here:

  https://cmake.org/Bug/view_all_bug_page.php

Query for "Resolution: moved" and "Assigned To: " to find issues
previously assigned to you that were not resolved prior to migration.

-Brad
-- 

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] CMake and FindBoost cannot set the library variables

[Roger Leigh]

On 10/06/2016 13:50, Xi Shen wrote:

find_package(Boost REQUIRED COMPONENTS regex program_options)

add_executable(winotify winotify.cpp)

message(STATUS "xxx ${Boost_program_options_LIBRARY_DEBUG}")


Try Boost_PROGRAM_OPTIONS_LIBRARY_DEBUG


message(STATUS "xxx ${Boost_INCLUDE_DIR}")
message(STATUS "xxx ${Boost_LIBRARY_DIR}")


Try Boost_LIBRARY_DIRS

Even easier: use the Boost::program_options interface target

  target_link_libraries(winotify Boost::program_options)

and it will handle both the include dir and the library to link with 
transparently.  It's the way forward!



Regards,
Roger
--

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

Re: [cmake-developers] daemon-mode: Project structure

[Stephen Kelly]

Tobias Hunger wrote:

> Hello everybody,
> 
> I made some progress with extracting project structure from cmake via the
> daemon-mode. I am rather happy with the information and would love to get
> some feedback from other interested parties.
> 
> Here is the format that is currently reported (with comments;-):
> 
> [== CMake MetaMagic ==[
> {
> # Reply header:
> "cookie":"",
> "type":"reply"
> "inReplyTo":"project",

Part of the design of the daemon is that messages that it sends can be 
'spontaneous' - it watches for filesystem changes and can tell clients to 
re-read the buildsystem information.

The inReplyTo does not fit that model. Additionally, it appears to be 
redundant if you have a 'cookie'?

> 
> # Data:
> "projects":

What you call 'projects' appear to be 'targets' in CMake vocabulary. Is that 
correct? Note that a project is something different in CMake vocabulary (see 
the project command). 

Note also that in CMake, targets (libraries, executables etc) have a project 
name.  Conceptualizing this as 'a project is a group of targets' doesn't 
work well because of how CMake deals with multiple project() commands and 
the VS and Xcode structures it generates. See 

 cmGlobalGenerator::FillProjectMap() 

and how the result of that method is used. It is important that the daemon 
does not create a new claim of truth in this regard - the structure from the 
daemon should be the same as the structure generated for those ide projects. 

You may need to understand that before you can create something final here.

Of course, my branch 

 https://github.com/steveire/CMake/commits/cmake-daemon-lite

is already 'correct' in this regard.

I think you need to understand my branch more. You're doing some different 
things, but you haven't compared and explained the differences I think. 
There should be comparison and convergence in the end.

> Is this the information you need for IDE integration?

You might be packing too much into one protocol verb. Try this on LLVM and 
VTK for example to see how much data it is. Perhaps then compare with the 
gradual approach in my branch.

In my branch I have 

* `buildsystem` - Get the targets (name, type, project) and backtraces
* `target_info` - Get buildsystem properties for a target
* `file_info` - Get buildsystem properties for a file in a target

Getting the backtraces (instead of the location) for targets is important - 
the location relevant to the user might be a macro invocation, not the 
inside of a macro. See:

 https://www.youtube.com/watch?v=BPgXuvPAl-8=870

In general I think you are missing a lot by not understanding my branch. My 
branch is created with the mindset of 'expose what is correct in CMake'. You 
are creating what you think QtCreator needs - that's good, but what is 
needed is convergence between the two. 

If you rebase your work on top of mine, then you can explain why you do 
that, and we can find out if you are exposing 'correct' information (I'm 
thinking again of the project stuff). For your convenience, I have pushed 
your work to my clone (after rebasing):

 https://github.com/steveire/CMake/commits/daemon-hunger

I suggest you continue your work from there. That way we can discuss your 
changes and converge on something correct.

Notice that some of your changes make some diffs needlessly big and 
therefore harder to understand. For example you rename member variables from 
mLoop to m_Loop, and you rename the cmMetadataServer class to cmServer. Both 
only make it harder to understand your patches. I recommend fixing up your 
patches to remove those differences. 

That way we can converge on the dual goals of exposing correct information, 
and exposing what QtCreator needs. 

You are currently diverging from my work without explaining the differences, 
leading to incorrectness in some cases, and you are missing out on the work 
that I have already done.

Thanks,

Steve.


-- 

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] cmCacheManager related changes

[Stephen Kelly]

Brad King wrote:

>  cmState: Expose list of properties of values in the cache
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63c0e92c

The way these classes are designed, cmState is intended to be the way to 
access state which generally does not change during a CMake configure run in 
a way which would be observable to and relevant to the daemon.

Things which do change in such a way should be accessed through 
cmState::Snapshot, or classes which depend on cmState::Snapshot such as 
cmState::Directory for directory properties, or some day cmState::Target for 
target properties. That way those properties can be versioned.

It is true that some existing things in cmState should not be there 
(commands, cache properties etc). You can consider whether now is the time 
to move the cache property access to cmState::Snapshot (even without 
versioning internally) instead of adding more methods related to cache 
properties to cmState directly.

Thanks,

Steve.


-- 

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] Review request: extract-cmMessenger branch

[Stephen Kelly]

Tobias Hunger wrote:
> Forcing messages into one consistent format will be a pain, agreed, but
> continuing to add messages in whatever form the developer likes at the
> time of writing the code is even worse. CMake has a lot of different error
> message styles!

This is something my branch addresses in part, which is why I drew attention 
to it in the context of the daemon.

> If you were to unify on e.g.
> 
> CMake Error at FILE:LINE (OPTIONAL_EXTRA_INFO):
> MULTILINE_MESSAGE_WITH_INDENT_ENDING_IN_TWO_NEWLINES
> 
> then you will probably hit existing code paths in IDEs.

I don't think that's possible for all messages (not all messages have file 
or line information).

However, that's not a problem when messages are delivered through the 
daemon, so I suggest that 

 https://github.com/steveire/cmake/tree/extract-cmMessenger

and the daemon itself are good places to direct your attention to improve 
this situation.

Thanks,

Steve.


-- 

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] how to compile single source file with debug options?

[Gonzalo]

El 10/06/16 a las 13:57, Sergey Spiridonov escribió:

I do release build, but I want single source file to be compiled in
debug mode, with "-O0 -DDEBUG" options instead of "-O3".

Of course, without recompiling whole directory.

Oh, I see. In perspective, Windows, for example, does not allow mixing 
debug and non debug builds.
I am afraid cmake cannot do what you want.  But you may be able to do it 
with a wrapper bash script.
The idea would be to have two CMakeCache.txt files (one debug, one 
release) and a CMakeFiles directory.  Once you want to compile a single 
file in a directory, you'd rename the debug CMakeCache.txt file and run 
cmake/make.

I'll let others chime in with more elegant solutions.

--
Gonzalo Garramuño
ggarr...@gmail.com

--

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

Re: [CMake] execute_process, cmd /c and vcvarsall

[Adam Rankin]

Thank you Kristian, I will keep experimenting.

David, I agree, and in my own project I have done it that way.

However, I am attempting to fix the CUDA auto detection in OpenCV, and I am not 
sure if they would take kindly to adding .bat files for Windows only solutions 
(maybe they will, I haven't discussed it yet).

I was hoping to solve the problem within a CMake one-liner to reduce the 
complexity of the change.

Thanks for your suggestions,

Adam

-Original Message-
From: David Cole [mailto:dlrd...@aol.com] 
Sent: Friday, June 10, 2016 7:48 AM
To: Kristian 
Cc: Adam Rankin ; cmake@cmake.org
Subject: Re: [CMake] execute_process, cmd /c and vcvarsall

The easiest way to do what you want here is to make a standalone script (*.bat 
/ *.cmd) that runs the commands you want and get it to work without CMake 
involvement at all, and then simply use execute_process to invoke that script.

You can pass arguments to it if you need to communicate information from CMake 
to the script, but if you **require** environment for your command to run, the 
easiest way to achieve it is to write a script that sets up the env, and then 
executes the command, and then restores the environment (if necessary).

In Windows *.cmd files, it's easy to save/restore the environment by using 
"setlocal" and "endlocal".

Why bother with all the escaping and special characters in an execute_process 
when you could just write a script and then call it?
It will be much easier on the eyes for people having to read your code in the 
future if you make it simpler.


HTH,
David C.




On Fri, Jun 10, 2016 at 6:21 AM, Kristian  wrote:
> After some tries I found maybe a solution for you. In my small 
> example, I had these lines, which are working:
>
>
>> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio
>> 14.0/VC/vcvarsall.bat")
>> execute_process(COMMAND ${HELLO1} && msbuild /help WORKING_DIRECTORY
>> "${CMAKE_CURRENT_SOURCE_DIR}")
>
> So for you, it would look like this (I am not very sure about it):
>
> ==
>
>
> execute_process( COMMAND
> $ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat x86_amd64 && 
> ${CUDA_NVCC_EXECUTABLE} 
> ${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu --run
>
>  WORKING_DIRECTORY
> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/"
>
>  RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out
>
>  OUTPUT_STRIP_TRAILING_WHITESPACE)
>
>
> ==
>
> Anyhow, when I tried several types of your presentation, I got always 
> some errors. I do not know, if this is a bug or not, but I will write 
> them down here. Maybe some of the others could write something about it.
>
>
> *** First try ***
>
>> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio
>> 14.0/VC/vcvarsall.bat")
>> execute_process(COMMAND cmd /c "call ${HELLO1}" WORKING_DIRECTORY 
>> "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res 
>> OUTPUT_VARIABLE
>> _nvcc_out)
>> message("${_nvcc_out}")
>
> When I call these lines on a windows machine, I am getting the error
>
>> 'C:/Program' is not recognized as an internal or external command, 
>> operable program or batch file.
>
> *** Second try ***
>
> When I change the execute_process to this
>
>> execute_process(COMMAND cmd /c "call \"${HELLO1}\"" WORKING_DIRECTORY 
>> "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res 
>> OUTPUT_VARIABLE
>> _nvcc_out)
>
> then I am getting this error
>
>> '\"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat\"'
>> is not recognized as an internal or external command, operable 
>> program or batch file.
>
> So now, CMake / Batch recognizes the right path, but somehow there are 
> the characters \".
>
> *** Third try ***
>
> I changed the definition of the variable HELLO1 into (because of some 
> hints here
> https://superuser.com/questions/279008/how-do-i-escape-spaces-in-comma
> nd-line-in-windows-without-using-quotation-marks)
>
>> set(HELLO1 "C:/Program^ Files^ (x86)/Microsoft^ Visual^ Studio^
>> 14.0/VC/vcvarsall.bat")
>
> But here, I am also getting the error
>
>> 'C:/Program' is not recognized as an internal or external command, 
>> operable program or batch file.
>
> Even, when I double the carets ^^, then the same error occurs
>
>
> 2016-06-09 22:41 GMT+02:00 Adam Rankin :
>>
>> Hello all,
>>
>>
>>
>> I am trying to develop a execute_process command that will first load 
>> the env variables set by the appropriate vcvarsall, and then run a 
>> compile command. See here for my progress so far:
>>
>>
>>
>> set(cuda_generation_command cmd /c "\"call 
>> \"$ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat\" 
>> x86_amd64 && \"${CUDA_NVCC_EXECUTABLE}\"
>> \"${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu\" 
>> \"--run\"\"")
>>
>>
>>
>> execute_process( COMMAND ${cuda_generation_command}
>>
>>  WORKING_DIRECTORY
>> 

Re: [CMake] how to compile single source file with debug options?

[Sergey Spiridonov]

Hi Gonzalo

On 10/06/16 18:52, Gonzalo wrote:

>> We have big project with lots of libraries and applications. We want to
>> switch to cmake. Currently we use our own build system, which is derived
>> from tmake.
> Cmake handles all dependencies if you keep the CMakeFiles directory around.
> If you do and have a debug build, you can then just do:
> 
> touch file.c
> 
> and only that file will be recompiled and relinked.

I do release build, but I want single source file to be compiled in
debug mode, with "-O0 -DDEBUG" options instead of "-O3".

Of course, without recompiling whole directory.

-- 
Best regards, Sergey Spiridonov



-- 

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

Re: [CMake] how to compile single source file with debug options?

[Gonzalo]

El 10/06/16 a las 09:05, Sergey Spiridonov escribió:

Hello all,

We have big project with lots of libraries and applications. We want to
switch to cmake. Currently we use our own build system, which is derived
from tmake.

Cmake handles all dependencies if you keep the CMakeFiles directory around.
If you do and have a debug build, you can then just do:

touch file.c

and only that file will be recompiled and relinked.

--
Gonzalo Garramuño
ggarr...@gmail.com

--

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

Re: [cmake-developers] CMake daemon-mode

[Tobias Hunger]

Hi Brad,

On Thu, Jun 9, 2016 at 7:57 PM, Brad King  wrote:
> On 06/09/2016 09:27 AM, Brad King wrote:
>>> https://github.com/hunger/CMake/commit/bc060a44b6b2c2281ffe99815163ba02ec835dd6
>> Good. I need to review that one more deeply but should be able to integrate 
>> it.
>
> I split out some incremental commits toward that:
>
>  cmCommonTargetGenerator: De-duplicate CMAKE_BUILD_TYPE lookup
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de4ee088
>
>  cmLocalGenerator: Adopt GetFrameworkFlags method
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70d3bf85
>
>  cmLocalGenerator: Move GetFrameworkFlags implementation to private helper
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9613b96
>
> Please rebase on that (at least once it is in master).
>
> For the main change, please also move over AddFortranFlags, perhaps
> becoming cmLocalGenerator::GetFortranFlags.  The result should be
> that cmCommonTargetGenerator::GetFlags moves into the new
> cmLocalGenerator::GetTargetCompileFlags method except for the caching.
> That will preserve flag order for GetFlags.
>
> For the Xcode part of the changes, we cannot use the full
> GetTargetCompileFlags.  The reason is that for Xcode some of the
> flags, like the architecture settings, become .pbxproj file properties
> instead of raw flags.  It may be simplest to just drop that part of
> the change for now.  Or, we need to factor out an intermediate helper
> that can be shared by GetTargetCompileFlags and Xcode.

I did try to do the changes you requested. The branch is here:

https://github.com/hunger/CMake/commits/compileflags



Some comments on the individual commits (and a direct link):



This moves the fortran module directory creation:

https://github.com/hunger/CMake/commit/eb417fef8bd1c91041a211899a2a7984aa75774d



Next patch moves the AddFortranFlags code. This will need some careful
review, as it removes a
path conversion that were present in the original code (in two
places). I could just not figure out how
to convert in the new place.

https://github.com/hunger/CMake/commit/2d5f6c673cc8a39f8590acfc23d4a6d5af8900a7



Then I add the cmLocalGenerator::GetTargetCompileFlags method I want.

https://github.com/hunger/CMake/commit/9be6beddfe2c2eac6b61d572ee3e5131b0f0b30e



Finally I convert the Sublime generator over to the new code:

https://github.com/hunger/CMake/commit/deb0793a243c266aee00d4f6e07685a5268f3dae



As I said, the second one will need some special care during the
review. I did run all unit tests with all patches applied, and all
pass on my system.

Best Regards,
Tobias
-- 

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] Questions about coding conventions

[Tobias Hunger]

On Fr, 2016-06-10 at 16:34 +0200, Daniel Pfeifer wrote:
> If used consistently, it indicates that you are dealing with a member.
> I personally prefer `this->` over `m_`. With semantic syntax
> highlighting you probably don't need either of them. But then again,
> you often look at code that does not have semantic highlighting (eg.
> inside diffs).

So you optimize for teletype terminals and punish everybody that has invested in
new stuff like screens with *color* in the last couple of decades:-/

/me is trapped in 1995!

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] daemon-mode: Project structure

[Brad King]

On 06/10/2016 11:24 AM, Tobias Hunger wrote:
>> The cmGeneratorTarget::GetFullName method will give you the name of the
>> "main" file for a target.  Passing `implib = true` will give the DLL
>> import library path on platforms where IsDLLPlatform returns true.
> 
> I would have never found that!
> 
> I'll change the code to list both the main artefact and the implib (if
> applicable).

Oops, I meant to point you at cmGeneratorTarget::GetFullPath to get the
absolute paths with file names.

-Brad

-- 

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] daemon-mode: Project structure

[Tobias Hunger]

On Fr, 2016-06-10 at 10:41 -0400, Brad King wrote:
> On 06/10/2016 10:28 AM, Tobias Hunger wrote:
> > Any pointers on how to get to that information? Any example code that gets
> > the
> > artifact list?
> > 
> > I do not think this information is particularly worthwhile to add, but am
> > open
> > to change this.
> 
> An "artifactDirectory" field is not appropriate because there can be more
> than one artifact per target, and in different directories.  What is it
> that an IDE might want to do with this information?  If nothing, we could
> just drop it for now.

I need the path to executables that get built as well as directories that
libraries (dlls in windows) end up in, so that I can set up the environment for
the executables in such a way that they find their libraries.

> The cmGeneratorTarget::GetFullName method will give you the name of the
> "main" file for a target.  Passing `implib = true` will give the DLL
> import library path on platforms where IsDLLPlatform returns true.

I would have never found that!

I'll change the code to list both the main artefact and the implib (if
applicable).

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] Search lib32 on more platforms

[Brad King]

On 06/10/2016 10:11 AM, Daniel Scharrer wrote:
> This adss a global property FIND_LIBRARY_USE_LIB32_PATHS analogous to
> the FIND_LIBRARY_USE_LIB64_PATHS property,  fixing linking issues on
> multilib systems that use lib32 directories and either don't have lib
> symlinks or point lib to lib64.
> 
> Bug: https://public.kitware.com/Bug/view.php?id=11260

Very nice!  Applied with minor tweaks:

 Teach find_library and find_package to search lib32 paths (#11260)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=896ad251

Thanks,
-Brad

-- 

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-commits] CMake branch, next, updated. v3.6.0-rc1-230-g6d1e598

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  6d1e598aa41352087b2e113e05897820f566b881 (commit)
   via  896ad251de49f167f4ce3cbbcf9a6cce85a16681 (commit)
  from  6fc549fd0f5c1ad49aab7beb0c9a8ea90d7f1aed (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6d1e598aa41352087b2e113e05897820f566b881
commit 6d1e598aa41352087b2e113e05897820f566b881
Merge: 6fc549f 896ad25
Author: Brad King 
AuthorDate: Fri Jun 10 11:10:19 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 11:10:19 2016 -0400

Merge topic 'find-lib32' into next

896ad251 Teach find_library and find_package to search lib32 paths (#11260)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=896ad251de49f167f4ce3cbbcf9a6cce85a16681
commit 896ad251de49f167f4ce3cbbcf9a6cce85a16681
Author: Daniel Scharrer 
AuthorDate: Fri Jun 10 16:11:18 2016 +0200
Commit: Brad King 
CommitDate: Fri Jun 10 11:09:16 2016 -0400

Teach find_library and find_package to search lib32 paths (#11260)

Add a ``FIND_LIBRARY_USE_LIB32_PATHS`` global property analogous to the
``FIND_LIBRARY_USE_LIB64_PATHS`` property.  This helps find commands on
multilib systems that use ``lib32`` directories and either do not have
``lib`` symlinks or point ``lib`` to ``lib64``.

diff --git a/Help/command/find_library.rst b/Help/command/find_library.rst
index 31e6ec0..1eb50f7 100644
--- a/Help/command/find_library.rst
+++ b/Help/command/find_library.rst
@@ -49,6 +49,13 @@ path to the framework ``/A.framework``.  When a 
full path to a
 framework is used as a library, CMake will use a ``-framework A``, and a
 ``-F`` to link the framework to the target.
 
+If the :prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS` global property is set
+all search paths will be tested as normal, with ``32/`` appended, and
+with all matches of ``lib/`` replaced with ``lib32/``.  This property is
+automatically set for the platforms that are known to need it if at
+least one of the languages supported by the :command:`project` command
+is enabled.
+
 If the :prop_gbl:`FIND_LIBRARY_USE_LIB64_PATHS` global property is set
 all search paths will be tested as normal, with ``64/`` appended, and
 with all matches of ``lib/`` replaced with ``lib64/``.  This property is
diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index 3403dcd..3574b7f 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -24,6 +24,7 @@ Properties of Global Scope
/prop_gbl/DISABLED_FEATURES
/prop_gbl/ENABLED_FEATURES
/prop_gbl/ENABLED_LANGUAGES
+   /prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS
/prop_gbl/FIND_LIBRARY_USE_LIB64_PATHS
/prop_gbl/FIND_LIBRARY_USE_OPENBSD_VERSIONING
/prop_gbl/GLOBAL_DEPENDS_DEBUG_MODE
diff --git a/Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst 
b/Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst
new file mode 100644
index 000..ce18b65
--- /dev/null
+++ b/Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst
@@ -0,0 +1,10 @@
+FIND_LIBRARY_USE_LIB32_PATHS
+
+
+Whether the :command:`find_library` command should automatically search
+``lib32`` directories.
+
+``FIND_LIBRARY_USE_LIB32_PATHS`` is a boolean specifying whether the
+:command:`find_library` command should automatically search the ``lib32``
+variant of directories called ``lib`` in the search path when building 32-bit
+binaries.
diff --git a/Help/release/dev/find-lib32.rst b/Help/release/dev/find-lib32.rst
new file mode 100644
index 000..00818dc
--- /dev/null
+++ b/Help/release/dev/find-lib32.rst
@@ -0,0 +1,7 @@
+find-lib32
+--
+
+* The :command:`find_library` and :command:`find_package` commands learned
+  to search in ``lib32/`` directories when the build targets a 32-bit
+  architecture.  See the :prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS` global
+  property.
diff --git a/Modules/FindPkgConfig.cmake b/Modules/FindPkgConfig.cmake
index 644687c..33290c4 100644
--- a/Modules/FindPkgConfig.cmake
+++ b/Modules/FindPkgConfig.cmake
@@ -316,9 +316,13 @@ macro(_pkg_check_modules_internal _is_required _is_silent 
_no_cmake_path _no_cma
 list(APPEND _lib_dirs 
"lib/${CMAKE_LIBRARY_ARCHITECTURE}/pkgconfig")
   endif()
 else()
-  # not debian, chech the FIND_LIBRARY_USE_LIB64_PATHS property
+  # not debian, check the FIND_LIBRARY_USE_LIB32_PATHS and 
FIND_LIBRARY_USE_LIB64_PATHS properties
+  get_property(uselib32 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS)
+ 

[CMake] v140_clang_3_7 generator and multi processor compilation

[Luke.Mauldin]

I am using Cmake 3.6.0 RC1 with Visual Studio 2015 and the Clang May 2016 
update.  When I create a simple C++ project with Visual Studio 2015 and change 
the toolset to v140_clang_3_7, I have the option to set Multi Processor 
Compilation to "Yes".  When I do this, this setting is added in the .vcxproj 
file:
  
true
  

However, if I use Cmake to generate my project files using: "cmake .. -G 
"Visual Studio 14 2015 Win64" -T v140_clang_3_7", I cannot find a way to have 
the generated project file contain the UseMutliToolTask as shown above.  I have 
tried modifying CXX_FLAGS and other input variables but cannot figure it out.  
Can someone please help me?

Luke

-- 

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

Re: [cmake-developers] Update bash completion scripts

[Brad King]

On 06/10/2016 10:12 AM, Eric Noulard wrote:
>  Here you go.

Thanks.  I've revised the original series:

 bash-completion: Add cmake --help-manual
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f67afbdc

 bash-completion: Fix cmake --help-policy lookup
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=48cb388e

 bash-completion: Add ctest --help-{manual,module,policy,property,variable}
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b08cae9b

 bash-completion: Add cpack --help-{manual,module,policy,property}
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=797c3c54

-Brad

-- 

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-commits] CMake branch, next, updated. v3.6.0-rc1-228-g6fc549f

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  6fc549fd0f5c1ad49aab7beb0c9a8ea90d7f1aed (commit)
   via  797c3c54e835e5c5131f38036aca61b0dae02260 (commit)
   via  b08cae9b0e9bad96e4615c1bbf9bbd00802e6985 (commit)
   via  48cb388ead09794aae01328d83620e10a8f7636b (commit)
  from  78dddcaf7e33e7d70516901699c7315ed53e7eca (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6fc549fd0f5c1ad49aab7beb0c9a8ea90d7f1aed
commit 6fc549fd0f5c1ad49aab7beb0c9a8ea90d7f1aed
Merge: 78dddca 797c3c5
Author: Brad King 
AuthorDate: Fri Jun 10 10:47:28 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 10:47:28 2016 -0400

Merge topic 'bash-completion' into next

797c3c54 bash-completion: Add cpack --help-{manual,module,policy,property}
b08cae9b bash-completion: Add ctest 
--help-{manual,module,policy,property,variable}
48cb388e bash-completion: Fix cmake --help-policy lookup


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=797c3c54e835e5c5131f38036aca61b0dae02260
commit 797c3c54e835e5c5131f38036aca61b0dae02260
Author: Eric NOULARD 
AuthorDate: Fri Jun 10 15:28:05 2016 +0200
Commit: Brad King 
CommitDate: Fri Jun 10 10:46:33 2016 -0400

bash-completion: Add cpack --help-{manual,module,policy,property}

diff --git a/Auxiliary/bash-completion/cpack b/Auxiliary/bash-completion/cpack
index 05e0e93..cf5751f 100644
--- a/Auxiliary/bash-completion/cpack
+++ b/Auxiliary/bash-completion/cpack
@@ -48,6 +48,26 @@ _cpack()
 grep -v "^cpack version " )' -- "$cur" ) )
 return
 ;;
+--help-manual)
+COMPREPLY=( $( compgen -W '$( cpack --help-manual-list 2>/dev/null|
+grep -v "^cpack version " | sed -e "s/([0-9])$//" )' -- "$cur" 
) )
+return
+;;
+--help-module)
+COMPREPLY=( $( compgen -W '$( cpack --help-module-list 2>/dev/null|
+grep -v "^cpack version " )' -- "$cur" ) )
+return
+;;
+--help-policy)
+COMPREPLY=( $( compgen -W '$( cpack --help-policy-list 2>/dev/null 
|
+grep -v "^cpack version " )' -- "$cur" ) )
+return
+;;
+--help-property)
+COMPREPLY=( $( compgen -W '$( cpack --help-property-list \
+2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )
+return
+;;
 --help-variable)
 COMPREPLY=( $( compgen -W '$( cpack --help-variable-list \
 2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b08cae9b0e9bad96e4615c1bbf9bbd00802e6985
commit b08cae9b0e9bad96e4615c1bbf9bbd00802e6985
Author: Eric NOULARD 
AuthorDate: Fri Jun 10 15:28:05 2016 +0200
Commit: Brad King 
CommitDate: Fri Jun 10 10:46:19 2016 -0400

bash-completion: Add ctest --help-{manual,module,policy,property,variable}

diff --git a/Auxiliary/bash-completion/ctest b/Auxiliary/bash-completion/ctest
index 387672a..49343bb 100644
--- a/Auxiliary/bash-completion/ctest
+++ b/Auxiliary/bash-completion/ctest
@@ -72,11 +72,37 @@ _ctest()
 COMPREPLY=( $( compgen -W '0 1' -- "$cur" ) )
 return
 ;;
+
 --help-command)
 COMPREPLY=( $( compgen -W '$( ctest --help-command-list 
2>/dev/null|
 grep -v "^ctest version " )' -- "$cur" ) )
 return
 ;;
+--help-manual)
+COMPREPLY=( $( compgen -W '$( ctest --help-manual-list 2>/dev/null|
+grep -v "^ctest version " | sed -e "s/([0-9])$//" )' -- "$cur" 
) )
+return
+;;
+--help-module)
+COMPREPLY=( $( compgen -W '$( ctest --help-module-list 2>/dev/null|
+grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
+--help-policy)
+COMPREPLY=( $( compgen -W '$( ctest --help-policy-list 2>/dev/null 
|
+grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
+--help-property)
+COMPREPLY=( $( compgen -W '$( ctest --help-property-list \
+2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
+--help-variable)
+COMPREPLY=( $( compgen -W '$( ctest --help-variable-list \
+2>/dev/null | grep -v "^ctest version " )' 

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-224-g78dddca

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  78dddcaf7e33e7d70516901699c7315ed53e7eca (commit)
   via  ecc7973fdaa488110cc96cd8377b9fd33ba35185 (commit)
  from  74ee264c0bcd5f5a003cc8e3ebf8f1b38e2ac3e5 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78dddcaf7e33e7d70516901699c7315ed53e7eca
commit 78dddcaf7e33e7d70516901699c7315ed53e7eca
Merge: 74ee264 ecc7973
Author: Brad King 
AuthorDate: Fri Jun 10 10:47:17 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 10:47:17 2016 -0400

Merge topic 'bash-completion' into next

ecc7973f Update --help-policy completion with comtemporary cmake tools.


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ecc7973fdaa488110cc96cd8377b9fd33ba35185
commit ecc7973fdaa488110cc96cd8377b9fd33ba35185
Author: Eric NOULARD 
AuthorDate: Fri Jun 10 16:07:06 2016 +0200
Commit: Brad King 
CommitDate: Fri Jun 10 10:44:24 2016 -0400

Update --help-policy completion with comtemporary cmake tools.

This was a leftover from previous patch.

diff --git a/Auxiliary/bash-completion/cmake b/Auxiliary/bash-completion/cmake
index 6997d47..6061129 100644
--- a/Auxiliary/bash-completion/cmake
+++ b/Auxiliary/bash-completion/cmake
@@ -132,8 +132,8 @@ _cmake()
 return
 ;;
  --help-policy)
-COMPREPLY=( $( compgen -W '$( cmake --help-policies 2>/dev/null |
-grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+COMPREPLY=( $( compgen -W '$( cmake --help-policy-list 2>/dev/null 
|
+grep -v "^cmake version " )' -- "$cur" ) )
 return
 ;;
  --help-property)
diff --git a/Auxiliary/bash-completion/cpack b/Auxiliary/bash-completion/cpack
index b30df8a..cf5751f 100644
--- a/Auxiliary/bash-completion/cpack
+++ b/Auxiliary/bash-completion/cpack
@@ -59,8 +59,8 @@ _cpack()
 return
 ;;
 --help-policy)
-COMPREPLY=( $( compgen -W '$( cpack --help-policies 2>/dev/null |
-grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+COMPREPLY=( $( compgen -W '$( cpack --help-policy-list 2>/dev/null 
|
+grep -v "^cpack version " )' -- "$cur" ) )
 return
 ;;
 --help-property)
diff --git a/Auxiliary/bash-completion/ctest b/Auxiliary/bash-completion/ctest
index d15cc98..49343bb 100644
--- a/Auxiliary/bash-completion/ctest
+++ b/Auxiliary/bash-completion/ctest
@@ -89,8 +89,8 @@ _ctest()
 return
 ;;
 --help-policy)
-COMPREPLY=( $( compgen -W '$( ctest --help-policies 2>/dev/null |
-grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+COMPREPLY=( $( compgen -W '$( ctest --help-policy-list 2>/dev/null 
|
+grep -v "^ctest version " )' -- "$cur" ) )
 return
 ;;
 --help-property)

---

Summary of changes:
 Auxiliary/bash-completion/cmake |4 ++--
 Auxiliary/bash-completion/cpack |4 ++--
 Auxiliary/bash-completion/ctest |4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] daemon-mode: Project structure

[Brad King]

On 06/10/2016 10:28 AM, Tobias Hunger wrote:
> Any pointers on how to get to that information? Any example code that gets the
> artifact list?
> 
> I do not think this information is particularly worthwhile to add, but am open
> to change this.

An "artifactDirectory" field is not appropriate because there can be more
than one artifact per target, and in different directories.  What is it
that an IDE might want to do with this information?  If nothing, we could
just drop it for now.

The cmGeneratorTarget::GetFullName method will give you the name of the
"main" file for a target.  Passing `implib = true` will give the DLL
import library path on platforms where IsDLLPlatform returns true.

-Brad

-- 

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] Questions about coding conventions

[Brad King]

On 06/10/2016 10:34 AM, Daniel Pfeifer wrote:
>> May I asked why "this->" is used so often?
> 
> If used consistently, it indicates that you are dealing with a member.
> I personally prefer `this->` over `m_`. ...
> you often look at code that does not have semantic highlighting (eg.
> inside diffs).

Yes, and this has been part of our coding convention from the beginning
of CMake.

-Brad

-- 

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] Questions about coding conventions

[Daniel Pfeifer]

On Fri, Jun 10, 2016 at 4:16 PM, Tobias Hunger  wrote:
> On Fr, 2016-06-10 at 15:30 +0200, Daniel Pfeifer wrote:
>> Naming conventions: Classes are named  cmLikeThis. Member functions
>> and member variables are named LikeThis. Local variables are named
>> likeThis. Members are always accessed with `this->`. So far it is
>> pretty consistent. But how to name free functions and macros? I have
>> seen all kinds of variations.
>
> May I asked why "this->" is used so often? I find it totally annoying to skip
> this line noise all the time and I never encountered this convention before.

If used consistently, it indicates that you are dealing with a member.
I personally prefer `this->` over `m_`. With semantic syntax
highlighting you probably don't need either of them. But then again,
you often look at code that does not have semantic highlighting (eg.
inside diffs).
-- 

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-commits] CMake branch, next, updated. v3.6.0-rc1-222-g74ee264

[Bill Hoffman]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  74ee264c0bcd5f5a003cc8e3ebf8f1b38e2ac3e5 (commit)
   via  89ae032fb010197715d8308697987421083d604a (commit)
   via  a8942cd2b555f72c39fdac6df54ecff52d58e975 (commit)
   via  24d7e3ea16e7cb687010c03a35621053f8ed74fb (commit)
  from  c0253804aed4f21ba5b9dede973a59bc65f65e47 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=74ee264c0bcd5f5a003cc8e3ebf8f1b38e2ac3e5
commit 74ee264c0bcd5f5a003cc8e3ebf8f1b38e2ac3e5
Merge: c025380 89ae032
Author: Bill Hoffman 
AuthorDate: Fri Jun 10 10:31:43 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 10:31:43 2016 -0400

Merge topic 'link_what_you_use' into next

89ae032f use inline markup for rst files and call ldd directly
a8942cd2 add documentation for LINK_WHAT_YOU_USE
24d7e3ea Add support for ldd -u -r as link what you use


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89ae032fb010197715d8308697987421083d604a
commit 89ae032fb010197715d8308697987421083d604a
Author: Bill Hoffman 
AuthorDate: Thu Jun 9 17:12:13 2016 -0400
Commit: Bill Hoffman 
CommitDate: Thu Jun 9 17:12:13 2016 -0400

use inline markup for rst files and call ldd directly

diff --git a/Help/prop_tgt/LINK_WHAT_YOU_USE.rst 
b/Help/prop_tgt/LINK_WHAT_YOU_USE.rst
index 76bfafa..32d6edb 100644
--- a/Help/prop_tgt/LINK_WHAT_YOU_USE.rst
+++ b/Help/prop_tgt/LINK_WHAT_YOU_USE.rst
@@ -1,10 +1,10 @@
 LINK_WHAT_YOU_USE
 ---
 
-This is a boolean option that when set to TRUE will automatically run
-ldd -r -u on the target after it is linked. In addition, the linker flag
--Wl,--no-as-needed will be passed to the target with the link command so that
-all libraries specified on the command line will be linked into the
+This is a boolean option that when set to ``TRUE`` will automatically run
+``ldd -r -u`` on the target after it is linked. In addition, the linker flag
+``-Wl,--no-as-needed`` will be passed to the target with the link command so
+that all libraries specified on the command line will be linked into the
 target. This will result in the link producing a list of libraries that
 provide no symbols used by this target but are being linked to it.
 This is only applicable to executable and shared library targets and
diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt
index 4be81e9..8fb91a9 100644
--- a/Tests/RunCMake/CMakeLists.txt
+++ b/Tests/RunCMake/CMakeLists.txt
@@ -307,9 +307,8 @@ if(CMAKE_OSX_ARCHITECTURES AND XCODE AND NOT 
"${XCODE_VERSION}" MATCHES "^[^12]"
 endif()
 
 if("${CMAKE_GENERATOR}" MATCHES "Make|Ninja")
-  find_program(LDD_PATH ldd)
-  if(UNIX AND LDD_PATH)
-execute_process(COMMAND ${LDD_PATH} --help
+  if(UNIX)
+execute_process(COMMAND ldd --help
   OUTPUT_VARIABLE LDD_HELP)
 if("${LDD_HELP}" MATCHES
 "(-r, --function-relocs.*process data and function relocations|-u, 
--unused.*print unused direct dependencies)")

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a8942cd2b555f72c39fdac6df54ecff52d58e975
commit a8942cd2b555f72c39fdac6df54ecff52d58e975
Author: Bill Hoffman 
AuthorDate: Thu Jun 9 16:32:24 2016 -0400
Commit: Bill Hoffman 
CommitDate: Thu Jun 9 16:32:24 2016 -0400

add documentation for LINK_WHAT_YOU_USE

diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index 3403dcd..6a7560a 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -217,6 +217,7 @@ Properties on Targets
/prop_tgt/LINK_LIBRARIES
/prop_tgt/LINK_SEARCH_END_STATIC
/prop_tgt/LINK_SEARCH_START_STATIC
+   /prop_tgt/LINK_WHAT_YOU_USE
/prop_tgt/LOCATION_CONFIG
/prop_tgt/LOCATION
/prop_tgt/MACOSX_BUNDLE_INFO_PLIST
diff --git a/Help/manual/cmake-variables.7.rst 
b/Help/manual/cmake-variables.7.rst
index 85b8eae..36d00dc 100644
--- a/Help/manual/cmake-variables.7.rst
+++ b/Help/manual/cmake-variables.7.rst
@@ -275,6 +275,7 @@ Variables that Control the Build
/variable/CMAKE_LINK_INTERFACE_LIBRARIES
/variable/CMAKE_LINK_LIBRARY_FILE_FLAG
/variable/CMAKE_LINK_LIBRARY_FLAG
+   /variable/CMAKE_LINK_WHAT_YOU_USE
/variable/CMAKE_MACOSX_BUNDLE
/variable/CMAKE_MACOSX_RPATH
/variable/CMAKE_MAP_IMPORTED_CONFIG_CONFIG
diff --git a/Help/prop_tgt/LINK_WHAT_YOU_USE.rst 
b/Help/prop_tgt/LINK_WHAT_YOU_USE.rst
new file mode 100644
index 000..76bfafa
--- /dev/null
+++ 

Re: [cmake-developers] daemon-mode: Project structure

[Tobias Hunger]

On Fr, 2016-06-10 at 10:06 -0400, Brad King wrote:
> On 06/09/2016 11:52 AM, Tobias Hunger wrote:
> >   [== CMake MetaMagic ==[
> 
> What is the purpose of this non-json wrapper in the content?
> Just part of the message protocol so that readers do not have
> to parse the json to know when the end of the message is reached
> (balanced with the start)?

At this time the daemon-mode accepts commands via stdin and responds via stdout.
The problem is that cmake will still happily send lots of output to stdout...
and in theory could even accept input from stdin. So Stephen added these CMake
MetaMagic around the JSON input/output.

It is pretty convenient for debugging and testing and we can always ask libuv to
communicate via a socket instead if that becomes necessary.

> I'd prefer a more descriptive name than "MetaMagic".

Please feel free to suggest whatever you prefer. I have no opinion on these
strings, as long as they are fixed:-)

> * What information to store about library build locations? Or maybe list
> > build
> >    artifacts instead?
> 
> I prefer the latter as I've mentioned elsewhere in the related threads.

Any pointers on how to get to that information? Any example code that gets the
artifact list?

I do not think this information is particularly worthwhile to add, but am open
to change this.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] [PATCH] Search lib32 on more platforms

[Daniel Scharrer]

This adss a global property FIND_LIBRARY_USE_LIB32_PATHS analogous to
the FIND_LIBRARY_USE_LIB64_PATHS property,  fixing linking issues on
multilib systems that use lib32 directories and either don't have lib
symlinks or point lib to lib64.

Bug: https://public.kitware.com/Bug/view.php?id=11260
---
 Help/command/find_library.rst |  7 +++
 Help/manual/cmake-properties.7.rst|  1 +
 Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst|  9 +
 Modules/FindPkgConfig.cmake   |  8 ++--
 Modules/Platform/Linux.cmake  |  3 ++-
 Modules/Platform/OpenBSD.cmake|  1 +
 Modules/Platform/UnixPaths.cmake  |  3 ++-
 Source/cmFindLibraryCommand.cxx   |  9 -
 Source/cmFindPackageCommand.cxx   | 11 +++
 Source/cmFindPackageCommand.h |  1 +
 Source/cmMakefile.cxx |  8 
 Source/cmMakefile.h   |  3 +++
 Tests/CMakeOnly/find_library/CMakeLists.txt   |  7 +++
 Tests/CMakeOnly/find_library/lib/32/libtest5.a|  0
 Tests/CMakeOnly/find_library/lib/A/lib32/libtest3.a   |  0
 Tests/CMakeOnly/find_library/lib32/A/lib/libtest2.a   |  0
 Tests/CMakeOnly/find_library/lib32/A/lib32/libtest4.a |  0
 Tests/CMakeOnly/find_library/lib32/A/libtest4.a   |  0
 Tests/CMakeOnly/find_library/lib32/libtest4.a |  0
 .../FindPkgConfig/FindPkgConfig_CMAKE_APPBUNDLE_PATH.cmake| 11 ---
 .../FindPkgConfig/FindPkgConfig_CMAKE_FRAMEWORK_PATH.cmake| 11 ---
 .../FindPkgConfig/FindPkgConfig_NO_PKGCONFIG_PATH.cmake   |  3 ---
 .../RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH.cmake | 11 ---
 ...ndPkgConfig_PKGCONFIG_PATH_NO_CMAKE_ENVIRONMENT_PATH.cmake | 11 ---
 .../FindPkgConfig_PKGCONFIG_PATH_NO_CMAKE_PATH.cmake  | 11 ---
 .../FindPkgConfig/pc-bar/lib32/pkgconfig/.placeholder |  0
 .../FindPkgConfig/pc-foo/lib32/pkgconfig/.placeholder |  0
 27 files changed, 102 insertions(+), 27 deletions(-)
 create mode 100644 Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst
 create mode 100644 Tests/CMakeOnly/find_library/lib/32/libtest5.a
 create mode 100644 Tests/CMakeOnly/find_library/lib/A/lib32/libtest3.a
 create mode 100644 Tests/CMakeOnly/find_library/lib32/A/lib/libtest2.a
 create mode 100644 Tests/CMakeOnly/find_library/lib32/A/lib32/libtest4.a
 create mode 100644 Tests/CMakeOnly/find_library/lib32/A/libtest4.a
 create mode 100644 Tests/CMakeOnly/find_library/lib32/libtest4.a
 create mode 100644 
Tests/RunCMake/FindPkgConfig/pc-bar/lib32/pkgconfig/.placeholder
 create mode 100644 
Tests/RunCMake/FindPkgConfig/pc-foo/lib32/pkgconfig/.placeholder

diff --git a/Help/command/find_library.rst b/Help/command/find_library.rst
index 31e6ec0..1eb50f7 100644
--- a/Help/command/find_library.rst
+++ b/Help/command/find_library.rst
@@ -49,6 +49,13 @@ path to the framework ``/A.framework``.  When a 
full path to a
 framework is used as a library, CMake will use a ``-framework A``, and a
 ``-F`` to link the framework to the target.
 
+If the :prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS` global property is set
+all search paths will be tested as normal, with ``32/`` appended, and
+with all matches of ``lib/`` replaced with ``lib32/``.  This property is
+automatically set for the platforms that are known to need it if at
+least one of the languages supported by the :command:`project` command
+is enabled.
+
 If the :prop_gbl:`FIND_LIBRARY_USE_LIB64_PATHS` global property is set
 all search paths will be tested as normal, with ``64/`` appended, and
 with all matches of ``lib/`` replaced with ``lib64/``.  This property is
diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index 3403dcd..3574b7f 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -24,6 +24,7 @@ Properties of Global Scope
/prop_gbl/DISABLED_FEATURES
/prop_gbl/ENABLED_FEATURES
/prop_gbl/ENABLED_LANGUAGES
+   /prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS
/prop_gbl/FIND_LIBRARY_USE_LIB64_PATHS
/prop_gbl/FIND_LIBRARY_USE_OPENBSD_VERSIONING
/prop_gbl/GLOBAL_DEPENDS_DEBUG_MODE
diff --git a/Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst 
b/Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst
new file mode 100644
index 000..3911e49
--- /dev/null
+++ b/Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst
@@ -0,0 +1,9 @@
+FIND_LIBRARY_USE_LIB32_PATHS
+
+
+Whether FIND_LIBRARY should automatically search lib32 directories.
+
+FIND_LIBRARY_USE_LIB32_PATHS is a boolean specifying whether the
+FIND_LIBRARY command should automatically search the lib32 variant of

Re: [cmake-developers] Questions about coding conventions

[Tobias Hunger]

On Fr, 2016-06-10 at 15:30 +0200, Daniel Pfeifer wrote:
> Naming conventions: Classes are named  cmLikeThis. Member functions
> and member variables are named LikeThis. Local variables are named
> likeThis. Members are always accessed with `this->`. So far it is
> pretty consistent. But how to name free functions and macros? I have
> seen all kinds of variations.

May I asked why "this->" is used so often? I find it totally annoying to skip
this line noise all the time and I never encountered this convention before.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] Update bash completion scripts

[Eric Noulard]

2016-06-10 15:56 GMT+02:00 Brad King :

> On 06/10/2016 09:31 AM, Eric Noulard wrote:
> > Here comes an update of the bash completion scripts.
> > All of them now handle the same set of --help-xxx options
> > the handling of --help-manual has been added.
>
> Thanks, applied:
>
>  bash-completion: Add cmake --help-manual
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f67afbdc
>
>  bash-completion: Add ctest --help-{manual,module,policy,property,variable}
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8178a77
>
>  bash-completion: Add cpack --help-{manual,module,policy,property}
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eacb75de
>
> > + --help-policy)
> > +COMPREPLY=( $( compgen -W '$( ctest --help-policies
> 2>/dev/null |
> > +grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
> > +return
> > +;;
>
> Does this actually work?  IIRC older CMake versions did not
> have `--help-policy-list` so the `--help-policies` hack was
> used.  However, I don't know if the output format of the
> latter will be matched by the `grep` anymore.
>


You are right this part was obsolete.
To be honest I did not test the policy completion :-(


>
> If needed, please post a follow-up patch to fix policy completion
> for cmake, ctest, and cpack.
>

 Here you go.


-- 
Eric
From 003e68e5ef1e89036313b63bccd571a683894493 Mon Sep 17 00:00:00 2001
From: Eric NOULARD 
Date: Fri, 10 Jun 2016 16:07:06 +0200
Subject: [PATCH 2/2] Update --help-policy completion with comtemporary cmake
 tools.

This was a leftover from previous patch.
---
 Auxiliary/bash-completion/cmake | 4 ++--
 Auxiliary/bash-completion/cpack | 4 ++--
 Auxiliary/bash-completion/ctest | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Auxiliary/bash-completion/cmake b/Auxiliary/bash-completion/cmake
index 6997d47..6061129 100644
--- a/Auxiliary/bash-completion/cmake
+++ b/Auxiliary/bash-completion/cmake
@@ -132,8 +132,8 @@ _cmake()
 return
 ;;
  --help-policy)
-COMPREPLY=( $( compgen -W '$( cmake --help-policies 2>/dev/null |
-grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+COMPREPLY=( $( compgen -W '$( cmake --help-policy-list 2>/dev/null |
+grep -v "^cmake version " )' -- "$cur" ) )
 return
 ;;
  --help-property)
diff --git a/Auxiliary/bash-completion/cpack b/Auxiliary/bash-completion/cpack
index 8f14a72..be29528 100644
--- a/Auxiliary/bash-completion/cpack
+++ b/Auxiliary/bash-completion/cpack
@@ -59,8 +59,8 @@ _cpack()
 return
 ;;
  --help-policy)
-COMPREPLY=( $( compgen -W '$( cpack --help-policies 2>/dev/null |
-grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+COMPREPLY=( $( compgen -W '$( cpack --help-policy-list 2>/dev/null |
+grep -v "^cpack version " )' -- "$cur" ) )
 return
 ;;
  --help-property)
diff --git a/Auxiliary/bash-completion/ctest b/Auxiliary/bash-completion/ctest
index de8fde1..71f47ba 100644
--- a/Auxiliary/bash-completion/ctest
+++ b/Auxiliary/bash-completion/ctest
@@ -89,8 +89,8 @@ _ctest()
 return
 ;;
  --help-policy)
-COMPREPLY=( $( compgen -W '$( ctest --help-policies 2>/dev/null |
-grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+COMPREPLY=( $( compgen -W '$( ctest --help-policy-list 2>/dev/null |
+grep -v "^ctest version " )' -- "$cur" ) )
 return
 ;;
  --help-property)
-- 
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

Re: [cmake-developers] daemon-mode: Project structure

[Brad King]

On 06/09/2016 11:52 AM, Tobias Hunger wrote:
>   [== CMake MetaMagic ==[

What is the purpose of this non-json wrapper in the content?
Just part of the message protocol so that readers do not have
to parse the json to know when the end of the message is reached
(balanced with the start)?

I'd prefer a more descriptive name than "MetaMagic".

>   "artifactDirectory":"/tmp/cmake/Source/CursesDialog/form",

See below.

>   "fileGroups":

Good.

> Output size is ~77KiB for the cmake project in raw JSON format. This is much
> smaller than before, due to the GLOBAL_TARGETs being gone.

Good.

>  * What information to store about library build locations? Or maybe list 
> build
>artifacts instead?

I prefer the latter as I've mentioned elsewhere in the related threads.

Thanks,
-Brad

-- 

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-commits] CMake branch, master, updated. v3.6.0-rc1-108-gc5d71b2

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  c5d71b28ec2682ec160dd35015e90dd5b81a5605 (commit)
   via  cc7e9d1d90b7e0906149613bddd94895160c8629 (commit)
   via  b55039ce5baeb76f0ad9599ceb85ae65bc20b2d7 (commit)
   via  fb30b1a2822a43a26368da8245d107c347526b04 (commit)
  from  98aafb2ad64daa0617b3a71ec61f692d5aa205ce (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.6.0-rc1-14-gcc7e9d1

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  cc7e9d1d90b7e0906149613bddd94895160c8629 (commit)
   via  f28401554af8fe48994b0c08668f0c1408708fe1 (commit)
   via  b55039ce5baeb76f0ad9599ceb85ae65bc20b2d7 (commit)
   via  1b18180ed4a808f706c4df2f03826e7e9804487b (commit)
   via  558e4d1ed64a02f53592403158e0549bbcee98f1 (commit)
   via  fb30b1a2822a43a26368da8245d107c347526b04 (commit)
   via  dbc9f73d0e9ed5fd8a2a0e64e17d81f860643efd (commit)
  from  cd1f0a824e84f4d7f37fb526528e1cfb04d5c250 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Help/command/ctest_update.rst |4 
 Help/manual/ctest.1.rst   |5 +
 Source/QtDialog/CMakeSetup.cxx|   34 +
 Utilities/cmlibarchive/CMakeLists.txt |1 +
 4 files changed, 44 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-218-gc025380

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  c0253804aed4f21ba5b9dede973a59bc65f65e47 (commit)
   via  c5d71b28ec2682ec160dd35015e90dd5b81a5605 (commit)
   via  cc7e9d1d90b7e0906149613bddd94895160c8629 (commit)
   via  b55039ce5baeb76f0ad9599ceb85ae65bc20b2d7 (commit)
   via  fb30b1a2822a43a26368da8245d107c347526b04 (commit)
  from  a7791154ed2f30a0bf12eff52617a95c54e9b0e0 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c0253804aed4f21ba5b9dede973a59bc65f65e47
commit c0253804aed4f21ba5b9dede973a59bc65f65e47
Merge: a779115 c5d71b2
Author: Brad King 
AuthorDate: Fri Jun 10 09:57:37 2016 -0400
Commit: Brad King 
CommitDate: Fri Jun 10 09:57:37 2016 -0400

Merge branch 'master' into next


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] Update bash completion scripts

[Brad King]

On 06/10/2016 09:31 AM, Eric Noulard wrote:
> Here comes an update of the bash completion scripts.
> All of them now handle the same set of --help-xxx options
> the handling of --help-manual has been added.

Thanks, applied:

 bash-completion: Add cmake --help-manual
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f67afbdc

 bash-completion: Add ctest --help-{manual,module,policy,property,variable}
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8178a77

 bash-completion: Add cpack --help-{manual,module,policy,property}
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eacb75de

> + --help-policy)
> +COMPREPLY=( $( compgen -W '$( ctest --help-policies 2>/dev/null |
> +grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
> +return
> +;;

Does this actually work?  IIRC older CMake versions did not
have `--help-policy-list` so the `--help-policies` hack was
used.  However, I don't know if the output format of the
latter will be matched by the `grep` anymore.

If needed, please post a follow-up patch to fix policy completion
for cmake, ctest, and cpack.

Thanks,
-Brad

-- 

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-commits] CMake branch, next, updated. v3.6.0-rc1-213-ga779115

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  a7791154ed2f30a0bf12eff52617a95c54e9b0e0 (commit)
   via  eacb75de484b3a8cc3be37d99f2489502270206e (commit)
   via  c8178a7772e103df57aea944d01d77b08c13bbb4 (commit)
   via  f67afbdc4a97c0b0305763e714d22dd04ead16f3 (commit)
  from  8c63b7000d98ed82f83706253a0c73d19b9c354b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7791154ed2f30a0bf12eff52617a95c54e9b0e0
commit a7791154ed2f30a0bf12eff52617a95c54e9b0e0
Merge: 8c63b70 eacb75d
Author: Brad King 
AuthorDate: Fri Jun 10 09:54:39 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 09:54:39 2016 -0400

Merge topic 'bash-completion' into next

eacb75de bash-completion: Add cpack --help-{manual,module,policy,property}
c8178a77 bash-completion: Add ctest 
--help-{manual,module,policy,property,variable}
f67afbdc bash-completion: Add cmake --help-manual


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eacb75de484b3a8cc3be37d99f2489502270206e
commit eacb75de484b3a8cc3be37d99f2489502270206e
Author: Eric NOULARD 
AuthorDate: Fri Jun 10 15:28:05 2016 +0200
Commit: Brad King 
CommitDate: Fri Jun 10 09:54:29 2016 -0400

bash-completion: Add cpack --help-{manual,module,policy,property}

diff --git a/Auxiliary/bash-completion/cpack b/Auxiliary/bash-completion/cpack
index 05e0e93..b30df8a 100644
--- a/Auxiliary/bash-completion/cpack
+++ b/Auxiliary/bash-completion/cpack
@@ -48,6 +48,26 @@ _cpack()
 grep -v "^cpack version " )' -- "$cur" ) )
 return
 ;;
+--help-manual)
+COMPREPLY=( $( compgen -W '$( cpack --help-manual-list 2>/dev/null|
+grep -v "^cpack version " | sed -e "s/([0-9])$//" )' -- "$cur" 
) )
+return
+;;
+--help-module)
+COMPREPLY=( $( compgen -W '$( cpack --help-module-list 2>/dev/null|
+grep -v "^cpack version " )' -- "$cur" ) )
+return
+;;
+--help-policy)
+COMPREPLY=( $( compgen -W '$( cpack --help-policies 2>/dev/null |
+grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+return
+;;
+--help-property)
+COMPREPLY=( $( compgen -W '$( cpack --help-property-list \
+2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )
+return
+;;
 --help-variable)
 COMPREPLY=( $( compgen -W '$( cpack --help-variable-list \
 2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8178a7772e103df57aea944d01d77b08c13bbb4
commit c8178a7772e103df57aea944d01d77b08c13bbb4
Author: Eric NOULARD 
AuthorDate: Fri Jun 10 15:28:05 2016 +0200
Commit: Brad King 
CommitDate: Fri Jun 10 09:54:29 2016 -0400

bash-completion: Add ctest --help-{manual,module,policy,property,variable}

diff --git a/Auxiliary/bash-completion/ctest b/Auxiliary/bash-completion/ctest
index 387672a..d15cc98 100644
--- a/Auxiliary/bash-completion/ctest
+++ b/Auxiliary/bash-completion/ctest
@@ -72,11 +72,37 @@ _ctest()
 COMPREPLY=( $( compgen -W '0 1' -- "$cur" ) )
 return
 ;;
+
 --help-command)
 COMPREPLY=( $( compgen -W '$( ctest --help-command-list 
2>/dev/null|
 grep -v "^ctest version " )' -- "$cur" ) )
 return
 ;;
+--help-manual)
+COMPREPLY=( $( compgen -W '$( ctest --help-manual-list 2>/dev/null|
+grep -v "^ctest version " | sed -e "s/([0-9])$//" )' -- "$cur" 
) )
+return
+;;
+--help-module)
+COMPREPLY=( $( compgen -W '$( ctest --help-module-list 2>/dev/null|
+grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
+--help-policy)
+COMPREPLY=( $( compgen -W '$( ctest --help-policies 2>/dev/null |
+grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+return
+;;
+--help-property)
+COMPREPLY=( $( compgen -W '$( ctest --help-property-list \
+2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
+--help-variable)
+COMPREPLY=( $( compgen -W '$( ctest --help-variable-list \
+2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-209-g8c63b70

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  8c63b7000d98ed82f83706253a0c73d19b9c354b (commit)
   via  dc7d397fe23dcf3dc6195af25da3bdb5f03dffa8 (commit)
   via  abdb88e7f742246be27bd4c13dbe72eef983d986 (commit)
   via  846d2876bb6ad0345f77660ea6154e2af8efbdde (commit)
  from  ceb8b8371ad2426dec35210e0de96fda69bc6c9a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c63b7000d98ed82f83706253a0c73d19b9c354b
commit 8c63b7000d98ed82f83706253a0c73d19b9c354b
Merge: ceb8b83 dc7d397
Author: Brad King 
AuthorDate: Fri Jun 10 09:53:34 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 09:53:34 2016 -0400

Merge topic 'bash-completion' into next

dc7d397f bash-completion: Add cpack --help-{manual,module,policy,property}
abdb88e7 bash-completion: Add ctest 
--help-{manual,module,policy,property,variable}
846d2876 bash-completion: Add cmake --help-manual


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dc7d397fe23dcf3dc6195af25da3bdb5f03dffa8
commit dc7d397fe23dcf3dc6195af25da3bdb5f03dffa8
Author: Eric NOULARD 
AuthorDate: Fri Jun 10 15:28:05 2016 +0200
Commit: Brad King 
CommitDate: Fri Jun 10 09:50:21 2016 -0400

bash-completion: Add cpack --help-{manual,module,policy,property}

diff --git a/Auxiliary/bash-completion/cpack b/Auxiliary/bash-completion/cpack
index 05e0e93..b30df8a 100644
--- a/Auxiliary/bash-completion/cpack
+++ b/Auxiliary/bash-completion/cpack
@@ -48,6 +48,26 @@ _cpack()
 grep -v "^cpack version " )' -- "$cur" ) )
 return
 ;;
+--help-manual)
+COMPREPLY=( $( compgen -W '$( cpack --help-manual-list 2>/dev/null|
+grep -v "^cpack version " | sed -e "s/([0-9])$//" )' -- "$cur" 
) )
+return
+;;
+--help-module)
+COMPREPLY=( $( compgen -W '$( cpack --help-module-list 2>/dev/null|
+grep -v "^cpack version " )' -- "$cur" ) )
+return
+;;
+--help-policy)
+COMPREPLY=( $( compgen -W '$( cpack --help-policies 2>/dev/null |
+grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+return
+;;
+--help-property)
+COMPREPLY=( $( compgen -W '$( cpack --help-property-list \
+2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )
+return
+;;
 --help-variable)
 COMPREPLY=( $( compgen -W '$( cpack --help-variable-list \
 2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=abdb88e7f742246be27bd4c13dbe72eef983d986
commit abdb88e7f742246be27bd4c13dbe72eef983d986
Author: Eric NOULARD 
AuthorDate: Fri Jun 10 15:28:05 2016 +0200
Commit: Brad King 
CommitDate: Fri Jun 10 09:50:01 2016 -0400

bash-completion: Add ctest --help-{manual,module,policy,property,variable}

diff --git a/Auxiliary/bash-completion/ctest b/Auxiliary/bash-completion/ctest
index 387672a..d15cc98 100644
--- a/Auxiliary/bash-completion/ctest
+++ b/Auxiliary/bash-completion/ctest
@@ -72,11 +72,37 @@ _ctest()
 COMPREPLY=( $( compgen -W '0 1' -- "$cur" ) )
 return
 ;;
+
 --help-command)
 COMPREPLY=( $( compgen -W '$( ctest --help-command-list 
2>/dev/null|
 grep -v "^ctest version " )' -- "$cur" ) )
 return
 ;;
+--help-manual)
+COMPREPLY=( $( compgen -W '$( ctest --help-manual-list 2>/dev/null|
+grep -v "^ctest version " | sed -e "s/([0-9])$//" )' -- "$cur" 
) )
+return
+;;
+--help-module)
+COMPREPLY=( $( compgen -W '$( ctest --help-module-list 2>/dev/null|
+grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
+--help-policy)
+COMPREPLY=( $( compgen -W '$( ctest --help-policies 2>/dev/null |
+grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+return
+;;
+--help-property)
+COMPREPLY=( $( compgen -W '$( ctest --help-property-list \
+2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
+--help-variable)
+COMPREPLY=( $( compgen -W '$( ctest --help-variable-list \
+2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )

[CMake] CMake and FindBoost cannot set the library variables

[Xi Shen]

Hi,

I have a simple CMakeList.txt file:

cmake_minimum_required (VERSION 3.0)
project (winotify)

set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
find_package(Boost REQUIRED COMPONENTS regex program_options)

add_executable(winotify winotify.cpp)

message(STATUS "xxx ${Boost_program_options_LIBRARY_DEBUG}")
message(STATUS "xxx ${Boost_INCLUDE_DIR}")
message(STATUS "xxx ${Boost_LIBRARY_DIR}")

target_link_libraries(winotify
 ${Boost_PROGRAMOPTIONS_LIBRARY_DEBUG})


I set up BOOST_ROOT on my Windows system. When I execute cmake, I got:

...
-- Boost version: 1.59.0
-- Found the following Boost libraries:
--   regex
--   program_options
-- xxx
-- xxx C:/Boost/include/boost-1_59
-- xxx
-- Configuring done
...

So the "Boost_INCLUDE_DIR" variable is set, but the other are not...what
did I miss?


Thanks,
David

-- 

Thanks,
David S.
-- 

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

Re: [cmake-developers] Questions about coding conventions

[Brad King]

On 06/10/2016 09:30 AM, Daniel Pfeifer wrote:
> By looking at the CMake source code, there are some inconsistencies
> regarding coding conventions. This is not a big problem and fixing
> them probably does not have a high priority.
> I would like to know what conventions to follow for new code.

Please look at documenting this in CONTRIBUTING.rst once we resolve
this discussion.

> Formatting: No longer an issue. A .clang-format is provided and most
> inconsistencies have disappeared.

Yes, and thanks for all your work on that.

> Braces around single conditional statements: This is currently not
> consistent. Should they be avoided? Should they be required? We could
> add the missing ones with clang-tidy. If we want them.

The intention has been to use braces for all blocks even with single
statements.  Due to lack of documentation and enforcement this has
not been maintained consistently.

> Naming conventions: Classes are named  cmLikeThis. Member functions
> and member variables are named LikeThis. Local variables are named
> likeThis. Members are always accessed with `this->`.

Yes, though there are also many local variables named `like_this` too.
I have no strong feelings on enforcing local variable name conventions.

> So far it is pretty consistent. But how to name free functions and
> macros? I have seen all kinds of variations.

No convention was ever established for those.

> `const T` or `T const` (also: `const T&` or `T const&`): Currently,
> CMake uses both. I have not analyzed which one dominates.

I prefer `T const` always, except for `const char*` specifically.

> Passing and returning strings: We have `const char*`, `std::string`,
> and `std::string const&`. Unifying this can affect performance.
> Storing `const char*` in a `std::string` creates a (potentially
> unneded) copy (assuming it is not null). `const char*` can distinguish
> invalid from empty. Do we actually need this distinction?

Last year we had a few cleanup passes done along those lines, but
it is far from consistent everywhere.  There  are cases where we
need to distinguish invalid from empty, like GetDefinition().  It
would be nice to have an optional or something like that
so we can keep the distinction but avoid using `const char*` all
over.  Any change like this should be introduced gradually, as
many of the related areas are performance sensitive.

-Brad

-- 

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-commits] CMake branch, next, updated. v3.6.0-rc1-205-gceb8b83

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  ceb8b8371ad2426dec35210e0de96fda69bc6c9a (commit)
   via  63c0e92c9395083a61fe31cd89bee7e3814f10e8 (commit)
   via  6eee24634bc1791a64f8146c0f79c769eb9dfb83 (commit)
   via  120899c6980fcd81aa2a0d7b733ae15332a7a133 (commit)
   via  7066218e792927cb6494ce73e834b8ddb3d275e6 (commit)
  from  88ae1dea8b44cbd456e07ad372d8f0ee14b5d8a3 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ceb8b8371ad2426dec35210e0de96fda69bc6c9a
commit ceb8b8371ad2426dec35210e0de96fda69bc6c9a
Merge: 88ae1de 63c0e92
Author: Brad King 
AuthorDate: Fri Jun 10 09:34:54 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 09:34:54 2016 -0400

Merge topic 'expose-cache-properties' into next

63c0e92c cmState: Expose list of properties of values in the cache
6eee2463 cmCacheEntry: Retrieve all properties of cache entries
120899c6 cmPropertyList: Add a way to retrieve all properties
7066218e cmake: Kill cmake::CacheManager and its getter


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63c0e92c9395083a61fe31cd89bee7e3814f10e8
commit 63c0e92c9395083a61fe31cd89bee7e3814f10e8
Author: Tobias Hunger 
AuthorDate: Fri Jun 10 10:10:07 2016 +0200
Commit: Brad King 
CommitDate: Fri Jun 10 09:33:41 2016 -0400

cmState: Expose list of properties of values in the cache

diff --git a/Source/cmState.cxx b/Source/cmState.cxx
index 04f07ce..d2cfaba 100644
--- a/Source/cmState.cxx
+++ b/Source/cmState.cxx
@@ -246,6 +246,14 @@ void cmState::SetCacheEntryBoolProperty(std::string const& 
key,
   it.SetProperty(propertyName, value);
 }
 
+std::vector cmState::GetCacheEntryPropertyList(
+  const std::string& key)
+{
+  cmCacheManager::CacheIterator it =
+this->CacheManager->GetCacheIterator(key.c_str());
+  return it.GetPropertyList();
+}
+
 const char* cmState::GetCacheEntryProperty(std::string const& key,
std::string const& propertyName)
 {
diff --git a/Source/cmState.h b/Source/cmState.h
index 18c45b8..935faec 100644
--- a/Source/cmState.h
+++ b/Source/cmState.h
@@ -247,6 +247,7 @@ public:
  std::string const& value);
   void SetCacheEntryBoolProperty(std::string const& key,
  std::string const& propertyName, bool value);
+  std::vector GetCacheEntryPropertyList(std::string const& key);
   const char* GetCacheEntryProperty(std::string const& key,
 std::string const& propertyName);
   bool GetCacheEntryPropertyAsBool(std::string const& key,

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6eee24634bc1791a64f8146c0f79c769eb9dfb83
commit 6eee24634bc1791a64f8146c0f79c769eb9dfb83
Author: Tobias Hunger 
AuthorDate: Fri Jun 10 09:34:49 2016 +0200
Commit: Brad King 
CommitDate: Fri Jun 10 09:33:41 2016 -0400

cmCacheEntry: Retrieve all properties of cache entries

diff --git a/Source/cmCacheManager.cxx b/Source/cmCacheManager.cxx
index 676e84a..233d9ca 100644
--- a/Source/cmCacheManager.cxx
+++ b/Source/cmCacheManager.cxx
@@ -539,6 +539,11 @@ void cmCacheManager::CacheIterator::Next()
   }
 }
 
+std::vector cmCacheManager::CacheIterator::GetPropertyList() const
+{
+  return this->GetEntry().GetPropertyList();
+}
+
 void cmCacheManager::CacheIterator::SetValue(const char* value)
 {
   if (this->IsAtEnd()) {
@@ -558,6 +563,11 @@ bool cmCacheManager::CacheIterator::GetValueAsBool() const
   return cmSystemTools::IsOn(this->GetEntry().Value.c_str());
 }
 
+std::vector cmCacheManager::CacheEntry::GetPropertyList() const
+{
+  return this->Properties.GetPropertyList();
+}
+
 const char* cmCacheManager::CacheEntry::GetProperty(
   const std::string& prop) const
 {
diff --git a/Source/cmCacheManager.h b/Source/cmCacheManager.h
index e9b80cb..153e957 100644
--- a/Source/cmCacheManager.h
+++ b/Source/cmCacheManager.h
@@ -38,6 +38,7 @@ private:
 std::string Value;
 cmState::CacheEntryType Type;
 cmPropertyMap Properties;
+std::vector GetPropertyList() const;
 const char* GetProperty(const std::string&) const;
 void SetProperty(const std::string& property, const char* value);
 void AppendProperty(const std::string& property, const char* value,
@@ -60,6 +61,7 @@ public:
 bool IsAtEnd() const;
 void Next();
 std::string GetName() const { return this->Position->first; }
+std::vector GetPropertyList() const;
 const char* 

[cmake-developers] Update bash completion scripts

[Eric Noulard]

Hi,

Here comes an update of the bash completion scripts.
All of them now handle the same set of --help-xxx options
the handling of --help-manual has been added.


-- 
Eric
From b201a66ab61643066294d554434829399371f733 Mon Sep 17 00:00:00 2001
From: Eric NOULARD 
Date: Fri, 10 Jun 2016 15:28:05 +0200
Subject: [PATCH] Update bash completion scripts for cmake, cpack & ctest.

The modifications are:
- add the handling of --help-manual which was missing
- make the 3 commands handle the common set of completion for --help-.
---
 Auxiliary/bash-completion/cmake |  5 +
 Auxiliary/bash-completion/cpack | 22 +-
 Auxiliary/bash-completion/ctest | 26 ++
 3 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/Auxiliary/bash-completion/cmake b/Auxiliary/bash-completion/cmake
index 557f243..6997d47 100644
--- a/Auxiliary/bash-completion/cmake
+++ b/Auxiliary/bash-completion/cmake
@@ -121,6 +121,11 @@ _cmake()
 grep -v "^cmake version " )' -- "$cur" ) )
 return
 ;;
+--help-manual)
+COMPREPLY=( $( compgen -W '$( cmake --help-manual-list 2>/dev/null|
+grep -v "^cmake version " | sed -e "s/([0-9])$//" )' -- "$cur" ) )
+return
+;;
 --help-module)
 COMPREPLY=( $( compgen -W '$( cmake --help-module-list 2>/dev/null|
 grep -v "^cmake version " )' -- "$cur" ) )
diff --git a/Auxiliary/bash-completion/cpack b/Auxiliary/bash-completion/cpack
index 05e0e93..8f14a72 100644
--- a/Auxiliary/bash-completion/cpack
+++ b/Auxiliary/bash-completion/cpack
@@ -48,7 +48,27 @@ _cpack()
 grep -v "^cpack version " )' -- "$cur" ) )
 return
 ;;
---help-variable)
+--help-manual)
+COMPREPLY=( $( compgen -W '$( cpack --help-manual-list 2>/dev/null|
+grep -v "^cpack version " | sed -e "s/([0-9])$//" )' -- "$cur" ) )
+return
+;;
+--help-module)
+COMPREPLY=( $( compgen -W '$( cpack --help-module-list 2>/dev/null|
+grep -v "^cpack version " )' -- "$cur" ) )
+return
+;;
+ --help-policy)
+COMPREPLY=( $( compgen -W '$( cpack --help-policies 2>/dev/null |
+grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+return
+;;
+ --help-property)
+COMPREPLY=( $( compgen -W '$( cpack --help-property-list \
+2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )
+return
+;;
+ --help-variable)
 COMPREPLY=( $( compgen -W '$( cpack --help-variable-list \
 2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )
 return
diff --git a/Auxiliary/bash-completion/ctest b/Auxiliary/bash-completion/ctest
index 387672a..de8fde1 100644
--- a/Auxiliary/bash-completion/ctest
+++ b/Auxiliary/bash-completion/ctest
@@ -72,11 +72,37 @@ _ctest()
 COMPREPLY=( $( compgen -W '0 1' -- "$cur" ) )
 return
 ;;
+
 --help-command)
 COMPREPLY=( $( compgen -W '$( ctest --help-command-list 2>/dev/null|
 grep -v "^ctest version " )' -- "$cur" ) )
 return
 ;;
+--help-manual)
+COMPREPLY=( $( compgen -W '$( ctest --help-manual-list 2>/dev/null|
+grep -v "^ctest version " | sed -e "s/([0-9])$//" )' -- "$cur" ) )
+return
+;;
+--help-module)
+COMPREPLY=( $( compgen -W '$( ctest --help-module-list 2>/dev/null|
+grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
+ --help-policy)
+COMPREPLY=( $( compgen -W '$( ctest --help-policies 2>/dev/null |
+grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+return
+;;
+ --help-property)
+COMPREPLY=( $( compgen -W '$( ctest --help-property-list \
+2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
+ --help-variable)
+COMPREPLY=( $( compgen -W '$( ctest --help-variable-list \
+2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
 esac
 
 if [[ "$cur" == -* ]]; then
-- 
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 

[cmake-developers] Questions about coding conventions

[Daniel Pfeifer]

Hi,

By looking at the CMake source code, there are some inconsistencies
regarding coding conventions. This is not a big problem and fixing
them probably does not have a high priority.
I would like to know what conventions to follow for new code.

Formatting: No longer an issue. A .clang-format is provided and most
inconsistencies have disappeared.

Braces around single conditional statements: This is currently not
consistent. Should they be avoided? Should they be required? We could
add the missing ones with clang-tidy. If we want them.

Naming conventions: Classes are named  cmLikeThis. Member functions
and member variables are named LikeThis. Local variables are named
likeThis. Members are always accessed with `this->`. So far it is
pretty consistent. But how to name free functions and macros? I have
seen all kinds of variations.

`const T` or `T const` (also: `const T&` or `T const&`): Currently,
CMake uses both. I have not analyzed which one dominates.

Passing and returning strings: We have `const char*`, `std::string`,
and `std::string const&`. Unifying this can affect performance.
Storing `const char*` in a `std::string` creates a (potentially
unneded) copy (assuming it is not null). `const char*` can distinguish
invalid from empty. Do we actually need this distinction? Or should we
assume empty==invalid and always prefer `std::string const&`
arguments? Or should we introduce a C++17-like cmStringView?

cheers, Daniel
-- 

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-commits] CMake branch, next, updated. v3.6.0-rc1-200-g88ae1de

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  88ae1dea8b44cbd456e07ad372d8f0ee14b5d8a3 (commit)
   via  f62ed322dc0d859f595be5ddeff40904ee478f50 (commit)
   via  853b1bb4ba176e886e3682a2475f1de1932ee890 (commit)
  from  efe13e2f0b16754a1a87b04e75421d29bd223573 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=88ae1dea8b44cbd456e07ad372d8f0ee14b5d8a3
commit 88ae1dea8b44cbd456e07ad372d8f0ee14b5d8a3
Merge: efe13e2 f62ed32
Author: Brad King 
AuthorDate: Fri Jun 10 09:26:52 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 09:26:52 2016 -0400

Merge topic 'refactor-cmLocalGenerator-flags' into next

f62ed322 cmLocalGenerator: Add GetTargetDefines to get all defines for a 
target
853b1bb4 cmLocalGenerator: Constify AppendDefines and AddCompileDefinitions


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f62ed322dc0d859f595be5ddeff40904ee478f50
commit f62ed322dc0d859f595be5ddeff40904ee478f50
Author: Tobias Hunger 
AuthorDate: Wed Jun 8 13:23:25 2016 +0200
Commit: Brad King 
CommitDate: Fri Jun 10 09:24:49 2016 -0400

cmLocalGenerator: Add GetTargetDefines to get all defines for a target

diff --git a/Source/cmCommonTargetGenerator.cxx 
b/Source/cmCommonTargetGenerator.cxx
index 131b490..b893dd3 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -246,19 +246,11 @@ std::string cmCommonTargetGenerator::GetDefines(const 
std::string& l)
   ByLanguageMap::iterator i = this->DefinesByLanguage.find(l);
   if (i == this->DefinesByLanguage.end()) {
 std::set defines;
-const char* lang = l.c_str();
-// Add the export symbol definition for shared library objects.
-if (const char* exportMacro = this->GeneratorTarget->GetExportMacro()) {
-  this->LocalGenerator->AppendDefines(defines, exportMacro);
-}
-
-// Add preprocessor definitions for this target and configuration.
-this->LocalGenerator->AddCompileDefinitions(
-  defines, this->GeneratorTarget, this->LocalGenerator->GetConfigName(),
-  l);
+this->LocalGenerator->GetTargetDefines(this->GeneratorTarget,
+   this->ConfigName, l, defines);
 
 std::string definesString;
-this->LocalGenerator->JoinDefines(defines, definesString, lang);
+this->LocalGenerator->JoinDefines(defines, definesString, l);
 
 ByLanguageMap::value_type entry(l, definesString);
 i = this->DefinesByLanguage.insert(entry).first;
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 3f957f0..2ccaa82 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1329,6 +1329,20 @@ std::string 
cmLocalGenerator::GetFrameworkFlags(std::string const& l,
   return ::GetFrameworkFlags(l, config, target);
 }
 
+void cmLocalGenerator::GetTargetDefines(cmGeneratorTarget const* target,
+std::string const& config,
+std::string const& lang,
+std::set& defines) const
+{
+  // Add the export symbol definition for shared library objects.
+  if (const char* exportMacro = target->GetExportMacro()) {
+this->AppendDefines(defines, exportMacro);
+  }
+
+  // Add preprocessor definitions for this target and configuration.
+  this->AddCompileDefinitions(defines, target, config, lang.c_str());
+}
+
 std::string cmLocalGenerator::ConvertToLinkReference(std::string const& lib,
  OutputFormat format)
 {
diff --git a/Source/cmLocalGenerator.h b/Source/cmLocalGenerator.h
index ad77c1f..55b8794 100644
--- a/Source/cmLocalGenerator.h
+++ b/Source/cmLocalGenerator.h
@@ -314,6 +314,9 @@ public:
   std::string& flags, std::string& linkFlags,
   std::string& frameworkPath, std::string& linkPath,
   cmGeneratorTarget* target, bool useWatcomQuote);
+  void GetTargetDefines(cmGeneratorTarget const* target,
+std::string const& config, std::string const& lang,
+std::set& defines) const;
 
   std::string GetFrameworkFlags(std::string const& l,
 std::string const& config,

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=853b1bb4ba176e886e3682a2475f1de1932ee890
commit 853b1bb4ba176e886e3682a2475f1de1932ee890
Author: Brad King 
AuthorDate: Fri Jun 10 09:23:14 2016 -0400
Commit:

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-197-gefe13e2

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  efe13e2f0b16754a1a87b04e75421d29bd223573 (commit)
   via  98aafb2ad64daa0617b3a71ec61f692d5aa205ce (commit)
   via  ff4697fc94d74e8c08d165837add668ccb5a5fad (commit)
   via  fbf461dde26aca7bb4b44d0f25e459ea30e3aa87 (commit)
   via  09e6c9eba7905b4af19dcdc18d8fe5c8d337218c (commit)
   via  b29f1514d012fb3036fd4579ccfb4004c20d8771 (commit)
   via  5d078868f00ff8dd514c7c35542aaf2eb0b5ef5f (commit)
   via  1bde72a390fd734795a3f5f4d09a3e279b5d61b8 (commit)
   via  1f9b35da101ba12f5c6d8cdbe8e073fa8709709a (commit)
  from  bcd209460fb45bc04ed0e99d23fac5c3c2e2c213 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=efe13e2f0b16754a1a87b04e75421d29bd223573
commit efe13e2f0b16754a1a87b04e75421d29bd223573
Merge: bcd2094 98aafb2
Author: Brad King 
AuthorDate: Fri Jun 10 09:10:43 2016 -0400
Commit: Brad King 
CommitDate: Fri Jun 10 09:10:43 2016 -0400

Merge branch 'master' into next


---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-104-g98aafb2

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  98aafb2ad64daa0617b3a71ec61f692d5aa205ce (commit)
   via  d9613b962e2ed5c908850c8a083630f753dac113 (commit)
   via  70d3bf85808d17dba8ec90e2975f2741383ef260 (commit)
   via  de4ee088e7ab60213b551ecf98bc9e1b512ee393 (commit)
  from  ff4697fc94d74e8c08d165837add668ccb5a5fad (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98aafb2ad64daa0617b3a71ec61f692d5aa205ce
commit 98aafb2ad64daa0617b3a71ec61f692d5aa205ce
Merge: ff4697f d9613b9
Author: Brad King 
AuthorDate: Fri Jun 10 09:10:04 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 09:10:04 2016 -0400

Merge topic 'refactor-cmLocalGenerator-flags'

d9613b96 cmLocalGenerator: Move GetFrameworkFlags implementation to private 
helper
70d3bf85 cmLocalGenerator: Adopt GetFrameworkFlags method
de4ee088 cmCommonTargetGenerator: De-duplicate CMAKE_BUILD_TYPE lookup


---

Summary of changes:
 Source/cmCommonTargetGenerator.cxx |   59 +++-
 Source/cmCommonTargetGenerator.h   |3 --
 Source/cmLocalGenerator.cxx|   58 +++
 Source/cmLocalGenerator.h  |4 +++
 4 files changed, 66 insertions(+), 58 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-100-gff4697f

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  ff4697fc94d74e8c08d165837add668ccb5a5fad (commit)
   via  d4b8e8135358024b6982100654a430358574efb2 (commit)
  from  fbf461dde26aca7bb4b44d0f25e459ea30e3aa87 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ff4697fc94d74e8c08d165837add668ccb5a5fad
commit ff4697fc94d74e8c08d165837add668ccb5a5fad
Merge: fbf461d d4b8e81
Author: Brad King 
AuthorDate: Fri Jun 10 09:10:02 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 09:10:02 2016 -0400

Merge topic 'FindProtobuf-proto-in-subdirs'

d4b8e813 FindProtobuf: fix protobuf_generate_*() to handle proto files in 
subdirs.


---

Summary of changes:
 Modules/FindProtobuf.cmake |8 
 1 file changed, 8 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-98-gfbf461d

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  fbf461dde26aca7bb4b44d0f25e459ea30e3aa87 (commit)
   via  746a4245738c7b3c0b29754cb09b2230697f13fc (commit)
  from  09e6c9eba7905b4af19dcdc18d8fe5c8d337218c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fbf461dde26aca7bb4b44d0f25e459ea30e3aa87
commit fbf461dde26aca7bb4b44d0f25e459ea30e3aa87
Merge: 09e6c9e 746a424
Author: Brad King 
AuthorDate: Fri Jun 10 09:09:59 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 09:09:59 2016 -0400

Merge topic 'FindFreetype-dedup-arguments'

746a4245 FindFreetype: Factor out common find command arguments


---

Summary of changes:
 Modules/FindFreetype.cmake |   35 ---
 1 file changed, 12 insertions(+), 23 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-91-g5d07886

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  5d078868f00ff8dd514c7c35542aaf2eb0b5ef5f (commit)
   via  ceebac93f66c3927997b708caf6f2eb2d1827593 (commit)
  from  1bde72a390fd734795a3f5f4d09a3e279b5d61b8 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d078868f00ff8dd514c7c35542aaf2eb0b5ef5f
commit 5d078868f00ff8dd514c7c35542aaf2eb0b5ef5f
Merge: 1bde72a ceebac9
Author: Brad King 
AuthorDate: Fri Jun 10 09:09:50 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 09:09:50 2016 -0400

Merge topic 'watcom-workaround'

ceebac93 Tests: Restore fix to Plugin test on Watcom compiler


---

Summary of changes:
 Tests/Plugin/src/example_exe.cxx |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-93-gb29f151

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  b29f1514d012fb3036fd4579ccfb4004c20d8771 (commit)
   via  e937b4c3879e1ee0770b465c0cdcbb6a960ba892 (commit)
  from  5d078868f00ff8dd514c7c35542aaf2eb0b5ef5f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b29f1514d012fb3036fd4579ccfb4004c20d8771
commit b29f1514d012fb3036fd4579ccfb4004c20d8771
Merge: 5d07886 e937b4c
Author: Brad King 
AuthorDate: Fri Jun 10 09:09:54 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 09:09:54 2016 -0400

Merge topic 'FindOpenSSL-BoringSSL'

e937b4c3 FindOpenSSL: Do not assume that the version regex finds something


---

Summary of changes:
 Modules/FindOpenSSL.cmake |8 
 1 file changed, 4 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-96-g09e6c9e

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  09e6c9eba7905b4af19dcdc18d8fe5c8d337218c (commit)
   via  7229ae728fa703390b70a9ded5606b01214c14de (commit)
   via  e9bfe8da04c5486335d15c68b544f25f940c9c92 (commit)
  from  b29f1514d012fb3036fd4579ccfb4004c20d8771 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=09e6c9eba7905b4af19dcdc18d8fe5c8d337218c
commit 09e6c9eba7905b4af19dcdc18d8fe5c8d337218c
Merge: b29f151 7229ae7
Author: Brad King 
AuthorDate: Fri Jun 10 09:09:57 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 09:09:57 2016 -0400

Merge topic 'FindCUDA-android'

7229ae72 FindCUDA: Refactor Android(Tegra) support
e9bfe8da FindCUDA: Adjust vertical whitespace


---

Summary of changes:
 Modules/FindCUDA.cmake |  140 +---
 Modules/FindCUDA/select_compute_arch.cmake |  195 
 2 files changed, 287 insertions(+), 48 deletions(-)
 create mode 100644 Modules/FindCUDA/select_compute_arch.cmake


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-89-g1bde72a

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  1bde72a390fd734795a3f5f4d09a3e279b5d61b8 (commit)
   via  f28401554af8fe48994b0c08668f0c1408708fe1 (commit)
  from  1f9b35da101ba12f5c6d8cdbe8e073fa8709709a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1bde72a390fd734795a3f5f4d09a3e279b5d61b8
commit 1bde72a390fd734795a3f5f4d09a3e279b5d61b8
Merge: 1f9b35d f284015
Author: Brad King 
AuthorDate: Fri Jun 10 09:09:47 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jun 10 09:09:47 2016 -0400

Merge topic 'cmake-gui-osx-symlink-qt5-plugin'

f2840155 cmake-gui: Teach Qt5 where plugins are when launched through a 
symlink


---

Summary of changes:
 Source/QtDialog/CMakeSetup.cxx |   34 ++
 1 file changed, 34 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] FindFreetype patch for Windows debug lib naming

[Brad King]

On 06/10/2016 03:19 AM, Stuart Mentzer wrote:
> On 6/10/2016 2:45 AM, Rolf Eike Beer wrote:
>> I'm sure I also wrote "you probably need to set/unset
>> FREETYPE_LIBRARY_RELEASE around SLC so it still works",
>> The point here is that you can't change the variable name
>> that is used in find_library() as it would break compatibility.
> 
> Is there someone who can just do what is needed and let us be done with this?

Eike, IIRC what we've done for other modules is change the cache
entries to use ${pkg}_LIBRARY_{RELEASE,DEBUG} and then provided
compatibility with scripts that explicitly set ${pkg}_LIBRARY
by using the value if set and skipping the search.  See FindZLIB
for an example of this.

-Brad

-- 

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] how to compile single source file with debug options?

[Sergey Spiridonov]

Hello all,

We have big project with lots of libraries and applications. We want to
switch to cmake. Currently we use our own build system, which is derived
from tmake.

To debug and fix our applications/libraries we often need to recompile
single source file in a debug mode. With the our current build system it
is as simple, as touching a file an starting make with debug option. It
will then recompile that single file with -O0 -g and with -DDEBUG and
relink target application/library.

How it would be possible in cmake? We found out how to do that for the
single directory (library or application). But recompiling whole
library/application just for single file is too slow.

This is really a show-stopper for us.
-- 
Best regards, Sergey Spiridonov

-- 

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

Re: [CMake] execute_process, cmd /c and vcvarsall

[David Cole via CMake]

The easiest way to do what you want here is to make a standalone
script (*.bat / *.cmd) that runs the commands you want and get it to
work without CMake involvement at all, and then simply use
execute_process to invoke that script.

You can pass arguments to it if you need to communicate information
from CMake to the script, but if you **require** environment for your
command to run, the easiest way to achieve it is to write a script
that sets up the env, and then executes the command, and then restores
the environment (if necessary).

In Windows *.cmd files, it's easy to save/restore the environment by
using "setlocal" and "endlocal".

Why bother with all the escaping and special characters in an
execute_process when you could just write a script and then call it?
It will be much easier on the eyes for people having to read your code
in the future if you make it simpler.


HTH,
David C.




On Fri, Jun 10, 2016 at 6:21 AM, Kristian  wrote:
> After some tries I found maybe a solution for you. In my small example, I
> had these lines, which are working:
>
>
>> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio
>> 14.0/VC/vcvarsall.bat")
>> execute_process(COMMAND ${HELLO1} && msbuild /help WORKING_DIRECTORY
>> "${CMAKE_CURRENT_SOURCE_DIR}")
>
> So for you, it would look like this (I am not very sure about it):
>
> ==
>
>
> execute_process( COMMAND
> $ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat x86_amd64 &&
> ${CUDA_NVCC_EXECUTABLE}
> ${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu --run
>
>  WORKING_DIRECTORY
> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/"
>
>  RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out
>
>  OUTPUT_STRIP_TRAILING_WHITESPACE)
>
>
> ==
>
> Anyhow, when I tried several types of your presentation, I got always some
> errors. I do not know, if this is a bug or not, but I will write them down
> here. Maybe some of the others could write something about it.
>
>
> *** First try ***
>
>> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio
>> 14.0/VC/vcvarsall.bat")
>> execute_process(COMMAND cmd /c "call ${HELLO1}" WORKING_DIRECTORY
>> "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE
>> _nvcc_out)
>> message("${_nvcc_out}")
>
> When I call these lines on a windows machine, I am getting the error
>
>> 'C:/Program' is not recognized as an internal or external command,
>> operable program or batch file.
>
> *** Second try ***
>
> When I change the execute_process to this
>
>> execute_process(COMMAND cmd /c "call \"${HELLO1}\"" WORKING_DIRECTORY
>> "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE
>> _nvcc_out)
>
> then I am getting this error
>
>> '\"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat\"'
>> is not recognized as an internal or external command, operable program or
>> batch file.
>
> So now, CMake / Batch recognizes the right path, but somehow there are the
> characters \".
>
> *** Third try ***
>
> I changed the definition of the variable HELLO1 into (because of some hints
> here
> https://superuser.com/questions/279008/how-do-i-escape-spaces-in-command-line-in-windows-without-using-quotation-marks)
>
>> set(HELLO1 "C:/Program^ Files^ (x86)/Microsoft^ Visual^ Studio^
>> 14.0/VC/vcvarsall.bat")
>
> But here, I am also getting the error
>
>> 'C:/Program' is not recognized as an internal or external command,
>> operable program or batch file.
>
> Even, when I double the carets ^^, then the same error occurs
>
>
> 2016-06-09 22:41 GMT+02:00 Adam Rankin :
>>
>> Hello all,
>>
>>
>>
>> I am trying to develop a execute_process command that will first load the
>> env variables set by the appropriate vcvarsall, and then run a compile
>> command. See here for my progress so far:
>>
>>
>>
>> set(cuda_generation_command cmd /c "\"call
>> \"$ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat\" x86_amd64 &&
>> \"${CUDA_NVCC_EXECUTABLE}\"
>> \"${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu\" \"--run\"\"")
>>
>>
>>
>> execute_process( COMMAND ${cuda_generation_command}
>>
>>  WORKING_DIRECTORY
>> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/"
>>
>>  RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out
>>
>>  OUTPUT_STRIP_TRAILING_WHITESPACE)
>>
>>
>>
>> When run at a command prompt, the command works as expected. When called
>> from CMake, the output is:
>>
>> The filename, directory name, or volume label syntax is incorrect.
>>
>>
>>
>> Has anyone ever succeeded with something like this?
>>
>>
>>
>> Cheers,
>>
>> Adam
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake 

Re: [CMake] How do you handle recursive dependencies in CMake

[Sven Baars]

Hey Chuck,

In ATargets.cmake it says

add_library(a SHARED IMPORTED)

and in BTargets.cmake it says

add_library(b SHARED IMPORTED)

However, if I build C it will say

/usr/bin/ld: cannot find -la

when I do

find_package(B)
target_link_libraries(c b)
add_executable(main main.cpp)
target_link_libraries(main c)

This, I think, because the 'b' target depends on 'a' but doesn't know
where 'a' is located, because this is not described in BTargets.cmake.

Sven

On 06/08/2016 06:07 PM, Chuck Atkins wrote:
> If the projects are each providing their own Config.cmake file then
> you probably will want to use those instead of Find modules.  Instead
> of using the Foo_Bar_LIBRARIES variable though, try using the actual
> imported targets from the config files.  Those should have the
> appropriate dependency information. If you're not sure what they are
> you should be able to dig through the provided Config.cmake and
> Targets.cmake files for FooBar and see which targets are created bu
> "add_library(FooBar::Foo ... IMPORTED)".
>
> - Chuck
>
> On Wed, Jun 8, 2016 at 11:31 AM, Sven Baars  > wrote:
>
> In my case all projects provide their own FooBarConfig.cmake, but
> not a FindFooBar.cmake. For this reason I wanted to use those,
> because I thought it saves me the effort of writing a lot of
> FindFooBar.cmake files, and it also seemed like the right way to
> do it, because it provides things like FooBar_LIBRARIES, which is
> what I need. The reason I said that I create my own
> FooBarConfig.cmake, is because I want to use CMake properly in my
> own project, so I also want to provide a FoorBarConfig.cmake file
> for my users. So even if the projects I use don't do everything
> properly, I still want to do it properly myself. The problem in
> this case is that I'm not sure what the proper way is. If the
> FoorBarConfig.cmake file is not enough to handle the dependencies
> I encounter, should I provide a FindFooBar.cmake file or
> something, instead of just the FooBarConfig.cmake? And meanwhile
> also write a FindFooBar.cmake file for all my dependencies?
>
> Another reason why this seems odd to me, is because if N different
> projects use FooBar, then also possibly N different versions of
> FindFooBar.cmake are created by all the different projects (I have
> actually already seen this a lot). That is the case, because the
> FindFooBar.cmake file is not provided by the FooBar project,
> unlike the FooBarConfig.cmake.
>
> Cheers,
> Sven
>
>
> On 06/08/2016 03:11 PM, Chuck Atkins wrote:
>> The FooBarConfig.cmake is something that should be generated by
>> FooBar's build.   The reason you don't get absolute paths for the
>> "libraries" from a package config file is that they're not
>> actually libraries but imported targets.  The imported target
>> let's you treat "foo" as though it were a library built by your
>> project.  It then has the appropriate target properties set on it
>> ti define the full path to it's library, etc.  That being said,
>> if you're manually creating the FooBarConfig.cmake that's not
>> really the right approach.  If the FooBar buil;d doesn't actually
>> generate it's own FooBarConfig.cmake file then you'll want to
>> create you're own FindFooBar.cmake.  A bare bones find module
>> that creates an imported target would look something like this:
>>
>> if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar)
>>   find_path(FooBar_INCLUDE_DIR FooBar.h)
>>   find_library(FooBar_LIBRARY FooBar)
>>
>>   include(FindPackageHandleStandardArgs)
>>   find_package_handle_standard_args(FooBar
>> FOUND_VAR FooBar_FOUND
>> REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY
>>   )
>> endif()
>>
>> if(FooBar_FOUND AND NOT TARGET FooBar::FooBar)
>>   add_library(FooBar::FooBar UNKNOWN IMPORTED)
>>   set_target_properties(FooBar::FooBar PROPERTIES
>> IMPORTED_LOCATION ${FooBar_LIBRARY}
>> INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR}
>>   )
>> endif()
>>
>> Then in your project you can use:
>>
>> find_package(FooBar)
>> add_library(MyLib supercoolfiles.cxx)
>> target_libkLibraries(MyLib FooBar::FooBar)
>>
>> Where this starts to get really helpful in your situation is if
>> you have an imported target for A, B, and C, then you can create
>> the appropriate dependencies.  Say, for example, you have a
>> FindA.cmake that follows the pattern above and generates an A::A
>> target.  Then in your FindB.cmake you can have:
>>
>> if(NOT B_FOUND AND NOT TARGET B::B)
>>   find_path(B_INCLUDE_DIR B.h)
>>   find_library(B_LIBRARY B)
>>
>>   include(FindPackageHandleStandardArgs)
>>   find_package_handle_standard_args(B
>> FOUND_VAR B_FOUND
>> REQUIRED_VARS B_INCLUDE_DIR B_LIBRARY
>>  

Re: [CMake] Boost directories are not added to solution file

[Petr Kmoch]

Hi David.

Probably something in your CMakeList is set up incorrectly. If you share
that CMakeList, someone might be able to tell what.

Petr

On 10 June 2016 at 13:09, Xi Shen  wrote:

> I created a simple command line tool on Windows, using the Boost library.
> I use the CMake tool to generate the build file for MSBuild.
>
> I set the BOOST_INCLUDEDIR environment variable and CMake generated the
> build file without any error.
>
> However the solution cannot be built by MSBuild. It complains not able to
> find "boost\regex.hpp" file, etc.
>
> I found if I open the solution file and edit the `additional include
> directory` and `additional library directory`, the solution can build
> without error.
>
> So I wonder why CMake did not add those directories to the solution. What
> did I miss?
>
>
> Thanks,
> Daivd
>
> --
>
> Thanks,
> David S.
>
> --
>
> 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
>
-- 

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

[CMake] Boost directories are not added to solution file

[Xi Shen]

I created a simple command line tool on Windows, using the Boost library. I
use the CMake tool to generate the build file for MSBuild.

I set the BOOST_INCLUDEDIR environment variable and CMake generated the
build file without any error.

However the solution cannot be built by MSBuild. It complains not able to
find "boost\regex.hpp" file, etc.

I found if I open the solution file and edit the `additional include
directory` and `additional library directory`, the solution can build
without error.

So I wonder why CMake did not add those directories to the solution. What
did I miss?


Thanks,
Daivd

-- 

Thanks,
David S.
-- 

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

Re: [CMake] execute_process, cmd /c and vcvarsall

[Kristian]

After some tries I found maybe a solution for you. In my small example, I
had these lines, which are working:


> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio
14.0/VC/vcvarsall.bat")
> execute_process(COMMAND ${HELLO1} && msbuild /help WORKING_DIRECTORY
"${CMAKE_CURRENT_SOURCE_DIR}")

So for you, it would look like this (I am not very sure about it):

==


execute_process( COMMAND $ENV{VS${VS_IDE_VERSION}
0COMNTOOLS}../../VC/vcvarsall.bat x86_amd64 &&  ${CUDA_NVCC_EXECUTABLE}
${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu --run

 WORKING_DIRECTORY
"${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/"

 RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out

 OUTPUT_STRIP_TRAILING_WHITESPACE)

==

Anyhow, when I tried several types of your presentation, I got always some
errors. I do not know, if this is a bug or not, but I will write them down
here. Maybe some of the others could write something about it.


*** First try ***

> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio
14.0/VC/vcvarsall.bat")
> execute_process(COMMAND cmd /c "call ${HELLO1}" WORKING_DIRECTORY
"${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE
_nvcc_out)
> message("${_nvcc_out}")

When I call these lines on a windows machine, I am getting the error

> 'C:/Program' is not recognized as an internal or external command,
operable program or batch file.

*** Second try ***

When I change the execute_process to this

> execute_process(COMMAND cmd /c "call \"${HELLO1}\"" WORKING_DIRECTORY
"${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE
_nvcc_out)

then I am getting this error

> '\"C:/Program Files (x86)/Microsoft Visual Studio
14.0/VC/vcvarsall.bat\"' is not recognized as an internal or external
command, operable program or batch file.

So now, CMake / Batch recognizes the right path, but somehow there are the
characters \".

*** Third try ***

I changed the definition of the variable HELLO1 into (because of some hints
here
https://superuser.com/questions/279008/how-do-i-escape-spaces-in-command-line-in-windows-without-using-quotation-marks
)

> set(HELLO1 "C:/Program^ Files^ (x86)/Microsoft^ Visual^ Studio^
14.0/VC/vcvarsall.bat")

But here, I am also getting the error

> 'C:/Program' is not recognized as an internal or external command,
operable program or batch file.

Even, when I double the carets ^^, then the same error occurs


2016-06-09 22:41 GMT+02:00 Adam Rankin :

> Hello all,
>
>
>
> I am trying to develop a execute_process command that will first load the
> env variables set by the appropriate vcvarsall, and then run a compile
> command. See here for my progress so far:
>
>
>
> set(cuda_generation_command cmd /c "\"call
> \"$ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat\" x86_amd64 &&
> \"${CUDA_NVCC_EXECUTABLE}\"
> \"${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu\" \"--run\"\"")
>
>
>
> execute_process( COMMAND ${cuda_generation_command}
>
>  WORKING_DIRECTORY
> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/"
>
>  RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out
>
>  OUTPUT_STRIP_TRAILING_WHITESPACE)
>
>
>
> When run at a command prompt, the command works as expected. When called
> from CMake, the output is:
>
> The filename, directory name, or volume label syntax is incorrect.
>
>
>
> Has anyone ever succeeded with something like this?
>
>
>
> Cheers,
>
> Adam
>
> --
>
> 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
>
-- 

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

[cmake-developers] cmCacheManager related changes

[Tobias Hunger]

Hi Brad,

I got some more changes to enable daemon-mode to access the full contents of the
CMakeCacheManager. With these patches and the daemon mode as of today Daniel
should be able to implement something like ccmake with daemon-mode only.

These patches are all concerned about accessing the properties that are set
on the cache values.

https://github.com/hunger/CMake/commit/b46f1feae7c2f1bd47b7d1848ce31d4edf505a1e

makes the list of defined properties accessible from the cmPropertyMap.

https://github.com/hunger/CMake/commit/a7bf58458172580e0aab865726b18341af142248

makes the list of defined properties accessible from the cmCacheEntry.

https://github.com/hunger/CMake/commit/0ff8cd2e862b52a0baf271b127945bed00f8db38

It kills an uninitialized cmCacheManager* in the cmake object and its getter.

https://github.com/hunger/CMake/commit/958c0bfd18f26a9d61d2a39ed826a7ce40fce35c

Adds an interface to cmState to retrieve the property list.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] FindFreetype patch for Windows debug lib naming

[Stuart Mentzer]

On 6/10/2016 2:45 AM, Rolf Eike Beer wrote:

Am 2016-06-09 23:35, schrieb Stuart Mentzer:

On 6/9/2016 9:33 AM, Rolf Eike Beer wrote:

Am 2016-06-09 15:00, schrieb Brad King:

On 06/08/2016 12:33 AM, Stuart Mentzer wrote:

Here is a little patch that lets FindFreetype find the debug
library on Windows, where it is named with a d suffix.


Thanks.  I split the patch into two and applied:

 FindFreetype: Factor out common find command arguments
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=746a4245

 FindFreetype: Search for a separate debug library
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6085b855


This will probably not work: SLC will look for FREETYPE_LIBRARY_RELEASE, which 
is never set. So you will have to

set(FREETYPE_LIBRARY_RELEASE ${FREETYPE_LIBRARY})
SLC()
unset(FREETYPE_LIBRARY_RELEASE)

or something like that.



I'm a little confused here. Eike, you suggested that I shouldn't name
the release variable FREETYPE_LIBRARY_RELEASE, so I changed it to
FREETYPE_LIBRARY, but looking at SLC code it seems that would both
work and get FREETYPE_LIBRARY set. I guess doing it the way you
suggest above would also achieve the same thing but it seemed and
seems more symmetric to name the release variable with _RELEASE and
let SLC do its job. Anyway, I'm happy to submit the second part of the
patch once it is clear what is best.


Hi,

I'm sure I also wrote "you probably need to set/unset FREETYPE_LIBRARY_RELEASE 
around SLC so it still works", although I can't find the mail where I said that 
(besides the above, of course). In the end you can test it easily: if both libraries are 
found, but only one ends up in FREETYPE_LIBRARIES then something went wrong.

The point here is that you can't change the variable name that is used in 
find_library() as it would break compatibility.

Greetings,

Eike

Eike,

Thanks for trying to help but really I don't know (or want to know) enough of 
CMake's internals to quickly resolve this. My only build example that uses 
FindFreetype builds debug and release separately and it would take some work to 
try to do them together. At this point I need some help or I have to move on 
and give up here. Is there someone who can just do what is needed and let us be 
done with this?

Thanks,
Stuart
--

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