date:20160412

Re: [CMake] issue with target_link_libraries and MSVC

2016-04-12 Thread Matějů Miroslav , Ing .

Hi Benjamin,

MSVC flags start with “forward” slashes: / (However, MSVC also accepts hyphens 
(-) in my experience.)
Documentation for /openmp flag: https://msdn.microsoft.com/library/fw509c3b.aspx

Best regards,
Miroslav

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Benjamin Ballet via 
CMake
Sent: Tuesday, April 12, 2016 5:30 PM
To: cmake@cmake.org
Subject: [CMake] issue with target_link_libraries and MSVC

I'm trying to add the openmp flag to a target with target_link_libraries.
\openmp is interpreted as a file name and visual try to link to \openmp.obj

The documentation state that target_link_libraries see an item as a flag if it 
start with - but MSVC flags start with \

Is there a way to add a link flags to a target with target_link_libraries and 
MSVC ?

Thank you all

--
Benjamin BALLET
Ingénieur R

ACTIVISU
19, rue Klock - 92110 Clichy
> Standard Tél :  01 44 69 37 37
> www.activisu.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 API for warnings

2016-04-12 Thread Ruslan Baratov via cmake-developers


On 13-Apr-16 01:00, Brad King wrote:

Hi Ruslo,

Sorry for taking so long to respond here.  I've been hoping to find time
to think through the design deeply but I don't know when that may happen.
Here is some more feedback.  I invite others to jump in here.  Without
more interest I'm hesitant to proceed.

On 04/05/2016 02:03 PM, Ruslan Baratov wrote:

Report an error in case of any type of conflicts.

Yes.


new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this.

I'd prefer to avoid extra knobs if possible.

Okay, what about CMake warning for developer? (cmake -Wdev/cmake -Wno-dev)




You mean this:

  compatibility-c++98=off
  inline=off
  special-members=off
  catch-semantic-changed=off
  covered-switch-default=off
  inherits-via-dominance=off
  name-length-exceeded=off
  padded=off
  this-used-in-init=off
  EVERYTHING=on
  EVERYTHING=error

versus this one:

  DISABLE
compatibility-c++98
inline
special-members
catch-semantic-changed
covered-switch-default
inherits-via-dominance
name-length-exceeded
padded
this-used-in-init
  ENABLE
EVERYTHING
  TREAT_AS_ERROR
EVERYTHING

Consider examples where we don't have the full list ahead of time and
are instead appending.

-


   Or, what if we want to check the current property
value to see if some setting is already present?

What do you mean?


   Compilers use flags like

   -Wxyz -Wno-abc -Whjk=error

and not

   -WDISABLE $w1 $w2 -WENABLE $w3 $w4
I don't think the reason of approach used in compilers is about been 
convenient for user to analyze command line flags. CMake can do much 
better job here.
All I'm trying to say about ENABLE/DISABLE lists is that if user will 
have N warnings to enable and M warnings to disable he will not write N 
times *=on and M times *=off and probably will just create helper functions:


function(enable_warnings_list ...)
  foreach(warning ...)
list(APPEND result ${warning}=on)
  endforeach()
endif()

So instead of writing extra different modules by a lot of developers why 
not support this from the box?




so IMO the individual values are easier to reason about.  Also one could
imagine having the value come from a generator expression, e.g.

foo=$
As far as I understand we should allow on/off/error, so effectively it 
will be:


foo=$<$:off>$<$:error>

so how about this:

   compile_warnings(DISABLE foo CONFIGURATION Debug)
   compile_warnings(ERROR foo CONFIGURATION NOT Debug)

?




I'd like to find another name that captures the idea of enabling most warnings.

Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?

I don't think "everything" or "all" has a meaningful implementation
available on all compilers.  I was actually saying the opposite.
We should not try to provide such an abstraction and instead have
one called "most" or "high" or something like that.
I'm pretty sure all compilers have flag to enable all kind of available 
warnings (it may not call "All", e.g. -Weverything for Clang). Even if 
there is such compiler we can use maximum level + adding extra warnings 
explicitly. There must be abstracted group that allow to enable 
everything. Also I think that LEVEL/MOST/ALL groups doesn't make a 
lot of practical sense since every compiler have different kind of 
warnings enabled by such groups, so it's not cross-platformic friendly.


Ruslo
--

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] find_package: request/proposal for better version matching support

2016-04-12 Thread Nicholas Braden

I've run into a bit of an issue with the find_package interface. Let's
say I want to use a library libsemver:

find_package(semver REQUIRED)

Now, I want my code to work even when libsemver releases new versions
with breaking API changes, and I happen to know they follow the
semantic versioning system. So, I lock my project to any version where
the major version is 1:

find_package(semver 1 EXACT REQUIRED)

This works for a while, but then I discover that version 1.0 is not
sufficient and I need at least version 1.1 - but there's a problem.
There are other versions after 1.1, such as 1.2, which contain new
features and bug fixes that many users will want, but I still want to
let my users use 1.1 if that's all they have installed on their system
and/or they cannot upgrade to the newer versions.

If I write `find_package(semver 1.1 REQUIRED)`, this allows it to find
version 2 which has breaking API changes and will not allow my project
to compile.

If I write `find_package(semver 1.1 EXACT REQUIRED)` this does not
allow it to find version 1.2 which my users may want to use for the
new features and bug fixes.

I don't currently see any direct way to say that the major version
must be 'exact' and the minor version must be 'at least'. The only
options I see are messy - for example, writing my own find module
instead of using the existing one provided by libsemver, or trying to
optionally find each known minor version in order of preference.
Neither of these is a good option because it now forces my project to
stay in sync with libsemver. As a result, the latter option will not
allow me to go back to previous commits and try to compile them
because their version lists will be out of date, and the former option
will require me to manually keep my find module in sync with
libsemver's find module by constantly patching it with the version
hack instead of just simply copying it without changes.

So it seems I am stuck between a rock and a hard place. If there is a
better alternative or a way around this I don't know of, please
enlighten me. I have done some thinking on this and I believe I have
thought of a good way to fix this problem while retaining
compatibility in CMake - that is, I know the general idea of what I
would need to change in CMake itself and would be willing to create
such a patch if it were simple enough. However, I want feedback before
I go any further - this is my idea:

Instead of only allowing EXACT in find_package, which requires all the
specified version numbers to match (or whatever custom logic the find
module uses), I would make it so you could instead specify one of
EXACT_MAJOR, EXACT_MINOR, EXACT_PATCH, or EXACT_TWEAK. For example:

find_package(semver 1.1 EXACT_MAJOR REQUIRED)

The above would require the major version to be exactly 1, but the
minor version need only be at least 1. Thus, 2.0 would not match, but
1.1 and 1.2 would.

find_package(semver 1.2.3 EXACT_MINOR REQUIRED)

