[Cmake-commits] CMake branch, master, updated. v3.6.0-421-g5642349

2016-07-15 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  564234912935ddb57c8553b7c9c97e8745a09ede (commit)
  from  c8e59d2dfa7cc716d11b9e32fdc6f2302e4cbe69 (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=564234912935ddb57c8553b7c9c97e8745a09ede
commit 564234912935ddb57c8553b7c9c97e8745a09ede
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sat Jul 16 00:01:04 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sat Jul 16 00:01:04 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 7ef1b4a..c9aecca 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 20160715)
+set(CMake_VERSION_PATCH 20160716)
 #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] Does Makefile generated by CMake support make -jN?

2016-07-15 Thread Gonzalo 



El 13/07/16 a las 03:21, Chaos Zhang escribió:

Thanks for your  references Decker, the condition is it cost close to three
times time after i use CMake than already exist makefile  to build project.
And i found the CPU  didn't use effectively than exist make flow, so i
wonder if CMake provide some options to use CPU more effectively.
Thanks,
Chao
If you are looking to speed up compilation times, you should switch from 
Makefiles to Ninja build files (-G Ninja).  It has a much faster 
detection of dependencies and compiles overall much faster.

--

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] find*.cmake config files, and Qt4 while cross compiling.

2016-07-15 Thread Miller Henry 
I'm going to ask two questions, but a good answer to the first will make the 
second question redundant.

I work with several different cmake projects that are cross compiled, and they 
depend on each other.  Each project creates a cmake config, so we can use 
find_package to find the contents.  Up until now we have been setting 
LINK_INTERFACE_LIBRARIES to "" SET_TARGET_PROPERTIES(${projectName} PROPERTIES 
LINK_INTERFACE_LIBRARIES ""), but for a few years this has required us to set 
CMP0022 to OLD.  Now that we no longer support older versions of CMake I 
figured it was time to set this to NEW (2.12 is minimum we use and most of us 
are up to 3.2 (I have not tried anything newer than 3.2).

This works great for libraries that provide a cmake config file when we link a 
library to libFoo the config includes the need to link to libFoo. However any 
project that we use a FindXXX.cmake to find (including cmake included like 
FindLibXml2.cmake) the package the config file says you need to link to 
/home/hank/sysroot/path/to/libFoo.  When I package this build and give it to a 
different developer to install into his sysroot it fails because the correct 
path for him is /home/joe/some/other/dir/sysroot/path/to/libFoo. I found a work 
around: in target_link_libraries make libFoo a private link.  This feels wrong 
though, I feel that cmake should handle this automatically.  (I'm fine with 
mark it as private, anything better is probably not implementable)

First question, how can I use libraries from a Find*.cmake file without having 
to mark it as private in every target_link_libraries call.

I couldn't figure this out, but I was able to mitigate it for the most common 
package we link to.  For Qt4 is you have a choice, what we were doing was:
  Find_package(Qt4 REQUIRED)
  INCLUDE(${QT_USE_FILE}
  TARGET_LINK_LIBRARIES(MyProject ${QT_LIBRARIES})
If you use this for you get the full path to each library in your sysroot.

However if you do:
  Find_package(Qt4 REQUIRED)
  TARGET_LINK_LIBRARIES(Qt4:QtGui ...)
You get just the Qt library, which would be what I want except that now the 
INCLUDE_DIRECTORIES for Qt libraries are not SYSTEM libraries and so I'm 
getting a lot of compiler warnings in qt header files which I cannot fix.

Second question: how can I use the TARGET_LINK_LIBRARIES(Qt4:QtGui...) form and 
get the qt headers as system libraries?



-- 

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] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-07-15 Thread Eon Jeong 
I wrote new patches for each of: changing usage of VERBOSE, new option
REPORT_FILE, and refactoring all of them.


0001-FindBISON-Change-usage-of-VERBOSE-file-to-VERBOSE-fi.patch
Description: Binary data


0002-FindBISON-Add-REPORT_FILE-option-to-pass-report-file.patch
Description: Binary data


0003-FindBISON-Refactor-public-and-inner-macro-routines.patch
Description: Binary data
-- 

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] OSX Code Signing best practice

2016-07-15 Thread Eric Wing 
On 7/12/16, Harry Mallon  wrote:
> Hello all,
>
> What is the current best practice for code signing OSX .apps and binaries? I
> am using:
>
> 1. MAC_OSX_BUNDLE for my .app targets.
> 2. unix style executables
> 3. dylibs
> 4. A prefpane (which I haven't got working yet) using something like the
> below:
>
> add_library(prefpane MODULE
> ${sourceFiles}
> )
>
> set_target_properties(codexprefpane PROPERTIES
> BUNDLE YES
> BUNDLE_EXTENSION prefPane
> XCODE_ATTRIBUTE_WRAPPER_EXTENSION prefPane
> MACOSX_BUNDLE_INFO_PLIST ${prefpane_plist_file}
> )
>
> I am not using the CPackBundle generator so I cannot use the signing in
> that. I have tried:
>
> 1. Using set_target_properties(  "XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY"
> "${SIGN_ID}")
> 2. Using an add_custom_command step. This code signs before all the
> Resources are copied in so the signatures are invalid
>
> Any ideas?
> Harry
>

I do something similar. I also don't use CPack and need the build
process to respect normal Xcode run/debug/profile workflows where the
app bundle is built correctly on build and not through separate CMake
target steps.

I have a add_custom_command as a POST_BUILD to copy and sign my
frameworks, dylibs, and plugins. Then I use
XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY to get Xcode to sign the rest of
the bundle through the normal Xcode mechanisms.

It works. I do find having to set the
XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY annoying. I kind of wish the CMake
generator could ignore that field and leave it to whatever the user
ends up setting (and not overwrite on every update regeneration)
because there are different identities you need depending on the
situation and changing this all the time in CMake scripts is annoying.
And I wish Xcode itself would automatically recursively sign
dependencies so I don't need to copy and sign manually.

-Eric
-- 

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] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-07-15 Thread Ben Boeckel 
On Fri, Jul 15, 2016 at 10:52:23 -0400, Brad King wrote:
> On 07/15/2016 10:45 AM, Eon Jeong wrote:
> > I considered that way, but doing this can't figure "VERBOSE" used
> > without  from never used. same empty string value.
> 
> You could hack it with something like
> 
>   if("${ARGN}" MATCHES ";VERBOSE;")
> 
> if the value comes back empty.