The above would require the major version to be exactly 1, the minor
version to be exactly 2, and the patch version to be at least 3.
EXACT_MAJOR is implicitly set.

Of course, implementing this in CMake itself would not be the end of
the story - this would also require that the find module be aware of
the new options. For existing find modules, they would behave as if
EXACT were specified, and would need to be manually updated to account
for the new EXACT_* options. But, EXACT would still be a valid option
to use, so existing projects need not update all their find_package
calls, and find modules don't need to be updated if nobody wants to
support the new functionality.

If you are wondering about edge cases, I have already thought of some
and know how to deal with them - for example, `find_package(semver 1.1
EXACT_TWEAK REQUIRED)` would issue either an error or warning (not
sure which is better). I think edge case discussion would be better
suited to when/if this is actually being implemented - for now I just
want general feedback. The basic functionality within CMake would
probably be simple to implement (I assume), but CMake has a lot of
find modules included with it that would need to be individually
updated to support the new functionality, and I'm not sure if that
should be in the same patch or not.

Any feedback on this subject would be great - I'd love to resolve this
problem or, even better, find out it isn't a problem in the first
place. Again, if implementing the changes aren't too complicated I
would even be willing to do the work and create the patch myself. I
have implemented find modules with good versioning support myself and
am familiar with how they work from that perspective, but I don't know
how the internals of CMake look.

About package config files - I'm really not sure what to do here,
because the documentation for them explicitly states "When multiple
package configuration files are available whose version files claim
compatibility with the version requested it is unspecified which

Re: [CMake] Documenting CMakeLists.txt and custom or local .cmake files

2016-04-12 Thread Philip Miller

I was hoping to get a little guidance on my question of how to document my 
CMakeLists.txt and other .cmake files. Any suggestions of how, as a cmake user, 
one may take advantage of the sphinx documentation scheme that cmake uses for 
its documentation?

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Philip Miller
Sent: Wednesday, April 06, 2016 10:52 PM
To: cmake@cmake.org
Subject: [CMake] Documenting CMakeLists.txt and custom or local .cmake files

Two days ago I posted this question on StackOverflow, 
http://stackoverflow.com/q/36415261/3154588. I have not gotten an answer there, 
so I thought I would ask on this list. 

What are good ways to document my project ``CMakeLists.txt`` files and local 
project ``.cmake`` files? There is a two year old question/answer 
http://stackoverflow.com/q/21628833/3154588 that I am essentially asking here 
again. The answer contains the statement 

> Currently, CMake 3.0 is under development which will get a new documentation 
> system based on Sphinx and reStructuredText. I guess that this will bring new 
> ways to document your modules.

I have looked at the [cmake developer 
documentation](https://cmake.org/cmake/help/v3.5/manual/cmake-developer.7.html?highlight=sphinx#id2),
 but this *new documentation system* seems geared towards the documentation of 
cmake itself. I do not see how I can use this to document my user-defined 
project ``CMakeLists.txt`` files or local ``.cmake`` files. 

I am hoping that since the cmake project internally has various sphinx 
directives and roles that there is was some way as a user I could take 
advantage of this internal usage of sphinx. I would like to be able to have 
some *markup* in my ``CMakeLists.txt`` files and local ``.cmake`` files without 
having to reinvent the wheel. There are related efforts in other projects. For 
example the ROS catkin project seems to offer the most complete approach that I 
have seen, but that is fairly heavyweight not easy to use for non-ROS projects. 
(As an example, look at their [extracted cmake api 
page](http://docs.ros.org/api/catkin/html/dev_guide/generated_cmake_api.html).) 
The simplest, is the 
[sphinx-contrib](https://bitbucket.org/birkenfeld/sphinx-contrib/) cmakedomain, 
but that relies on a separate rst source doc rather than an *autodoc* approach 
with markup comments. 

I appreciate any help.
Sincerely,
Phil
-- 

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-commits] CMake branch, master, updated. v3.5.1-439-gd0b2ec3

2016-04-12 Thread 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  d0b2ec3e713b7b90f78ec56ca4e1eebffb328b93 (commit)
  from  a2ce4e81d554fd176070893ad420a53516d016c7 (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=d0b2ec3e713b7b90f78ec56ca4e1eebffb328b93
commit d0b2ec3e713b7b90f78ec56ca4e1eebffb328b93
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Wed Apr 13 00:01:05 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Wed Apr 13 00:01:05 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b7a3d5f..1edf6b4 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 5)
-set(CMake_VERSION_PATCH 20160412)
+set(CMake_VERSION_PATCH 20160413)
 #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] Setting properties from within a function

2016-04-12 Thread Michael Surette


On 2016-04-12 06:57 PM, Tamás Kenéz wrote:

I don't get how come the macro works because
`target_compile_definitions` needs at least 3 parameters. The second one
must be PRIVATE|PUBLIC|INTERFACE.
Tamas

On Tue, Apr 12, 2016 at 7:43 AM, Michael Surette
> wrote:

I would like to use set target properties from within a function.  ie

function(MINE TGT DEF)
   target_compile_definitions("${TGT}" "${DEF}")
endfunction(MINE TGT DEF)

This doesn't work.  If I change it to a macro, it does.

macro(MINE TGT DEF)
   target_compile_definitions("${TGT}" "${DEF}")
endmacro(MINE TGT DEF)

Is there a way to extend the scope of TGT in the function so that
the function variant works?


Good catch.

Actually, I have the (usually PRIVATE) part as the beginning of ${DEF}.

To clarify, this is a question about scoping.  If the command in the 
function was a "set" I could do


set("${TGT}" "${DEF}" PARENT_SCOPE)

In my example, what I want to do is set the target_compile_definitions 
of the name "${TGT}".  A function is preferable to a macro so I can 
avoid namespace collisions.


This is not all that this function does of course, or I would just call 
target_compile_definitions directly, but I cut out the other stuff to 
simplify the example.


Upon further thought, perhaps you are on to something, let me do some 
testing.


In the meantime, any more thoughts would be appreciated.

Mike

--

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-commits] CMake branch, next, updated. v3.5.1-915-geaadfd3

2016-04-12 Thread 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  eaadfd357c9a6a438f642dd892b8bea771279a90 (commit)
   via  1d3d48110311ca68cceef70dc56f6c2ced36f68e (commit)
  from  e985c24c197f416fdf1a85a3a833e82609357841 (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=eaadfd357c9a6a438f642dd892b8bea771279a90
commit eaadfd357c9a6a438f642dd892b8bea771279a90
Merge: e985c24 1d3d481
Author: Brad King 
AuthorDate: Tue Apr 12 19:31:11 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 12 19:31:11 2016 -0400

Merge topic 'refactor-cmListFileBacktrace' into next

1d3d4811 Revert "cmState: Avoid accumulating snapshot storage for 
backtraces"


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d3d48110311ca68cceef70dc56f6c2ced36f68e
commit 1d3d48110311ca68cceef70dc56f6c2ced36f68e
Author: Brad King 
AuthorDate: Tue Apr 12 19:30:45 2016 -0400
Commit: Brad King 
CommitDate: Tue Apr 12 19:30:45 2016 -0400

Revert "cmState: Avoid accumulating snapshot storage for backtraces"

This reverts commit 6c76ede12f950cee51c10d1fb1988adab1477976.

diff --git a/Source/cmListFileCache.cxx b/Source/cmListFileCache.cxx
index 083a0e2..d5d0184 100644
--- a/Source/cmListFileCache.cxx
+++ b/Source/cmListFileCache.cxx
@@ -400,37 +400,12 @@ bool cmListFileParser::AddArgument(cmListFileLexer_Token* 
token,
 
 cmListFileBacktrace::cmListFileBacktrace(cmState::Snapshot snapshot,
  cmCommandContext const& cc)
-  : Snapshot(snapshot)
+  : Context(cc)
+  , Snapshot(snapshot)
 {
-  if (!this->Snapshot.IsValid())
+  if (this->Snapshot.IsValid())
 {
-return;
-}
-
-  // Record the entire call stack now so that the `Snapshot` we
-  // save for later refers to a long-lived scope.  This avoids
-  // having to keep short-lived scopes around just to extract
-  // their backtrace information later.
-
-  cmListFileContext lfc =
-cmListFileContext::FromCommandContext(
-  cc, this->Snapshot.GetExecutionListFile());
-  this->push_back(lfc);
-
-  cmState::Snapshot parent = this->Snapshot.GetCallStackParent();
-  while (parent.IsValid())
-{
-lfc.Name = this->Snapshot.GetEntryPointCommand();
-lfc.Line = this->Snapshot.GetEntryPointLine();
-lfc.FilePath = parent.GetExecutionListFile();
-if (lfc.FilePath.empty())
-  {
-  break;
-  }
-this->push_back(lfc);
-
-this->Snapshot = parent;
-parent = parent.GetCallStackParent();
+this->Snapshot.Keep();
 }
 }
 
@@ -440,30 +415,48 @@ cmListFileBacktrace::~cmListFileBacktrace()
 
 void cmListFileBacktrace::PrintTitle(std::ostream& out) const
 {
-  if (this->empty())
+  if (!this->Snapshot.IsValid())
 {
 return;
 }
   cmOutputConverter converter(this->Snapshot);
-  cmListFileContext lfc = this->front();
+  cmListFileContext lfc =
+  cmListFileContext::FromCommandContext(
+this->Context, this->Snapshot.GetExecutionListFile());
   lfc.FilePath = converter.Convert(lfc.FilePath, cmOutputConverter::HOME);
   out << (lfc.Line ? " at " : " in ") << lfc;
 }
 
 void cmListFileBacktrace::PrintCallStack(std::ostream& out) const
 {
-  if (this->size() <= 1)
+  if (!this->Snapshot.IsValid())
+{
+return;
+}
+  cmState::Snapshot parent = this->Snapshot.GetCallStackParent();
+  if (!parent.IsValid() || parent.GetExecutionListFile().empty())
 {
 return;
 }
-  out << "Call Stack (most recent call first):\n";
 
   cmOutputConverter converter(this->Snapshot);
-  for (const_iterator i = this->begin() + 1; i != this->end(); ++i)
+  std::string commandName = this->Snapshot.GetEntryPointCommand();
+  long commandLine = this->Snapshot.GetEntryPointLine();
+
+  out << "Call Stack (most recent call first):\n";
+  while(parent.IsValid())
 {
-cmListFileContext lfc = *i;
-lfc.FilePath = converter.Convert(lfc.FilePath, cmOutputConverter::HOME);
+cmListFileContext lfc;
+lfc.Name = commandName;
+lfc.Line = commandLine;
+
+lfc.FilePath = converter.Convert(parent.GetExecutionListFile(),
+ cmOutputConverter::HOME);
 out << "  " << lfc << "\n";
+
+commandName = parent.GetEntryPointCommand();
+commandLine = parent.GetEntryPointLine();
+parent = parent.GetCallStackParent();
 }
 }
 
diff --git a/Source/cmListFileCache.h b/Source/cmListFileCache.h
index d3cab22..4d3055f 100644
--- a/Source/cmListFileCache.h
+++ b/Source/cmListFileCache.h
@@ -87,7 +87,7 @@ struct cmListFileFunction: public

Re: [CMake] Setting properties from within a function

2016-04-12 Thread Tamás Kenéz

I don't get how come the macro works because `target_compile_definitions`
needs at least 3 parameters. The second one must be
PRIVATE|PUBLIC|INTERFACE.
Tamas

On Tue, Apr 12, 2016 at 7:43 AM, Michael Surette 
wrote:

> I would like to use set target properties from within a function.  ie
>
> function(MINE TGT DEF)
>   target_compile_definitions("${TGT}" "${DEF}")
> endfunction(MINE TGT DEF)
>
> This doesn't work.  If I change it to a macro, it does.
>
> macro(MINE TGT DEF)
>   target_compile_definitions("${TGT}" "${DEF}")
> endmacro(MINE TGT DEF)
>
> Is there a way to extend the scope of TGT in the function so that the
> function variant works?
>
> TIA
>
> Mike
>
> --
>
> 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] [CMake 0016060]: Chrome warns cmake installer is harmful program

2016-04-12 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16060 
== 
Reported By:raysatiro
Assigned To:
== 
Project:CMake
Issue ID:   16060
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-04-12 17:52 EDT
Last Modified:  2016-04-12 17:52 EDT
== 
Summary:Chrome warns cmake installer is harmful program
Description: 
Using Chrome Version 49.0.2623.112 m I'm trying to download the cmake installer:

"The site ahead contains harmful programs

Attackers on cmake.org might attempt to trick you into installing programs that
harm your browsing experience (for example, by changing your homepage or showing
extra ads on sites you visit)."



Steps to Reproduce: 
https://cmake.org/download/ and click on cmake-3.5.1-win32-x86.msi

Additional Information: 
https://www.google.com/transparencyreport/safebrowsing/diagnostic/index.html?hl=en-US#url=https://cmake.org/files/v3.5/cmake-3.5.1-win32-x86.msi
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-12 17:52 raysatiro  New Issue
2016-04-12 17:52 raysatiro  File Added: cmake chrome says harmful
programs.PNG
==

-- 

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.5.1-913-ge985c24

2016-04-12 Thread 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  e985c24c197f416fdf1a85a3a833e82609357841 (commit)
   via  6c76ede12f950cee51c10d1fb1988adab1477976 (commit)
   via  c54ed7813fa4efe2c6c95b6ba75c02b78b601a26 (commit)
   via  a2ce4e81d554fd176070893ad420a53516d016c7 (commit)
  from  6278587aaa4c450405bbb05c921c2df831540c8d (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=e985c24c197f416fdf1a85a3a833e82609357841
commit e985c24c197f416fdf1a85a3a833e82609357841
Merge: 6278587 6c76ede
Author: Brad King 
AuthorDate: Tue Apr 12 17:28:13 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 12 17:28:13 2016 -0400

Merge topic 'refactor-cmListFileBacktrace' into next

6c76ede1 cmState: Avoid accumulating snapshot storage for backtraces
c54ed781 cmState: Rename CallStack snapshots to IncludeFile
a2ce4e81 CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6c76ede12f950cee51c10d1fb1988adab1477976
commit 6c76ede12f950cee51c10d1fb1988adab1477976
Author: Brad King 
AuthorDate: Tue Apr 12 17:07:08 2016 -0400
Commit: Brad King 
CommitDate: Tue Apr 12 17:24:57 2016 -0400

cmState: Avoid accumulating snapshot storage for backtraces

Changes during post-3.3/pre-3.4 development refactored storage of most
configure-time information, including variable bindings and function
scopes.  All scopes (even short-lived) were kept persistently for
possible future debugging features, causing huge accumulated memory
usage.  This was mostly addressed by commit v3.4.1~4^2 (cmState: Avoid
accumulating snapshot storage for short-lived scopes, 2015-11-24).

Since then we still keep short-lived scopes when they are needed for a
backtrace.  This is because since commit v3.4.0-rc1~378^2
(cmListFileBacktrace: Implement in terms of cmState::Snapshot,
2015-05-29) backtraces have been lightweight objects that simply point
into the snapshot tree.  While the intention of this approach was to
avoid duplicating the call stack file path strings, the cost turned out
to be holding on to the entire call stack worth of scope snapshots,
which is much worse.

Furthermore, since commit v3.4.0-rc2~1^2 (cmIfCommand: Issue CMP0054
warning with appropriate context, 2015-10-20) all conditions used in
`if()` commands hold a backtrace for use in diagnostic messages.  Even
though the backtrace is short-lived it still causes the scope snapshot
to be kept.  This means that code like

function(foo)
  if(0)
  endif()
endfunction()

foreach(i RANGE 100)
  foo()
endforeach()

accumulates storage for the function call scope snapshots.

Fix this by partially reverting commit v3.4.0-rc1~378^2 and saving the
entire call stack during cmListFileBacktrace construction.  This way
we can avoid keeping short-lived scope snapshot storage in all cases.

diff --git a/Source/cmListFileCache.cxx b/Source/cmListFileCache.cxx
index d5d0184..083a0e2 100644
--- a/Source/cmListFileCache.cxx
+++ b/Source/cmListFileCache.cxx
@@ -400,12 +400,37 @@ bool cmListFileParser::AddArgument(cmListFileLexer_Token* 
token,
 
 cmListFileBacktrace::cmListFileBacktrace(cmState::Snapshot snapshot,
  cmCommandContext const& cc)
-  : Context(cc)
-  , Snapshot(snapshot)
+  : Snapshot(snapshot)
 {
-  if (this->Snapshot.IsValid())
+  if (!this->Snapshot.IsValid())
 {
-this->Snapshot.Keep();
+return;
+}
+
+  // Record the entire call stack now so that the `Snapshot` we
+  // save for later refers to a long-lived scope.  This avoids
+  // having to keep short-lived scopes around just to extract
+  // their backtrace information later.
+
+  cmListFileContext lfc =
+cmListFileContext::FromCommandContext(
+  cc, this->Snapshot.GetExecutionListFile());
+  this->push_back(lfc);
+
+  cmState::Snapshot parent = this->Snapshot.GetCallStackParent();
+  while (parent.IsValid())
+{
+lfc.Name = this->Snapshot.GetEntryPointCommand();
+lfc.Line = this->Snapshot.GetEntryPointLine();
+lfc.FilePath = parent.GetExecutionListFile();
+if (lfc.FilePath.empty())
+  {
+  break;
+  }
+this->push_back(lfc);
+
+this->Snapshot = parent;
+parent = parent.GetCallStackParent();
 }
 }
 
@@ -415,48 +440,30 @@ cmListFileBacktrace::~cmListFileBacktrace()
 
 void

[CMake] Automoc for a part of target sources

2016-04-12 Thread Konstantin Tokarev

Hi all,

Is it somehow possible to apply automoc-like processing to the list of files, 
not whole target?

My use case: in QtWebKit most of sources composing core targets are not related 
to Qt at all, but there are specific sources specific to Qt port. Currently I'm 
using automoc, but I suspect that it should be possible to improve incremental 
build times by reducing number of automoc'ed files.


-- 
Regards,
Konstantin
-- 

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] Automoc same source - More thoughts

2016-04-12 Thread Brad King

On 04/12/2016 03:12 PM, Sebastian Holtermann wrote:
> Here it is. Please review/commit.
> 
> To test it insert #include "moc_item.cpp" in any or many
> of the item.cpp files of the attached test project.

Thanks for working on this!

As requested in the issue tracker entry you linked,
in this comment:

  https://cmake.org/Bug/view.php?id=12873#c40513

please extend the CMake test suite with a case covering
this.  We need to test both the conflicting source name
use case and the #include "moc_..." use case.  Please
revise the patch to include such tests.

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

Re: [cmake-developers] Automoc same source - More thoughts

2016-04-12 Thread Sebastian Holtermann


Am 12.04.2016 um 17:40 schrieb Sebastian Holtermann:

Am 12.04.2016 um 13:43 schrieb Sebastian Holtermann:

Sorry for the noise.


I've stumbled over bug
https://cmake.org/Bug/view.php?id=12873
a few times now since I like to use same named data/view classes.

I've prepared a fix that generates all moc_xxx.cpp files
in the foo_automoc.dir subdirectory.




I had some more thoughts about this.

CMAKE_CURRENT_BINARY_DIR /
   foo_automoc.cpp
   foo_automoc.dir/data/moc_item.cpp
   foo_automoc.dir/view/moc_item.cpp
   foo_automoc.dir/moc_item.cpp

With directory based moc file generation it is complicated to allow
"#include " (I've never included mocs btw.).
Putting every moc directory into the target INCLUDE_DIRECTORIES
won't help because then there would be multiple moc_item.cpp
files that match "include ".
If per source INCLUDE_DIRECTORIES were possible it might work though.

My proposal is this:

- Moc files that are "#include<>"d get generated in
CMAKE_CURRENT_BINARY_DIR/moc_xxx.cpp as before but with
name collision test.

- Moc files not included but detected from
headers get generated in
CMAKE_CURRENT_BINARY_DIR/foo_automoc.dir/
with subdirectory support.
Since they're not included it doesn't matter where they are as long as
they don't overwrite each other.


I'll prepare another patch for this...



Here it is. Please review/commit.

To test it insert #include "moc_item.cpp" in any or many
of the item.cpp files of the attached test project.


Kind regards,
Sebastian Holtermann


>From cbc41b51685a4a35ceaa0763ba3f14e1ae425ad4 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann 
Date: Tue, 12 Apr 2016 20:49:50 +0200
Subject: [PATCH] Automoc generates non included mocs in dedicated directory
 with source directory tree reflection

---
 Source/cmQtAutoGenerators.cxx | 107 +++---
 Source/cmQtAutoGenerators.h   |   4 ++
 2 files changed, 104 insertions(+), 7 deletions(-)

diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index ebe08b0..1faab2d 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -93,8 +93,19 @@ static std::string extractSubDir(const std::string& absPath,
   std::string subDir;
   if (currentMoc.find_first_of('/') != std::string::npos)
 {
-subDir = absPath
-  + cmsys::SystemTools::GetFilenamePath(currentMoc) + '/';
+std::string fileNamePath = cmsys::SystemTools::GetFilenamePath(currentMoc);
+if ( fileNamePath.find ( ".." ) == std::string::npos )
+  {
+subDir = absPath + fileNamePath + '/';
+  }
+else
+  {
+  // We can't handle parent directories
+  std::cerr << "AUTOGEN: error: moc include \"" << currentMoc
+<< "\" contains parent directory reference \"..\""
+<< std::endl;
+  ::exit(EXIT_FAILURE);
+  }
 }
   return subDir;
 }
@@ -414,6 +425,9 @@ void cmQtAutoGenerators::Init()
   this->OutMocCppFilename += this->TargetName;
   this->OutMocCppFilename += ".cpp";
 
+  this->OutMocDirname += this->TargetName;
+  this->OutMocDirname += ".dir";
+
   std::vector cdefList;
   cmSystemTools::ExpandListArgument(this->MocCompileDefinitionsStr, cdefList);
   for(std::vector::const_iterator it = cdefList.begin();
@@ -589,6 +603,26 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
   std::map notIncludedMocs;
   this->ParseHeaders(headerFiles, includedMocs, notIncludedMocs, includedUis);
 
+  // Check: Look for name collisions
+{
+typedef std::map::const_iterator Iter;
+for ( Iter ita = includedMocs.begin(); ita != includedMocs.end(); ++ita )
+  {
+  Iter itb = ita;
+  ++itb;
+  for ( ; itb != includedMocs.end(); ++itb )
+{
+if ( ita->second == itb->second )
+  {
+  std::cerr << "AUTOGEN: error: moc name collision" << std::endl
+<< ita->first << " -> " << ita->second << std::endl
+<< itb->first << " -> " << itb->second << std::endl;
+  ::exit(EXIT_FAILURE);
+  }
+}
+  }
+}
+
   // run moc on all the moc's that are #included in source files
   for(std::map::const_iterator
  it = includedMocs.begin();
@@ -1104,15 +1138,14 @@ void cmQtAutoGenerators::ParseHeaders(const std::set& absHeaders,
 std::cout << "AUTOGEN: Checking " << headerName << std::endl;
 }
 
-  const std::string basename = cmsys::SystemTools::
-   GetFilenameWithoutLastExtension(headerName);
-
-  const std::string currentMoc = "moc_" + basename + ".cpp";
   std::string macroName;
   if (requiresMocing(contents, macroName))
 {
 //std::cout << "header contains Q_OBJECT macro";
-notIncludedMocs[headerName] = currentMoc;
+const std::string basename = cmsys::SystemTools::

Re: [CMake] [cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

2016-04-12 Thread Brad King

On 04/12/2016 02:54 PM, Robert Dailey wrote:
> set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} )
> 
> if( BUILD_TESTING )
> set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" )
> endif()
> 
> However this fails stating those targets do not exist.

They don't exist because they are not created until generate-time.

FYI recent changes in 'master' move ALL_BUILD into the predefined
targets folder.

> Does CMake only allow you to set properties on targets created
> directly by the scripts themselves (i.e. no built-in targets can be
> affected)?

Correct.  See above.  This is not trivial to change because the
ALL_BUILD, INSTALL, etc. targets are not normal targets.
Internally they have type GLOBAL_TARGET.  There can be *multiple*
such targets of the same name created by the generators.  Each
directory whose CMakeLists.txt file calls project(SomeName) gets
a SomeName.sln in VS, for example.  Each such .sln has a different
ALL_BUILD target with its own dependencies.  The generators can
get away with this because nothing ever looks up these targets
by name.  Therefore trying to present such targets to CMake
project code is not well-defined.

-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

Re: [cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

2016-04-12 Thread Brad King

On 04/12/2016 02:54 PM, Robert Dailey wrote:
> set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} )
> 
> if( BUILD_TESTING )
> set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" )
> endif()
> 
> However this fails stating those targets do not exist.

They don't exist because they are not created until generate-time.

FYI recent changes in 'master' move ALL_BUILD into the predefined
targets folder.

> Does CMake only allow you to set properties on targets created
> directly by the scripts themselves (i.e. no built-in targets can be
> affected)?

Correct.  See above.  This is not trivial to change because the
ALL_BUILD, INSTALL, etc. targets are not normal targets.
Internally they have type GLOBAL_TARGET.  There can be *multiple*
such targets of the same name created by the generators.  Each
directory whose CMakeLists.txt file calls project(SomeName) gets
a SomeName.sln in VS, for example.  Each such .sln has a different
ALL_BUILD target with its own dependencies.  The generators can
get away with this because nothing ever looks up these targets
by name.  Therefore trying to present such targets to CMake
project code is not well-defined.

-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-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

2016-04-12 Thread Robert Dailey

I have the following CMake code:

get_property( predefined_folder GLOBAL PROPERTY PREDEFINED_TARGETS_FOLDER )

set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} )

if( BUILD_TESTING )
set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" )
endif()

However this fails stating those targets do not exist. Is there a way
I can make this work? I'd like to organize these CMake targets in my
own way in the Visual Studio solution. There have been topics
regarding this on the mailing list in the past, but they have gone
unanswered.

Specifically, why are these targets treated as if they do not exist?
Does CMake only allow you to set properties on targets created
directly by the scripts themselves (i.e. no built-in targets can be
affected)?

I'm happy to contribute a patch to this if needed.

Thanks in advance.
-- 

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] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

2016-04-12 Thread Robert Dailey

I have the following CMake code:

get_property( predefined_folder GLOBAL PROPERTY PREDEFINED_TARGETS_FOLDER )

set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} )

if( BUILD_TESTING )
set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" )
endif()

However this fails stating those targets do not exist. Is there a way
I can make this work? I'd like to organize these CMake targets in my
own way in the Visual Studio solution. There have been topics
regarding this on the mailing list in the past, but they have gone
unanswered.

Specifically, why are these targets treated as if they do not exist?
Does CMake only allow you to set properties on targets created
directly by the scripts themselves (i.e. no built-in targets can be
affected)?

I'm happy to contribute a patch to this if needed.

Thanks in advance.
-- 

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] ASAN error