Avoiding regexes here would be better:

list(FIND ARGN "VERBOSE" has_verbose)

--Ben
-- 

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] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-07-15 Thread Eon Jeong 
Thanks Brad, I'll try with that hack.

Eon
-- 

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] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-07-15 Thread Brad King 
On 07/15/2016 10:45 AM, Eon Jeong wrote:
> I considered that way, but doing this can't figure "VERBOSE" used
> without  from never used. same empty string value.

You could hack it with something like

  if("${ARGN}" MATCHES ";VERBOSE;")

if the value comes back empty.

-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-872-gd0a5f23

2016-07-15 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  d0a5f2376f221009da1de5b38f997fb04f1a2e0f (commit)
   via  a6290cffaec49fc06875d6f0379af7d712b90bb3 (commit)
  from  dd96dd9740d83a1de6e7071862f09f0e8c0e38c6 (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=d0a5f2376f221009da1de5b38f997fb04f1a2e0f
commit d0a5f2376f221009da1de5b38f997fb04f1a2e0f
Merge: dd96dd9 a6290cf
Author: Brad King 
AuthorDate: Fri Jul 15 10:39:22 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jul 15 10:39:22 2016 -0400

Merge topic 'vs-natvis' into next

a6290cff VS: Add support for NATVIS files


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6290cffaec49fc06875d6f0379af7d712b90bb3
commit a6290cffaec49fc06875d6f0379af7d712b90bb3
Author: Robert Dailey 
AuthorDate: Fri Jul 15 09:19:03 2016 -0500
Commit: Brad King 
CommitDate: Fri Jul 15 10:36:21 2016 -0400

VS: Add support for NATVIS files

Add an explicit `` element in VS project files for `*.natvis`
files.  These enable custom debug visualizers for project-specific
types.

Fixes #16043.

diff --git a/Help/release/dev/vs-natvis.rst b/Help/release/dev/vs-natvis.rst
new file mode 100644
index 000..7cc9844
--- /dev/null
+++ b/Help/release/dev/vs-natvis.rst
@@ -0,0 +1,5 @@
+vs-natvis
+-
+
+* :ref:`Visual Studio Generators` for VS 2010 and above learned to
+  place ``.natvis`` source files into VS project files properly.
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx 
b/Source/cmVisualStudio10TargetGenerator.cxx
index f5bbf4d..29459db 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -1187,6 +1187,8 @@ void 
cmVisualStudio10TargetGenerator::WriteExtraSource(cmSourceFile const* sf)
 tool = "PRIResource";
   } else if (ext == "xml") {
 tool = "XML";
+  } else if (ext == "natvis") {
+tool = "Natvis";
   }
 
   if (this->NsightTegra) {

---

Summary of changes:
 Help/release/dev/vs-natvis.rst |5 +
 Source/cmVisualStudio10TargetGenerator.cxx |2 ++
 2 files changed, 7 insertions(+)
 create mode 100644 Help/release/dev/vs-natvis.rst


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

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-07-15 Thread Brad King 
On 07/15/2016 10:35 AM, Eon Jeong wrote:
> [VERBOSE []] was my hope, but it's not easy. Since FindBISON now
> uses CMakeParseArguments, a keyword can't be used both as an option
> and as a one-value keyword.

Just make it a multi-value keyword and then reject multiple values
manually after cmake_parse_arguments returns.

-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] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-07-15 Thread Eon Jeong 
2016-07-15 23:38 GMT+09:00 Brad King :
> Just make it a multi-value keyword and then reject multiple values
> manually after cmake_parse_arguments returns.

I considered that way, but doing this can't figure "VERBOSE" used
without  from never used. same empty string value.

Eon
-- 

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] Natvis support in Visual Studio

2016-07-15 Thread Brad King 
On 07/15/2016 10:23 AM, Robert Dailey wrote:
> Nice, I wasn't aware that there was already a feature in place to
> support this. Given that this exists, is there any point to adding an
> explicit code change to support natvis files?

The VS_TOOL_OVERRIDE option is nice to allow projects a path forward
for types that CMake doesn't yet support.  However, we should still
add types as needed to CMake.

> I have a simple patch attached that shows the change I've made to the code.

Applied, thanks:

 VS: Add support for NATVIS files
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6290cff

-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] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-07-15 Thread Eon Jeong 
Thank you clarifying the basic rules.

2016-07-15 22:33 GMT+09:00 Brad King :
>> 3.5. [VERBOSE []] and [REPORT_FILE ]. In this case, 
>> argument of [VERBOSE ] can be either ignored or used (copying
>> the report file.) This does not break compatibility at all
>
> I think this is the best solution.  One could also reject use of
> both  options at the same time.

[VERBOSE []] was my hope, but it's not easy. Since FindBISON now
uses CMakeParseArguments, a keyword can't be used both as an option
and as a one-value keyword.

Possible solutions are:

- Splitting [VERBOSE ] into [VERBOSE] (just `--verbose`) and
[VERBOSE_FILE ] (`--verbose` and copy). It breaks the
compatibility slightly, but I think this is an approvable break even
without REPORT_FILE because there was no choice to get just
default-named output file. In this case, "VERBOSE", "VERBOSE
REPORT_FILE " or "VERBOSE_FILE " or any combinations can
be used.

- Let [VERBOSE ] and [REPORT_FILE ] independently exist.
[VERBOSE ] means `--verbose` and copying to , and
[REPORT_FILE ] means `--report-file ` *and `--verbose`*.
cf. In bison, `--report-file ` does not imply `--verbose`.

- Extending CMakeParseArguments so a one-value keyword can be also
used as options when it's passed both in  and
. Then combinations "VERBOSE", "VERBOSE ",
"VERBOSE REPORT_FILE ", "VERBOSE  REPORT_FILE " can
be used.

- Not using CMakeParseArguments.

Sorry for making mistake. I was thinking wrong about how
CMakeParseArguments works.

Thanks,

Eon
-- 

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] Natvis support in Visual Studio