2016-04-12 Thread Aaron Boxer

Hello,
I am running on Ubuntu 15.10, with g++ 5.2.1
I have built my cmake project with ASAN and UBSAN.

When I run the ctest nightly memory check, all of my tests fail
with the error

Shadow memory range interleaves with an existing memory mapping. ASan
cannot proceed correctly. ABORTING


Has anyone encountered this? If I just run make test, then

I don't get these errors.

Thanks,

Aaron
-- 

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 API for warnings

2016-04-12 Thread Brad King

Hi Ruslo,

Sorry for taking so long to respond here.  I've been hoping to find time
to think through the design deeply but I don't know when that may happen.
Here is some more feedback.  I invite others to jump in here.  Without
more interest I'm hesitant to proceed.

On 04/05/2016 02:03 PM, Ruslan Baratov wrote:
> Report an error in case of any type of conflicts.

Yes.

> new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this.

I'd prefer to avoid extra knobs if possible.

> You mean this:
> 
>  compatibility-c++98=off
>  inline=off
>  special-members=off
>  catch-semantic-changed=off
>  covered-switch-default=off
>  inherits-via-dominance=off
>  name-length-exceeded=off
>  padded=off
>  this-used-in-init=off
>  EVERYTHING=on
>  EVERYTHING=error
> 
> versus this one:
> 
>  DISABLE
>compatibility-c++98
>inline
>special-members
>catch-semantic-changed
>covered-switch-default
>inherits-via-dominance
>name-length-exceeded
>padded
>this-used-in-init
>  ENABLE
>EVERYTHING
>  TREAT_AS_ERROR
>EVERYTHING

Consider examples where we don't have the full list ahead of time and
are instead appending.  Or, what if we want to check the current property
value to see if some setting is already present?  Compilers use flags like

  -Wxyz -Wno-abc -Whjk=error

and not

  -WDISABLE $w1 $w2 -WENABLE $w3 $w4

so IMO the individual values are easier to reason about.  Also one could
imagine having the value come from a generator expression, e.g.

   foo=$

>> I'd like to find another name that captures the idea of enabling most 
>> warnings.
> 
> Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?

I don't think "everything" or "all" has a meaningful implementation
available on all compilers.  I was actually saying the opposite.
We should not try to provide such an abstraction and instead have
one called "most" or "high" or something like that.

-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] issue with target_link_libraries and MSVC

2016-04-12 Thread Kristian

I'm not sure, but I think, you should consider 'set_target_properties'
(https://cmake.org/cmake/help/v3.0/command/set_target_properties.html).

E.g.

target_link_libraries(my_target source1.cpp source2.cpp)
set_target_properties(my_target PROPERTIES LINK_FLAGS "\openmp")



2016-04-12 17:29 GMT+02:00 Benjamin Ballet via CMake :
> I'm trying to add the openmp flag to a target with target_link_libraries.
> \openmp is interpreted as a file name and visual try to link to \openmp.obj
>
> The documentation state that target_link_libraries see an item as a flag if
> it start with - but MSVC flags start with \
>
> Is there a way to add a link flags to a target with target_link_libraries
> and MSVC ?
>
> Thank you all
>
> --
> Benjamin BALLET
> Ingénieur R
>
> ACTIVISU
> 19, rue Klock - 92110 Clichy
>> Standard Tél :  01 44 69 37 37
>> www.activisu.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
-- 

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] [CMake 0016059]: It is not possible to specify a linker different from the compiler to link a shared library