2016-07-15 Thread Robert Dailey 
On Fri, Jul 15, 2016 at 9:05 AM, Brad King  wrote:
>  VS: Add a VS_TOOL_OVERRIDE source file property
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed05f11d

Nice, I wasn't aware that there was already a feature in place to
support this. Given that this exists, is there any point to adding an
explicit code change to support natvis files?

I will install a 3.6.2 nightly build and try out that property. I like
that idea, the only downside is you lose the automatic mapping based
on file extension. I have a simple patch attached that shows the
change I've made to the code. I don't have time ATM to write a unit
test for it, but hopefully you can build onto this if you find it
valuable? Seems the change is simple based on your explanation.


0001-Support-NATVIS-files-in-VS10-generator.patch
Description: Binary data
-- 

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] Natvis support in Visual Studio

2016-07-15 Thread Brad King 
On 07/15/2016 09:47 AM, Robert Dailey wrote:
> is Kitware officially using github or gitlab? CMake exists on both

The GitLab repo is used as the issue tracker (recently migrated from Mantis).
The GitHub repo is offered as a convenience for the community but is not
the official path for contribution.  See CONTRIBUTING.rst for the documented
official contribution path.  GitLab MRs are also allowed but not documented
yet because we're still experimenting with them.

> mapped to object files and call WriteSource() on each of those.
> Currently it seems to support C, CXX, MASM, and RC language types.
> Then there is WriteExtraSources(), which I can only assume is
> "everything else". Is this correct?

Yes.  WriteSource() is for first-class language that use enable_language().
Those languages need to be supported by all generators so adding natvis to
it may not make sense.

> If I am correct, would I also be correct to assume that
> WriteExtraSource should be the one to set the XML element name
> () for *.natvis files based on LANGUAGE being set to NATVIS?

Yes.  It already has a table of VS-specific special cases checked by
file extension.  See also:

 VS: Add a VS_TOOL_OVERRIDE source file property
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed05f11d

> To add to this confusion, cmVisualStudio7Generator::WriteGroup()

That is only for VS <= 9.

> Somewhere I need to be able to automatically set the LANGUAGE property
> based on file extension.

The LANGUAGE property is meant to be set by projects.  If it is not
set then we detect the language.  We don't need to explicitly set
the property based on the extension.  I think WriteExtraSource is
the only place that needs modification for 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

Re: [cmake-developers] [PATCH] ninja: Generalize check for sysconf(3) call.

2016-07-15 Thread Brad King 
On 07/15/2016 06:46 AM, Raphael Kubo da Costa wrote:
> Commit f9644a2d ("cmGlobalNinjaGenerator: Clarify logic for forcing use
> of response files") started considering that negative command line
> length values meant forcing the use of response files.
> 
> cmNinjaNormalTargetGenerator::calculateCommandLineLength() was not
> implemented for certain operating systems

Thanks.  The problem you encountered is actually a regression in 3.6.0.
I've fixed it here:

 Ninja: Do not force response files when no sysconf(3) limit is used
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=86dd2427

and queued the change for merge to `release` for 3.6.1.

I've also applied your change on `master` for development toward 3.7:

 Ninja: Generalize check for sysconf(3) call
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5ec17e61

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-870-gdd96dd9

2016-07-15 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  dd96dd9740d83a1de6e7071862f09f0e8c0e38c6 (commit)
   via  5ec17e610609b8ca80cf8ce4f33f8c03ea48a090 (commit)
  from  26dea7c28b9eb1a747253e9e9beb3f985c1a (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=dd96dd9740d83a1de6e7071862f09f0e8c0e38c6
commit dd96dd9740d83a1de6e7071862f09f0e8c0e38c6
Merge: 26dea7c 5ec17e6
Author: Brad King 
AuthorDate: Fri Jul 15 09:51:39 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jul 15 09:51:39 2016 -0400

Merge topic 'ninja-portable-arg-max' into next

5ec17e61 Ninja: Generalize check for sysconf(3) call


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5ec17e610609b8ca80cf8ce4f33f8c03ea48a090
commit 5ec17e610609b8ca80cf8ce4f33f8c03ea48a090
Author: Raphael Kubo da Costa 
AuthorDate: Fri Jul 15 12:46:53 2016 +0200
Commit: Brad King 
CommitDate: Fri Jul 15 09:50:59 2016 -0400

Ninja: Generalize check for sysconf(3) call

Use `sysconf(_SC_ARG_MAX)` wherever `_SC_ARG_MAX` is available instead
of hard-coding an incomplete list of operating systems that implement
it.  In particular, it is available on BSD platforms that were not
previously listed.

diff --git a/Source/cmNinjaNormalTargetGenerator.cxx 
b/Source/cmNinjaNormalTargetGenerator.cxx
index 81a1618..1e83722 100644
--- a/Source/cmNinjaNormalTargetGenerator.cxx
+++ b/Source/cmNinjaNormalTargetGenerator.cxx
@@ -374,7 +374,7 @@ static int calculateCommandLineLengthLimit(int 
linkRuleLength)
 #ifdef _WIN32
 8000,
 #endif
-#if defined(__APPLE__) || defined(__HAIKU__) || defined(__linux)
+#if defined(_SC_ARG_MAX)
 // for instance ARG_MAX is 2096152 on Ubuntu or 262144 on Mac
 ((int)sysconf(_SC_ARG_MAX)) - 1000,
 #endif

---

Summary of changes:
 Source/cmNinjaNormalTargetGenerator.cxx |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-developers] Natvis support in Visual Studio

2016-07-15 Thread Robert Dailey 
Hello CMake devs,

I'm writing code to support Natvis files in Visual Studio 2015
(earlier versions support this as well, I think).

I found an issue regarding this here (is Kitware officially using
github or gitlab? CMake exists on both):
https://gitlab.kitware.com/cmake/cmake/issues/16043

Corresponding link on mantis (deprecated?):
https://cmake.org/Bug/view.php?id=16043

I have some questions. It's not straightforward on  how to implement
this. In cmVisualStudio10TargetGenerator, there is a WriteAllSources()
function which seems to do 2 main things. It seems to look up things
mapped to object files and call WriteSource() on each of those.
Currently it seems to support C, CXX, MASM, and RC language types.
Then there is WriteExtraSources(), which I can only assume is
"everything else". Is this correct?

If I am correct, would I also be correct to assume that
WriteExtraSource should be the one to set the XML element name
() for *.natvis files based on LANGUAGE being set to NATVIS?
To add to this confusion, cmVisualStudio7Generator::WriteGroup() seems
to do the file extension to LANGUAGE mapping, and I can't tell if the
VS10 generator class is also sharing this code. If it is, do I extend
that function in the VS10 generator class for *.natvis files?
Somewhere I need to be able to automatically set the LANGUAGE property
based on file extension.

Guidance is appreciated!
-- 

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] Improve FindGIF version detection (fix for issue #16196)

2016-07-15 Thread Brad King 
On 07/14/2016 06:31 PM, Ben Campbell wrote:
> new patch attached!

Thanks, looks good!  Applied and merged to `next` for testing:

 FindGIF: Detect version from GIF 4.1.6 and above
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a6c227d

Once this is merged to `master` the issue should close automatically.

-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] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-07-15 Thread Brad King 
On 07/15/2016 04:51 AM, Eon Jeong wrote:
> review past discussion on this issue.

Thanks for summarizing.

> 3.5. [VERBOSE []] and [REPORT_FILE ]. In this case, 
> argument of [VERBOSE ] can be either ignored or used (copying
> the report file.) This does not break compatibility at all

I think this is the best solution.  One could also reject use of
both  options at the same time.

> - Behavioral & syntactic compatibility of [VERBOSE ] between
> before and after the patch.

We need to remain compatible with users of [VERBOSE ].

> - If we add [REPORT_FILE ], it does not work on systems using
> bison before 2007. We may care it with custom command using `move`, or
> not.

If a project chooses to use REPORT_FILE then it is implying a dependency
on a sufficiently new version of bison, not CMake.  This is fine.

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-866-gd960645

2016-07-15 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  d9606452ce72c28ea5fad450702ad732780b1a3e (commit)
   via  0a6c227d6412b01cf2ca45cd21b90384e7fe99c3 (commit)
  from  42b2616776dca55084ef1bb1d23507e6baa2726b (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=d9606452ce72c28ea5fad450702ad732780b1a3e
commit d9606452ce72c28ea5fad450702ad732780b1a3e
Merge: 42b2616 0a6c227
Author: Brad King 
AuthorDate: Fri Jul 15 09:13:36 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jul 15 09:13:36 2016 -0400

Merge topic 'FindGIF-version' into next

0a6c227d FindGIF: Detect version from GIF 4.1.6 and above


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a6c227d6412b01cf2ca45cd21b90384e7fe99c3
commit 0a6c227d6412b01cf2ca45cd21b90384e7fe99c3
Author: Ben Campbell 
AuthorDate: Wed Jul 13 15:05:47 2016 +1200
Commit: Brad King 
CommitDate: Fri Jul 15 09:10:59 2016 -0400

FindGIF: Detect version from GIF 4.1.6 and above

GIF 4.1.6 introduced version macros in the header file.  Use them
to get a full version.

Fixes #16196.

diff --git a/Modules/FindGIF.cmake b/Modules/FindGIF.cmake
index 7bbb8cf..6fbe9e9 100644
--- a/Modules/FindGIF.cmake
+++ b/Modules/FindGIF.cmake
@@ -2,12 +2,18 @@
 # FindGIF
 # ---
 #
+# This finds the GIF library (giflib)
 #
+# The module defines the following variables:
 #
-# This module searches giflib and defines GIF_LIBRARIES - libraries to
-# link to in order to use GIF GIF_FOUND, if false, do not try to link
-# GIF_INCLUDE_DIR, where to find the headers GIF_VERSION, reports either
-# version 4 or 3 (for everything before version 4)
+# ``GIF_FOUND``
+#   True if giflib was found
+# ``GIF_LIBRARIES``
+#   Libraries to link to in order to use giflib
+# ``GIF_INCLUDE_DIR``
+#   where to find the headers
+# ``GIF_VERSION``
+#   3, 4 or a full version string (eg 5.1.4) for versions >= 4.1.6
 #
 # The minimum required version of giflib can be specified using the
 # standard syntax, e.g.  find_package(GIF 4)
@@ -29,7 +35,7 @@
 #  License text for the above reference.)
 
 # Created by Eric Wing.
-# Modifications by Alexander Neundorf
+# Modifications by Alexander Neundorf, Ben Campbell
 
 find_path(GIF_INCLUDE_DIR gif_lib.h
   HINTS
@@ -61,22 +67,40 @@ set(GIF_LIBRARIES ${GIF_LIBRARY})
 # to be always " Version 2.0, " in versions 3.x of giflib.
 # In version 4 the member UserData was added to GifFileType, so we check for 
this
 # one.
-# http://giflib.sourcearchive.com/documentation/4.1.4/files.html
+# Versions after 4.1.6 define GIFLIB_MAJOR, GIFLIB_MINOR, and GIFLIB_RELEASE
+# see http://giflib.sourceforge.net/gif_lib.html#compatibility
 if(GIF_INCLUDE_DIR)
   include(${CMAKE_CURRENT_LIST_DIR}/CMakePushCheckState.cmake)
   include(${CMAKE_CURRENT_LIST_DIR}/CheckStructHasMember.cmake)
   CMAKE_PUSH_CHECK_STATE()
   set(CMAKE_REQUIRED_QUIET ${GIF_FIND_QUIETLY})
-  set(GIF_VERSION 3)
   set(CMAKE_REQUIRED_INCLUDES "${GIF_INCLUDE_DIR}")
-  CHECK_STRUCT_HAS_MEMBER(GifFileType UserData gif_lib.h 
GIF_GifFileType_UserData )
-  if(GIF_GifFileType_UserData)
-set(GIF_VERSION 4)
+
+  # Check for the specific version defines (>=4.1.6 only)
+  file(STRINGS ${GIF_INCLUDE_DIR}/gif_lib.h _GIF_DEFS REGEX "^[ \t]*#define[ 
\t]+GIFLIB_(MAJOR|MINOR|RELEASE)")
+  if(_GIF_DEFS)
+# yay - got exact version info
+string(REGEX REPLACE ".*GIFLIB_MAJOR ([0-9]+).*" "\\1" _GIF_MAJ 
"${_GIF_DEFS}")
+string(REGEX REPLACE ".*GIFLIB_MINOR ([0-9]+).*" "\\1" _GIF_MIN 
"${_GIF_DEFS}")
+string(REGEX REPLACE ".*GIFLIB_RELEASE ([0-9]+).*" "\\1" _GIF_REL 
"${_GIF_DEFS}")
+set(GIF_VERSION "${_GIF_MAJ}.${_GIF_MIN}.${_GIF_REL}")
+  else()
+# use UserData field to sniff version instead
+CHECK_STRUCT_HAS_MEMBER(GifFileType UserData gif_lib.h 
GIF_GifFileType_UserData )
+if(GIF_GifFileType_UserData)
+  set(GIF_VERSION 4)
+else()
+  set(GIF_VERSION 3)
+endif()
   endif()
+
+  unset(_GIF_MAJ)
+  unset(_GIF_MIN)
+  unset(_GIF_REL)
+  unset(_GIF_DEFS)
   CMAKE_POP_CHECK_STATE()
 endif()
 
-
 # handle the QUIETLY and REQUIRED arguments and set GIF_FOUND to TRUE if
 # all listed variables are TRUE
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)

---

Summary of changes:
 Modules/FindGIF.cmake |   46 +++---
 1 file changed, 35 insertions(+), 11 deletions(-)


hooks/post-receive
-- 
CMake

[Cmake-commits] CMake branch, next, updated. v3.6.0-864-g42b2616

2016-07-15 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  42b2616776dca55084ef1bb1d23507e6baa2726b (commit)
   via  c8e59d2dfa7cc716d11b9e32fdc6f2302e4cbe69 (commit)
   via  595cbb493fcdbdae30ac5936c3bdfdedd75a19e7 (commit)
   via  c59ec2b7c8f24de9eceba141ae7b379806c37948 (commit)
   via  0c3fc5a2513ecf2daff2223dc26bcc4dcadf9b09 (commit)
  from  85506455c1b2cb839d65451743aba8e8fa4076f8 (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=42b2616776dca55084ef1bb1d23507e6baa2726b
commit 42b2616776dca55084ef1bb1d23507e6baa2726b
Merge: 8550645 c8e59d2
Author: Brad King 
AuthorDate: Fri Jul 15 09:04:47 2016 -0400
Commit: Brad King 
CommitDate: Fri Jul 15 09:04:47 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-415-g595cbb4

2016-07-15 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, master has been updated
   via  595cbb493fcdbdae30ac5936c3bdfdedd75a19e7 (commit)
   via  58677c327fd4a47aa88efe121f290182b44d01f5 (commit)
  from  c59ec2b7c8f24de9eceba141ae7b379806c37948 (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=595cbb493fcdbdae30ac5936c3bdfdedd75a19e7
commit 595cbb493fcdbdae30ac5936c3bdfdedd75a19e7
Merge: c59ec2b 58677c3
Author: Brad King 
AuthorDate: Fri Jul 15 09:04:27 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jul 15 09:04:27 2016 -0400

Merge topic 'fix-pq-libraries'

58677c32 FindPostgreSQL: Fix initialization of PostgreSQL_LIBRARIES


---

Summary of changes:
 Modules/FindPostgreSQL.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-420-gc8e59d2

2016-07-15 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, master has been updated
   via  c8e59d2dfa7cc716d11b9e32fdc6f2302e4cbe69 (commit)
   via  8a98cf643235a4d2869e1c876f8769b3e6bcd86f (commit)
   via  37d15c399e33f3140c1ab0259984c54084dc34f8 (commit)
   via  55c884ed3bf29069f3b74db7a0ba54ed62edb88f (commit)
   via  aec3c79acbe86a2156e3929678ef05bc2840edfa (commit)
  from  595cbb493fcdbdae30ac5936c3bdfdedd75a19e7 (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=c8e59d2dfa7cc716d11b9e32fdc6f2302e4cbe69
commit c8e59d2dfa7cc716d11b9e32fdc6f2302e4cbe69
Merge: 595cbb4 8a98cf6
Author: Brad King 
AuthorDate: Fri Jul 15 09:04:30 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jul 15 09:04:30 2016 -0400

Merge topic 'toolchain-flag-init'

8a98cf64 Honor CMAKE_*_LINKER_FLAGS[_]_INIT set in toolchain files
37d15c39 MSVC: Set all CMAKE_*_LINKER_FLAGS_INIT directly
55c884ed Embarcadero: Set all CMAKE_*_LINKER_FLAGS_INIT directly
aec3c79a Strip CMAKE_*_LINKER_FLAGS[_] initializer whitespace


---

Summary of changes:
 Help/manual/cmake-variables.7.rst  |8 +++
 Help/release/dev/toolchain-flag-init.rst   |9 +++
 .../CMAKE_EXE_LINKER_FLAGS_CONFIG_INIT.rst |   10 
 Help/variable/CMAKE_EXE_LINKER_FLAGS_INIT.rst  |   11 
 .../CMAKE_MODULE_LINKER_FLAGS_CONFIG_INIT.rst  |   10 
 Help/variable/CMAKE_MODULE_LINKER_FLAGS_INIT.rst   |   11 
 .../CMAKE_SHARED_LINKER_FLAGS_CONFIG_INIT.rst  |   10 
 Help/variable/CMAKE_SHARED_LINKER_FLAGS_INIT.rst   |   11 
 .../CMAKE_STATIC_LINKER_FLAGS_CONFIG_INIT.rst  |   10 
 Help/variable/CMAKE_STATIC_LINKER_FLAGS_INIT.rst   |   11 
 Modules/CMakeCommonLanguageInclude.cmake   |   14 +++--
 Modules/Platform/AIX-GNU.cmake |6 +-
 Modules/Platform/AIX-XL.cmake  |6 +-
 Modules/Platform/CYGWIN-GNU.cmake  |2 +-
 Modules/Platform/Windows-Embarcadero.cmake |   14 ++---
 Modules/Platform/Windows-MSVC.cmake|   47 +++
 Modules/Platform/Windows-OpenWatcom.cmake  |   10 ++--
 .../ToolchainFile/LinkFlagsInit-stdout.txt |   60 
 .../ToolchainFile/LinkFlagsInit-toolchain.cmake|5 ++
 Tests/RunCMake/ToolchainFile/LinkFlagsInit.cmake   |7 +++
 Tests/RunCMake/ToolchainFile/RunCMakeTest.cmake|1 +
 21 files changed, 219 insertions(+), 54 deletions(-)
 create mode 100644 Help/variable/CMAKE_EXE_LINKER_FLAGS_CONFIG_INIT.rst
 create mode 100644 Help/variable/CMAKE_EXE_LINKER_FLAGS_INIT.rst
 create mode 100644 Help/variable/CMAKE_MODULE_LINKER_FLAGS_CONFIG_INIT.rst
 create mode 100644 Help/variable/CMAKE_MODULE_LINKER_FLAGS_INIT.rst
 create mode 100644 Help/variable/CMAKE_SHARED_LINKER_FLAGS_CONFIG_INIT.rst
 create mode 100644 Help/variable/CMAKE_SHARED_LINKER_FLAGS_INIT.rst
 create mode 100644 Help/variable/CMAKE_STATIC_LINKER_FLAGS_CONFIG_INIT.rst
 create mode 100644 Help/variable/CMAKE_STATIC_LINKER_FLAGS_INIT.rst
 create mode 100644 Tests/RunCMake/ToolchainFile/LinkFlagsInit-stdout.txt
 create mode 100644 Tests/RunCMake/ToolchainFile/LinkFlagsInit-toolchain.cmake
 create mode 100644 Tests/RunCMake/ToolchainFile/LinkFlagsInit.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-413-gc59ec2b

2016-07-15 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, master has been updated
   via  c59ec2b7c8f24de9eceba141ae7b379806c37948 (commit)
   via  4db08807db2fc0db6ab0c4d438ddb3f20969d2fb (commit)
   via  43a68a6dcaa7a98d94a71b4f2ecc2e2c63c84688 (commit)
   via  af0e1cd4cbb7029de0877de9db72ba37085abff2 (commit)
   via  6a077b5d63895489c2962af2f7302f52444045cc (commit)
  from  0c3fc5a2513ecf2daff2223dc26bcc4dcadf9b09 (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=c59ec2b7c8f24de9eceba141ae7b379806c37948
commit c59ec2b7c8f24de9eceba141ae7b379806c37948
Merge: 0c3fc5a 4db0880
Author: Brad King 
AuthorDate: Fri Jul 15 09:04:24 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Jul 15 09:04:24 2016 -0400

Merge topic 'cmake-internal-info'

4db08807 CMake: Report whether generators support platforms
43a68a6d cmGlobalGeneratorFactory: Use CM_OVERRIDE for all derived classes
af0e1cd4 Make CMake version dirty state available to code
6a077b5d Make CMake version suffix available to code


---

Summary of changes:
 Source/CMakeVersionCompute.cmake   |   16 
 Source/CMakeVersionSource.cmake|4 +++-
 Source/cmGlobalGeneratorFactory.h  |6 ++
 Source/cmGlobalGhsMultiGenerator.h |6 ++
 Source/cmGlobalNinjaGenerator.h|6 ++
 Source/cmGlobalUnixMakefileGenerator3.h|6 ++
 Source/cmGlobalVisualStudio10Generator.cxx |   11 ++-
 Source/cmGlobalVisualStudio11Generator.cxx |   11 ++-
 Source/cmGlobalVisualStudio12Generator.cxx |   11 ++-
 Source/cmGlobalVisualStudio14Generator.cxx |   11 ++-
 Source/cmGlobalVisualStudio7Generator.h|6 ++
 Source/cmGlobalVisualStudio8Generator.cxx  |   11 ++-
 Source/cmGlobalVisualStudio9Generator.cxx  |   11 ++-
 Source/cmGlobalXCodeGenerator.cxx  |   11 ++-
 Source/cmVersionConfig.h.in|2 ++
 Source/cmake.cxx   |2 ++
 Source/cmake.h |1 +
 17 files changed, 92 insertions(+), 40 deletions(-)


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

Re: [CMake] Splitting in multiple directories

2016-07-15 Thread portolan 

Yes, it was add_subirectory.

I tried once more after cleaning up the CMakeList.txt and now it 
worksI must have ad some spurious settings generating the error.


Thanks,


Michele


Le 13/07/2016 à 22:48, Alexander Neundorf a écrit :

On Tuesday 12 July 2016 09:00:43 portolan wrote:

Hello,

I am new to Cmake and I have a pretty strange behaviour: I set my c+++
project to work with a single CMakefile.txt, and now I am trying to have
a more proper version with a .txt for each subdirectory

Pretty normal stuff, my source tree is:

 --Lib(my sources)

   --Logger   (as the name says, a logger)

  --Lib_UT  (Unitary tests for CxxTest)

  --Lib_UT_Runner  (the Cxx-generated test runner)


I have a Lib_UT/CMakefile.txt and Lib_UT_Runner/CMakefile.txt, I call
them using include_directory(Lib_UT) and


I guess you mean add_subdirectory() ?



include_directory(Lib_UT_Runner) and everything is fine (apart from the
runner executable being in a different directory)

BUT is I do the same for the logger, Lib_UT_Runner has a linking error
where it cannot link to LibLogger.so. But the shared library is
correctly generated and it is on the command line :

/usr/bin/c++  -lpthread CMakeFiles/Lib_UT_Runner.dir/Runner.cpp.o
-o Lib_UT_Runner ../Lib_UT/libLib_UT.so ../libLib.so ../libLogger.so
-lpthread
-Wl,-rpath,/home/michele/mast-devel/cmake_debug/Lib_UT:/home/michele/mast-de
vel/cmake_debug:/home/michele/mast-devel/cmake_debug/Logger

I tried using find_library, but I always get not-found


what's the error message ?

Posting relevant bits of your CMakeLists.txt (related to subdirs, creating
targets and linking) would be helpful too.

Alex



--

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] cmake 3.5 vs 3.6 + qt

2016-07-15 Thread Tom Kulaga 
Should this have changed in 3.6 I couldn't see anything in the change log?

How can I control where they are generated?

On Fri, 15 Jul 2016, 18:51 David Callu  wrote:

> Hi Tom,
>
> Same thing on my side. I call in my code functions defined in generated
> .cpp from moc/rcc.
> Functions name are based on file path used during .cpp generation.
> And this path change from cmake 3.5 to 3.6.
>
> You should check functions in generated .cpp files that you used in your
> code.
>
> HTH
> David
>
> 2016-07-15 1:54 GMT+02:00 Tom Kulaga :
>
>> Hi All,
>>
>> I'm using 3.5.2 for a qt based project and I've updated to 3.6 and the
>> RCC feature seems to fail. Here's a summary
>>
>> CMAKE settings:
>>
>> cmake_policy(SET CMP0015 NEW) # relative linker paths
>>
>> cmake_policy(SET CMP0020 NEW) # linking to qmainlib
>>
>>
>> # Tell CMake to run moc when necessary:
>>
>> set(CMAKE_AUTOMOC ON)
>>
>> set(CMAKE_AUTOUIC ON)
>>
>> set(CMAKE_AUTORCC ON)
>>
>> # As moc files are generated in the binary dir, tell CMake
>>
>> # to always look for includes there:
>>
>> set(CMAKE_INCLUDE_CURRENT_DIR ON)
>>
>>
>> When I swtiched to 3.6, the compiler can no longer link to the generated rcc 
>> files.
>>
>>
>> Anyone else face this or know what I'm doing wrong?
>>
>>
>> --
>>
>> 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
-- 

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] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-07-15 Thread Eon Jeong 
This mail is not bound to thread because of my mistake. The original
thread is [PATCH] Discussion needed: FindBISON: refine VERBOSE feature
of BISON_TARGET
.
Any review should be made on the thread.
-- 

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] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-07-15 Thread Eon Jeong 
A year passed so long to reply for a personal reason.

Adding to this list because I think it's better to review past
discussion on this issue.

So let's clearify:

1. Current [VERBOSE ] defines `--verbose`, so bison generates
foo.output from foo.y, (generating also foo.tab.c and foo.tab.h) then
cmake copies foo.output to . It's intermediate-file-and-copy as
said. It's also problematic because using [VERBOSE ] forces the
report file to be copied to some other name.

2. Since 2007, bison has `--report-file ` option that specifies
the report file name instead of foo.output. so [REPORT_FILE ] is
suggested. No intermediate file is made; so using this breaks
behavioral backward compatibility. On the other hand, some build
systems are still using bison of version before 2007.

3. There are some candidates replacing current [VERBOSE ]:

3.1. No change for our FindBISON module. `--report-file ` option
can be used via COMPILE_FLAGS. Hint this in documentation.

3.2. [VERBOSE []]. This does not break backward compatibility,
and makes someone can choose the report file is copied or not.

3.4. Just [VERBOSE] and [REPORT_FILE ]. Independently, [VERBOSE]
inserts `--verbose`, [REPORT_FILE ] inserts `--report_file
`. No more intermediate-file-and-copy, so breaking
compatibility, but the clearest solution.

3.5. [VERBOSE []] and [REPORT_FILE ]. In this case, 
argument of [VERBOSE ] can be either ignored or used (copying
the report file.) This does not break compatibility at all, but it's
dirty when [REPORT_FILE ] is cared for lower versions of bison
using `cmake -E copy` because [VERBOSE ] does the exact thing.

And many other solutions possible.

4. Issues are:

- Behavioral & syntactic compatibility of [VERBOSE ] between
before and after the patch.

- If we remove  from [VERBOSE ] so it becomes [VERBOSE],
syntactic compatibility breaks.

- If we add [REPORT_FILE ], it does not work on systems using
bison before 2007. We may care it with custom command using `move`, or
not.

These issues are about how CMake cares about the modules'
compatibility and clearness, so I need some direction.

I will make appropriate patch for the result.

Thanks,

Eon

2015-06-25 0:29 GMT+09:00 Brad King :
> On 06/24/2015 11:13 AM, 정언 wrote:
>> The copying command should be run right after each execution of bison.
>
> Yes.
>
>> However, add_custom_command never guarantees a running order of
>> internal commands. The documentation says, the commands can run
>> parallel so never ever put commands with implicit dependencies.
>
> I'm not sure what text from the documentation you're referencing,
> but I think that is warning about listing one output in multiple
> independent targets, e.g.
>
>  add_custom_command(OUTPUT out.txt ...)
>  add_custom_target(tgt1 DEPENDS out.txt)
>  add_custom_target(tgt2 DEPENDS out.txt)
>
> That is not the case here.
>
>> Again, we have two custom commands as a result of passing `VERBOSE` to
>> bison_target(). One runs bison, and the other runs cp.
>
> We only need one add_custom_command call.  It can list both outputs
> and have two COMMAND arguments.  Something like (untested):
>
>   if(...)
> set(_maybe_copy_verbose_output ${BISON_TARGET_ARG_VERBOSE})
> set(_maybe_copy_verbose_command
>   COMMAND ${CMAKE_COMMAND} -E copy 
> ${BISON_TARGET_output_path}/${BISON_TARGET_output_name}.output 
> ${BISON_TARGET_ARG_VERBOSE}
>   )
>   endif()
>
>   add_custom_command(OUTPUT ${BISON_TARGET_outputs} 
> ${_maybe_copy_verbose_output}
> ${BISON_TARGET_extraoutputs}
> COMMAND ${BISON_EXECUTABLE} ${BISON_TARGET_cmdopt} -o ${BisonOutput} 
> ${BisonInput}
> ${_maybe_copy_verbose_command}
> DEPENDS ${BisonInput}
> COMMENT "[BISON][${Name}] Building parser with bison ${BISON_VERSION}"
> WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
>
> When both COMMAND options are present they will run sequentially.
>
>> If VERBOSE behaved right, REPORT_FILE would not have any benefits over it.
>
> Wouldn't it be able to skip the intermediate file and copy step?
>
> -Brad
>



-- 
Eon Jeong 
Seoul, Rep. of Korea
Undergrad @ Dept.of Computer Science and Communication Engineering, Korea Univ.
-- 

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 3.5 vs 3.6 + qt

2016-07-15 Thread David Callu 
Hi Tom,

Same thing on my side. I call in my code functions defined in generated
.cpp from moc/rcc.
Functions name are based on file path used during .cpp generation.
And this path change from cmake 3.5 to 3.6.

You should check functions in generated .cpp files that you used in your
code.

HTH
David

2016-07-15 1:54 GMT+02:00 Tom Kulaga :

> Hi All,
>
> I'm using 3.5.2 for a qt based project and I've updated to 3.6 and the RCC
> feature seems to fail. Here's a summary
>
> CMAKE settings:
>
> cmake_policy(SET CMP0015 NEW) # relative linker paths
>
> cmake_policy(SET CMP0020 NEW) # linking to qmainlib
>
>
> # Tell CMake to run moc when necessary:
>
> set(CMAKE_AUTOMOC ON)
>
> set(CMAKE_AUTOUIC ON)
>
> set(CMAKE_AUTORCC ON)
>
> # As moc files are generated in the binary dir, tell CMake
>
> # to always look for includes there:
>
> set(CMAKE_INCLUDE_CURRENT_DIR ON)
>
>
> When I swtiched to 3.6, the compiler can no longer link to the generated rcc 
> files.
>
>
> Anyone else face this or know what I'm doing wrong?
>
>
> --
>
> 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

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-07-15 Thread Eon Jeong 
A year passed so long to reply for a personal reason.

Adding to this list because I think it's better to review past
discussion on this issue.

So let's clearify:

1. Current [VERBOSE ] defines `--verbose`, so bison generates
foo.output from foo.y, (generating also foo.tab.c and foo.tab.h) then
cmake copies foo.output to . It's intermediate-file-and-copy as
said. It's also problematic because using [VERBOSE ] forces the
report file to be copied to some other name.

2. Since 2007, bison has `--report-file ` option that specifies
the report file name instead of foo.output. so [REPORT_FILE ] is
suggested. No intermediate file is made; so using this breaks
behavioral backward compatibility. On the other hand, some build
systems are still using bison of version before 2007.

3. There are some candidates replacing current [VERBOSE ]:

3.1. No change for our FindBISON module. `--report-file ` option
can be used via COMPILE_FLAGS. Hint this in documentation.

3.2. [VERBOSE []]. This does not break backward compatibility,
and makes someone can choose the report file is copied or not.

3.4. Just [VERBOSE] and [REPORT_FILE ]. Independently, [VERBOSE]
inserts `--verbose`, [REPORT_FILE ] inserts `--report_file
`. No more intermediate-file-and-copy, so breaking
compatibility, but the clearest solution.

3.5. [VERBOSE []] and [REPORT_FILE ]. In this case, 
argument of [VERBOSE ] can be either ignored or used (copying
the report file.) This does not break compatibility at all, but it's
dirty when [REPORT_FILE ] is cared for lower versions of bison
using `cmake -E copy` because [VERBOSE ] does the exact thing.

And many other solutions possible.

4. Issues are:

- Behavioral & syntactic compatibility of [VERBOSE ] between
before and after the patch.

- If we remove  from [VERBOSE ] so it becomes [VERBOSE],
syntactic compatibility breaks.

- If we add [REPORT_FILE ], it does not work on systems using
bison before 2007. We may care it with custom command using `move`, or
not.

These issues are about how CMake cares about the modules'
compatibility and clearness, so I need some direction.

I will make appropriate patch for the result.

Thanks,

Eon

2016-07-15 17:42 GMT+09:00 Eon Jeong :
> Sorry, resending on list.
>
> 2016-07-15 17:42 GMT+09:00 Eon Jeong :
>> A year passed so long to reply for a personal reason.
>>
>> Adding to this list because I think it's better to review past
>> discussion on this issue.
>>
>> So let's clearify:
>>
>> 1. Current [VERBOSE ] defines `--verbose`, so bison generates
>> foo.output from foo.y, (generating also foo.tab.c and foo.tab.h) then
>> cmake copies foo.output to . It's intermediate-file-and-copy as
>> said. It's also problematic because using [VERBOSE ] forces the
>> report file to be copied to some other name.
>>
>> 2. Since 2007, bison has `--report-file ` option that specifies
>> the report file name instead of foo.output. so [REPORT_FILE ] is
>> suggested. No intermediate file is made; so using this breaks
>> behavioral backward compatibility. On the other hand, some build
>> systems are still using bison of version before 2007.
>>
>> 3. There are some candidates replacing current [VERBOSE ]:
>>
>> 3.1. No change for our FindBISON module. `--report-file ` option
>> can be used via COMPILE_FLAGS. Hint this in documentation.
>>
>> 3.2. [VERBOSE []]. This does not break backward compatibility,
>> and makes someone can choose the report file is copied or not.
>>
>> 3.4. Just [VERBOSE] and [REPORT_FILE ]. Independently, [VERBOSE]
>> inserts `--verbose`, [REPORT_FILE ] inserts `--report_file
>> `. No more intermediate-file-and-copy, so breaking
>> compatibility, but the clearest solution.
>>
>> 3.5. [VERBOSE []] and [REPORT_FILE ]. In this case, 
>> argument of [VERBOSE ] can be either ignored or used (copying
>> the report file.) This does not break compatibility at all, but it's
>> dirty when [REPORT_FILE ] is cared for lower versions of bison
>> using `cmake -E copy` because [VERBOSE ] does the exact thing.
>>
>> And many other solutions possible.
>>
>> 4. Issues are:
>>
>> - Behavioral & syntactic compatibility of [VERBOSE ] between
>> before and after the patch.
>>
>> - If we remove  from [VERBOSE ] so it becomes [VERBOSE],
>> syntactic compatibility breaks.
>>
>> - If we add [REPORT_FILE ], it does not work on systems using
>> bison before 2007. We may care it with custom command using `move`, or
>> not.
>>
>> These issues are about how CMake cares about the modules'
>> compatibility and clearness, so I need some direction.
>>
>> I will make appropriate patch for the result.
>>
>> Thanks,
>>
>> Eon
>>
>> 2015-06-25 0:29 GMT+09:00 Brad King :
>>> On 06/24/2015 11:13 AM, 정언 wrote:
 The copying command should be run right after each execution of bison.
>>>
>>> Yes.
>>>
 However, add_custom_command never guarantees a running order of
 internal commands. The documentation says, the commands can run
 parallel