2016-04-12 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16059 
== 
Reported By:Antonio
Assigned To:
== 
Project:CMake
Issue ID:   16059
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-04-12 12:00 EDT
Last Modified:  2016-04-12 12:00 EDT
== 
Summary:It is not possible to specify a linker different
from the compiler to link a shared library
Description: 
In some situations, it might be convenient to specify a different linker than
the compiler. For example, for llvm combined with mingw, compiling with clang
and linking with gcc would work. The workaround proposed here
https://cmake.org/pipermail/cmake/2014-August/058268.html does not seem to work.

Steps to Reproduce: 
Requires 2 compilers to be there. In the attached project,
Configuring with 
D:\dummyProj\build> cmake ..\src -G "Eclipse CDT4 - Ninja"
-DCMAKE_TOOLCHAIN_FILE=..\src\Toolchain-LLVM.cmake 
-DCMAKE_LINKER=C:/Programs/mingw32_493_posix_dwarf/bin/g++.exe
-DCMAKE_CXX_LINK_EXECUTABLE="  
  -o  " 
-DCMAKE_CXX_CREATE_SHARED_LIBRARY="
  
  -o 
 "

Building will anyway lead to the following commands to be generated:
[1/2] C:\Programs\LLVM\bin\clang++.exe   -Ddummy_EXPORTS   -MMD -MT
CMakeFiles/dummy.dir/dummy.cpp.obj -MF CMakeFiles/dummy.dir/dummy.cpp.obj.d -o
CMakeFiles/dummy.dir/dummy.cpp.obj -c D:/dummyProj/src/dummy.cpp
[2/2] cmd.exe /C "cd . && C:\Programs\LLVM\bin\clang++.exe  -shared -o
libdummy.dll -Wl,--out-implib,libdummy.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
CMakeFiles/dummy.dir/dummy.cpp.obj  -lkernel32 -luser32 -lgdi32 -lwinspool
-lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
FAILED: cmd.exe /C "cd . && C:\Programs\LLVM\bin\clang++.exe  -shared -o
libdummy.dll -Wl,--out-implib,libdummy.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
CMakeFiles/dummy.dir/dummy.cpp.obj  -lkernel32 -luser32 -lgdi32 -lwinspool
-lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
C:\Programs\mingw32_493_posix_dwarf\i686-w64-mingw32\lib/libmingw32.a(lib32_libmingw32_a-pseudo-reloc.o):pseudo-reloc.c:(.text+0x1d6):
undefined reference to `__chkstk_ms'

clang++.exe: error: linker command failed with exit code 1 (use -v to see
invocation)

ninja: build stopped: subcommand failed.

The first command is correct, the second doesn't use g++ to link as desired.
Linking succeeds if g++ is replaced in the command line.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-12 12:00 AntonioNew Issue
2016-04-12 12:00 AntonioFile Added: dummyProj.zip
==

-- 

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] Automoc same source - More thoughts

2016-04-12 Thread Sebastian Holtermann


Am 12.04.2016 um 13:43 schrieb Sebastian Holtermann:

Sorry for the noise.


I've stumbled over bug
https://cmake.org/Bug/view.php?id=12873
a few times now since I like to use same named data/view classes.

I've prepared a fix that generates all moc_xxx.cpp files
in the foo_automoc.dir subdirectory.




I had some more thoughts about this.

CMAKE_CURRENT_BINARY_DIR /
  foo_automoc.cpp
  foo_automoc.dir/data/moc_item.cpp
  foo_automoc.dir/view/moc_item.cpp
  foo_automoc.dir/moc_item.cpp

With directory based moc file generation it is complicated to allow 
"#include " (I've never included mocs btw.).

Putting every moc directory into the target INCLUDE_DIRECTORIES
won't help because then there would be multiple moc_item.cpp
files that match "include ".
If per source INCLUDE_DIRECTORIES were possible it might work though.

My proposal is this:

- Moc files that are "#include<>"d get generated in
CMAKE_CURRENT_BINARY_DIR/moc_xxx.cpp as before but with
name collision test.

- Moc files not included but detected from
headers get generated in
CMAKE_CURRENT_BINARY_DIR/foo_automoc.dir/
with subdirectory support.
Since they're not included it doesn't matter where they are as long as
they don't overwrite each other.


I'll prepare another patch for this...

Kind regards,
Sebastian



--

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] issue with target_link_libraries and MSVC

2016-04-12 Thread Benjamin Ballet via CMake

I'm trying to add the openmp flag to a target with target_link_libraries.
\openmp is interpreted as a file name and visual try to link to \openmp.obj

The documentation state that target_link_libraries see an item as a flag if
it start with - but MSVC flags start with \

Is there a way to add a link flags to a target with target_link_libraries
and MSVC ?

Thank you all

-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.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

[Cmake-commits] CMake branch, next, updated. v3.5.1-909-g6278587

2016-04-12 Thread 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  6278587aaa4c450405bbb05c921c2df831540c8d (commit)
   via  f6e531bcf25cd42c87cca979b9a8a702f03d48f8 (commit)
  from  f5a877d4c6581fd83e99928bfcc0de0458350fc7 (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=6278587aaa4c450405bbb05c921c2df831540c8d
commit 6278587aaa4c450405bbb05c921c2df831540c8d
Merge: f5a877d f6e531b
Author: Brad King 
AuthorDate: Tue Apr 12 08:35:49 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 12 08:35:49 2016 -0400

Merge topic 'clang-tidy' into next

f6e531bc fixup! Add options to run clang-tidy with the compiler


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f6e531bcf25cd42c87cca979b9a8a702f03d48f8
commit f6e531bcf25cd42c87cca979b9a8a702f03d48f8
Author: Brad King 
AuthorDate: Tue Apr 12 08:35:32 2016 -0400
Commit: Brad King 
CommitDate: Tue Apr 12 08:35:32 2016 -0400

fixup! Add options to run clang-tidy with the compiler

diff --git a/Tests/RunCMake/ClangTidy/C-Build-stdout.txt 
b/Tests/RunCMake/ClangTidy/C-Build-stdout.txt
index 1bca21e..a47a2de 100644
--- a/Tests/RunCMake/ClangTidy/C-Build-stdout.txt
+++ b/Tests/RunCMake/ClangTidy/C-Build-stdout.txt
@@ -1 +1 @@
-Tests/RunCMake/ClangTidy/main\.c:0:0: warning: message \[checker\]
+Tests[/\]RunCMake[/\]ClangTidy[/\]main\.c:0:0: warning: message \[checker\]
diff --git a/Tests/RunCMake/ClangTidy/C-launch-Build-stdout.txt 
b/Tests/RunCMake/ClangTidy/C-launch-Build-stdout.txt
index 1bca21e..a47a2de 100644
--- a/Tests/RunCMake/ClangTidy/C-launch-Build-stdout.txt
+++ b/Tests/RunCMake/ClangTidy/C-launch-Build-stdout.txt
@@ -1 +1 @@
-Tests/RunCMake/ClangTidy/main\.c:0:0: warning: message \[checker\]
+Tests[/\]RunCMake[/\]ClangTidy[/\]main\.c:0:0: warning: message \[checker\]
diff --git a/Tests/RunCMake/ClangTidy/CXX-Build-stdout.txt 
b/Tests/RunCMake/ClangTidy/CXX-Build-stdout.txt
index 016b6b4..47e43af 100644
--- a/Tests/RunCMake/ClangTidy/CXX-Build-stdout.txt
+++ b/Tests/RunCMake/ClangTidy/CXX-Build-stdout.txt
@@ -1 +1 @@
-Tests/RunCMake/ClangTidy/main\.cxx:0:0: warning: message \[checker\]
+Tests[/\]RunCMake[/\]ClangTidy[/\]main\.cxx:0:0: warning: message \[checker\]
diff --git a/Tests/RunCMake/ClangTidy/CXX-launch-Build-stdout.txt 
b/Tests/RunCMake/ClangTidy/CXX-launch-Build-stdout.txt
index 016b6b4..47e43af 100644
--- a/Tests/RunCMake/ClangTidy/CXX-launch-Build-stdout.txt
+++ b/Tests/RunCMake/ClangTidy/CXX-launch-Build-stdout.txt
@@ -1 +1 @@
-Tests/RunCMake/ClangTidy/main\.cxx:0:0: warning: message \[checker\]
+Tests[/\]RunCMake[/\]ClangTidy[/\]main\.cxx:0:0: warning: message \[checker\]

---

Summary of changes:
 Tests/RunCMake/ClangTidy/C-Build-stdout.txt  |2 +-
 Tests/RunCMake/ClangTidy/C-launch-Build-stdout.txt   |2 +-
 Tests/RunCMake/ClangTidy/CXX-Build-stdout.txt|2 +-
 Tests/RunCMake/ClangTidy/CXX-launch-Build-stdout.txt |2 +-
 4 files 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] FindBoost does not detect absence of header file

2016-04-12 Thread Joachim Wuttke


FindBoost does not detect absence of header files.

To be specific: Run the following under cmake version 3.5.1:

set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
add_definitions(-DBOOST_ALL_DYN_LINK) # line is needed for MSVC
#add_definitions(-DBOOST_LIB_DIAGNOSTIC) # shows during compilation auto-linked 
libraries
if(WIN32)
set(boost_libraries_required date_time chrono program_options zlib bzip2 
iostreams system filesystem regex thread)
else()
set(boost_libraries_required date_time chrono program_options iostreams 
system filesystem regex thread)
endif()
find_package(Boost 1.48.0 COMPONENTS ${boost_libraries_required} REQUIRED)
message(STATUS "--> Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}")
message(STATUS "Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}")
message(STATUS "Boost_LIBRARIES: ${Boost_LIBRARIES}")

It will pass, even if files like /usr/include/boost/date_time.hpp  are removed
from the system.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 

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] Automoc same source name fix (proposal)

2016-04-12 Thread Sebastian Holtermann


Am 12.04.2016 um 11:57 schrieb Sebastian Holtermann:

Oops, moc_item.cpp it is.


For the attached test case you end up with


foo_automoc.cpp -- As before but includes sources below
foo_automoc.dir/data/moc_item.cpp
foo_automoc.dir/view/moc_item.cpp
foo_automoc.dir/moc_item.cpp


--

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] Automoc same source name fix (proposal)

2016-04-12 Thread Sebastian Holtermann


Hi,

I've stumbled over bug
https://cmake.org/Bug/view.php?id=12873
a few times now since I like to use same named data/view classes.

I've prepared a fix that generates all moc_xxx.cpp files
in the foo_automoc.dir subdirectory.
For the attached test case you end up with

foo_automoc.cpp -- As before but includes sources below
foo_automoc.dir/data/moc_item.cpp
foo_automoc.dir/view/moc_item.cpp
foo_automoc.dir/item.cpp

This solves the same output moc problem.

What remains though is that including "moc_foo.cpp"
does not work because of missing INCLUDE_DIRECTORIES.

Kind regards,
Sebastian Holtermann

>From cf51dcf0af4744fbb40e3bb5ad253d2514325148 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann 
Date: Tue, 12 Apr 2016 10:47:49 +0200
Subject: [PATCH] Automoc: Create moc files below foo_automoc.dir with respect
 to the source header project relative path

---
 Source/cmQtAutoGenerators.cxx | 90 ---
 Source/cmQtAutoGenerators.h   |  3 ++
 2 files changed, 80 insertions(+), 13 deletions(-)

diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index ebe08b0..69b1e3d 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -414,6 +414,9 @@ void cmQtAutoGenerators::Init()
   this->OutMocCppFilename += this->TargetName;
   this->OutMocCppFilename += ".cpp";
 
+  this->OutMocDirname += this->TargetName;
+  this->OutMocDirname += ".dir";
+
   std::vector cdefList;
   cmSystemTools::ExpandListArgument(this->MocCompileDefinitionsStr, cdefList);
   for(std::vector::const_iterator it = cdefList.begin();
@@ -637,7 +640,7 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
 {
 automocCppChanged = true;
 }
-  outStream << "#include \"" << it->second << "\"\n";
+  outStream << "#include \"" << MocPathBuildRel ( it->second ) << "\"\n";
   }
 }
 
@@ -749,7 +752,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename,
 
 if (!headerToMoc.empty())
   {
-  includedMocs[headerToMoc] = currentMoc;
+  includedMocs[headerToMoc] = MocPathIncluderRel ( absFilename, currentMoc );
   if (basename == scannedFileBasename)
 {
 mocUnderscoreIncluded = true;
@@ -826,7 +829,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename,
   dotMocIncluded = true;
   ownDotMocFile = currentMoc;
   }
-includedMocs[fileToMoc] = currentMoc;
+includedMocs[fileToMoc] = MocPathIncluderRel ( absFilename, currentMoc );
 }
   matchOffset += mocIncludeRegExp.end();
   } while(mocIncludeRegExp.find(contentsString.c_str() + matchOffset));
@@ -851,7 +854,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename,
 << scannedFileBasename << ".moc\" for compatibility with "
"strict mode (see CMAKE_AUTOMOC_RELAXED_MODE).\n"
 << std::endl;
-  includedMocs[absFilename] = ownMocUnderscoreFile;
+  includedMocs[absFilename] = MocPathIncluderRel ( absFilename, ownMocUnderscoreFile );
   includedMocs.erase(ownMocHeaderFile);
   }
 else
@@ -930,7 +933,7 @@ void cmQtAutoGenerators::StrictParseCppFile(const std::string& absFilename,
 
 if (!headerToMoc.empty())
   {
-  includedMocs[headerToMoc] = currentMoc;
+  includedMocs[headerToMoc] = MocPathIncluderRel ( absFilename, currentMoc );
   }
 else
   {
@@ -964,7 +967,7 @@ void cmQtAutoGenerators::StrictParseCppFile(const std::string& absFilename,
   ::exit(EXIT_FAILURE);
   }
 dotMocIncluded = true;
-includedMocs[absFilename] = currentMoc;
+includedMocs[absFilename] = MocPathIncluderRel ( absFilename, currentMoc );
 }
   matchOffset += mocIncludeRegExp.end();
   } while(mocIncludeRegExp.find(contentsString.c_str() + matchOffset));
@@ -1104,15 +1107,14 @@ void cmQtAutoGenerators::ParseHeaders(const std::set& absHeaders,
 std::cout << "AUTOGEN: Checking " << headerName << std::endl;
 }
 
-  const std::string basename = cmsys::SystemTools::
-   GetFilenameWithoutLastExtension(headerName);
-
-  const std::string currentMoc = "moc_" + basename + ".cpp";
   std::string macroName;
   if (requiresMocing(contents, macroName))
 {
 //std::cout << "header contains Q_OBJECT macro";
-notIncludedMocs[headerName] = currentMoc;
+const std::string basename = cmsys::SystemTools::
+ GetFilenameWithoutLastExtension(headerName);
+const std::string currentMoc = "moc_" + basename + ".cpp";
+notIncludedMocs[headerName] = MocPathIncluderRel ( headerName, currentMoc );
 }
   }
 this->ParseForUic(headerName, contents, includedUis);
@@ -1122,7 +1124,11 @@ void

Re: [CMake] issue with target_link_libraries and MSVC

Re: [cmake-developers] CMake API for warnings

[CMake] find_package: request/proposal for better version matching support

Re: [CMake] Documenting CMakeLists.txt and custom or local .cmake files

[Cmake-commits] CMake branch, master, updated. v3.5.1-439-gd0b2ec3

Re: [CMake] Setting properties from within a function

[Cmake-commits] CMake branch, next, updated. v3.5.1-915-geaadfd3

Re: [CMake] Setting properties from within a function

[cmake-developers] [CMake 0016060]: Chrome warns cmake installer is harmful program

[Cmake-commits] CMake branch, next, updated. v3.5.1-913-ge985c24

[CMake] Automoc for a part of target sources

Re: [cmake-developers] Automoc same source - More thoughts

Re: [cmake-developers] Automoc same source - More thoughts

Re: [CMake] [cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

Re: [cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

[cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

[CMake] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

[CMake] ASAN error

Re: [cmake-developers] CMake API for warnings

Re: [CMake] issue with target_link_libraries and MSVC

[cmake-developers] [CMake 0016059]: It is not possible to specify a linker different from the compiler to link a shared library

Re: [cmake-developers] Automoc same source - More thoughts

[CMake] issue with target_link_libraries and MSVC

[Cmake-commits] CMake branch, next, updated. v3.5.1-909-g6278587

[CMake] FindBoost does not detect absence of header file

Re: [cmake-developers] Automoc same source name fix (proposal)

[cmake-developers] Automoc same source name fix (proposal)

27 matches

Site Navigation

Mail list logo

Footer information