[CMake] /usr/include filtered out of include paths?

[O'Grady, Paul Christopher]

Hi,

We’re using cmake/anaconda, including the anaconda-delivered gcc7 compilers.  
As delivered by anaconda, I believe those compilers don’t search include paths 
like /usr/include and library paths like /lib64 /usr/lib64.  When I try to add 
those paths (e.g. /usr/include to cmake's target_include_directories) it 
appears to me that cmake filters them out (i.e. doesn’t put them in the list).  
I can get other paths to show up without a problem.  I’m guessing cmake is 
assuming that the compiler will add those paths automatically.  If my 
understanding is correct, is there a way I can disable this filtering?

I have a workaround where I can modify environment variables like 
CFLAGS/CXXFLAGS/LDFLAGS before running cmake, but that felt somewhat ugly.

Thanks for any thoughts you might have,

chris

-- 

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.10.0-395-g7dbeb3a

[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  7dbeb3ac5c7e0985063a5473c98fdbee102f2a4d (commit)
  from  baa19f658f947047dddac0228bcd52591829983d (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=7dbeb3ac5c7e0985063a5473c98fdbee102f2a4d
commit 7dbeb3ac5c7e0985063a5473c98fdbee102f2a4d
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Wed Nov 22 00:02:20 2017 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Wed Nov 22 00:02:20 2017 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 8b19b84..01b42b1 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 10)
-set(CMake_VERSION_PATCH 20171121)
+set(CMake_VERSION_PATCH 20171122)
 #set(CMake_VERSION_RC 1)

---

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


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

Re: [CMake] cmake 2.8.12 - How to prevent target executable having dependency to prefixed path of target shared libraries

[Alan W. Irwin]

On 2017-11-22 00:42- Couch, Kelly J wrote:


I am using cmake to build a binary with multiple shared libraries (some built 
and some on the system). I want the resulting executable to have dependencies 
on the required shared libraries (WITHOUT prefixed path to the library).

Specific build environment:
OpenSuse 11.3
cmake 2.8.12 and
gcc: i686-linux5.0-gcc (GCC) 4.6.3
g++: g++ (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]

When specifying target_link_libraries(tgtA libA), the result is a tgtA with 
library linked using a relative path to the libA. For example, when using 'ldd 
tgtA', result is something like:

...
   libpthread.so.0 => /lib/libpthread.so.0 (0xf629)
   /lib/ld-linux.so.2 (0xf7758000)
   librt.so.1 => /lib/librt.so.1 (0xf6286000)
--->directoryA/directoryB/libA.so => not found

Additional details:
1. The same cmake files work as expected on other linux distributions. It is 
only the specified config above that I encounter this issue.
2. I've various combinations of setting/NOT-setting all of these, trying to 
overcome this issue: CMAKE_BINARY_DIR, CMAKE_ARCHIVE_OUTPUT_DIRECTORY, 
CMAKE_RUNTIME_OUTPUT_DIRECTORY, CMAKE_LIBRARY_OUTPUT_DIRECTORY, 
CMAKE_SKIP_RPATH, CMAKE_SKIP_INSTALL_RPATH
3. The behavior of prefixed library occurs on libraries that are built targets 
and library found using find_library
4. when I examine resulting link.txt file, the link command line includes the path to the 
shared library (so). Why doesn't cmake use -L to express the path to look and then only pass 
the library name as -l? Looks like "g++  -o tgtA 
/directoryA/directoryB/libA.so"

I have tried all manner of changes related to RPATH options and cmake install, 
but the prefixed path to the library is always remains present. I am stumped 
and appreciate the help!


Hi Kelly:

PLplot also depends on both internally built and external libraries,
but I have absolutely no trouble with the issues you have mentioned,
and it sounds like you also don't have the problem on any Linux distro
other than this old Suse one. So I suspect the fundamental issue is
your ancient version = 2.8.12 (!) of CMake that you are attempting to
use.

So I suggest instead of fooling around with CMake-2.8.12 you try
building your project with modern CMake.  I would set a minimum
version (which sets policies) of something like CMake-3.6.2 (the
minimum I have adopted for PLplot) since most modern versions of
software distributions provide that version of CMake. When you build
your own project with modern CMake that process will likely find bugs
and issues with your own package's build system, but getting rid of
those is a good thing!

Modern cmake is obviously not packaged for your old Suse distro, but
one option is for you is to build modern CMake (with version equal to
whatever you adopt for your minimum version and/or newer) using the
bootstrap approach.  I have done that quite a lot for versions of
CMake between our minimum version and the latest (3.10.0) version, and
those builds have all been quite straightforward (and the corresponding
PLplot builds have been good as well).

Of course, another option is to upgrade your Suse distro to the latest
version.  But that is a much more intrusive change than simply
building the CMake version(s) you need for testing your software
project on that old Suse distro.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] cmake 2.8.12 - How to prevent target executable having dependency to prefixed path of target shared libraries

[Couch, Kelly J]

I am using cmake to build a binary with multiple shared libraries (some built 
and some on the system). I want the resulting executable to have dependencies 
on the required shared libraries (WITHOUT prefixed path to the library).

Specific build environment:
OpenSuse 11.3
cmake 2.8.12 and 
gcc: i686-linux5.0-gcc (GCC) 4.6.3
g++: g++ (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]

When specifying target_link_libraries(tgtA libA), the result is a tgtA with 
library linked using a relative path to the libA. For example, when using 'ldd 
tgtA', result is something like:

...
libpthread.so.0 => /lib/libpthread.so.0 (0xf629)
/lib/ld-linux.so.2 (0xf7758000)
librt.so.1 => /lib/librt.so.1 (0xf6286000)
--->directoryA/directoryB/libA.so => not found

Additional details:
1. The same cmake files work as expected on other linux distributions. It is 
only the specified config above that I encounter this issue.
2. I've various combinations of setting/NOT-setting all of these, trying to 
overcome this issue: CMAKE_BINARY_DIR, CMAKE_ARCHIVE_OUTPUT_DIRECTORY, 
CMAKE_RUNTIME_OUTPUT_DIRECTORY, CMAKE_LIBRARY_OUTPUT_DIRECTORY, 
CMAKE_SKIP_RPATH, CMAKE_SKIP_INSTALL_RPATH
3. The behavior of prefixed library occurs on libraries that are built targets 
and library found using find_library
4. when I examine resulting link.txt file, the link command line includes the 
path to the shared library (so). Why doesn't cmake use -L to express the path 
to look and then only pass the library name as -l? Looks like "g++  -o 
tgtA /directoryA/directoryB/libA.so"

I have tried all manner of changes related to RPATH options and cmake install, 
but the prefixed path to the library is always remains present. I am stumped 
and appreciate the help!

Thanks,
-Kelly

-- 

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] Which version of NSIS to use with CMake's CPack ?

[Nicholas Yue]

Hi,

  Is there a recommended version of NSIS which works best with CMake's
CPack ?

Cheers
-- 

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] Using find_package() portably?

[Konstantin Tokarev]

> Using ExternalProject and a dependency fetching script suffer from the
> same problem. It is very easy to implement these things insecurely,
> and it makes your software hard to package for Linux distributions.
> When I see a trendy new project that prominently features a "curl |
> sh" line on its webpage I shudder and, try as I might, I usually write
> it off in my mind. Besides those lines sometimes not having "https://;
> in them,

You should check sha256 of all downloaded files. It really guarantees that
files were not tampered, unlike that "s" letter in the URL after "http" which
only checks that peer's TLS certificate looks okay.


> installing software outside of your package manager will
> eventually lead to a slew of problems (developers that focus on one or
> two projects may never experience those problems, but that is almost
> entirely luck).

This is not the case if done carefully, and is not relevant at all if 
dependencies
are not installed into system location

-- 
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] Using find_package() portably?

[R0b0t1]

Hello friends!

The points brought up are good. However, I have some experience with
CMake's edge cases (due to using Gentoo) so I feel like I should give
my opinion on some of the solutions. The solutions are good, I just
think it is important to indicate that building truly cross platform
code with CMake still seems to be an open problem.

Specifically, if anyone has anything to add on how to use CMake to
find Windows dependencies, I am looking for help in that area.


On Tue, Nov 21, 2017 at 5:36 AM, Konstantin Tokarev  wrote:
>
>
> 21.11.2017, 13:45, "Johannes Zarl-Zierl" :
>> Hi,
>>
>> I thought you might want some context for the suggestions:
>>
>> On Dienstag, 21. November 2017 11:45:43 CET Konstantin Tokarev wrote:
>>>  1) add instruction how to install dependencies
>>
>> This is what many/most projects do, and it works reasonably well.
>> Advantages:
>>  - You don't clutter your project with dependencies
>>  - People on each platform already know how to install dependencies
>>  - You don't complicate things for package maintainers
>> Disadvantages:
>>  - No automatic dependency resolution
>>

This is really the best solution on Unix-based operating systems and
will work in the vast majority of cases. The one sticking point is
that most FOSS libraries are not distributed by installer for Windows
anymore, and it is extremely likely you will need to bundle your
dependencies with your project when targeting Windows.

Also, sometimes fringe distributions will not have their library
install locations in the paths checked by CMake. Usually they will
have pkg-config configured properly, and you can find the libraries
and headers that way.

>>>  2) use hand-made script or more complex solution to automate dependency
>>>  installation, or
>>
>> Hand-made scripts are often a maintenance nightmare and hard to get right for
>> all platforms. The One True Way(TM) would be a so-called "super-build", i.e. 
>> a
>> CMake project that uses external_project() to build your project along with
>> its dependencies.
>
> FWIW I've seen many projects that provide scripts or one-liners how to 
> install all
> dependencies on popular systems, and if things are readily available or 
> otherwise pre-built
> and downloadable from central place, it's not hard to maintain, at least when 
> number of
> dependencies is small
>

>>
>>>  3) avoid using find_package() st all
>>
>> That's the first time I've heard that suggestion. I'm not sure if this will
>> ease your pain ;-)
>
> I've meant by using things like ExternalProject, or from your point 4, or when
> using other metabuilders. When all dependencies are in known locations,
> you don't really need to use find_package anymore.
>
> Though It may be handy though if you allow building with both external and
> internal dependencies, e.g. if you develop open source project distributors
> will be reluctant to include it if it can use bundled dependencies only.
>

Using ExternalProject and a dependency fetching script suffer from the
same problem. It is very easy to implement these things insecurely,
and it makes your software hard to package for Linux distributions.
When I see a trendy new project that prominently features a "curl |
sh" line on its webpage I shudder and, try as I might, I usually write
it off in my mind. Besides those lines sometimes not having "https://;
in them, installing software outside of your package manager will
eventually lead to a slew of problems (developers that focus on one or
two projects may never experience those problems, but that is almost
entirely luck).

I think there are two major examples I can give:

1) Haskell's Cabal would fetch code (some immediately executed but
also the packages) over HTTP with no authentication, and that code
would often run as root. This has only recently been fixed, but I
still feel like I need to double check myself.

2) Sage Math bundles, I think, 80 pieces of software with it, and has
its own package management system. It builds GCC to build itself! For
some of the problems that this causes, see
https://bugs.gentoo.org/201321.

I do recognize that sometimes distributions simply won't have the
libraries you need. In that case, I recommend leaving it to the user
to find a way to get those libraries. Personally I install them to
~/.local and add them to the search paths, but this is hard to do with
CMake. Sometimes users will find newer libraries in a backports
repository.

>>
>> 4) Shipping the dependency with your project (not using external_project)
>> This can sometimes be useful, but you should carefully consider the
>> implications beforehand to see if it's worth it for your project. As a rule 
>> of
>> thumb: don't do this if the dependency is readily available and/or big.
>>

I dislike doing this on principle but it's pretty common for Windows.
Sticking a deps/ directory in your repository with precompiled
libraries and the header files is an easy way to reduce the 

Re: [CMake] CMake Monthly Meeting Summary

[Cristian Adam]

On Tue, Nov 21, 2017 at 6:40 PM, Robert Maynard 
wrote:

> Sorry about this this was meant for an internal mailing list.
>
>
Please do give us an update on the part regarding C++20 modules! I think
I'm not the only
on interested in this.

Cheers,
Cristian.
-- 

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] Handling of generator expressions

[Robert Maynard]

Hi Roberto,

Can you please report this as an issue (
https://gitlab.kitware.com/cmake/cmake ) as this looks like a bug in
the way we are parsing generator expressions in target_link_libraries.
The target_link_libraries fully supports taking a list of linker flags
when it isn't part of a generator expression.

On Sun, Nov 19, 2017 at 1:16 PM, Roberto Di Remigio
 wrote:
> Hello,
> I am trying to compile the following code snippet:
>
> int main(int argc, char ** argv) {
>   int stack_array[100];
>   stack_array[1] = 0;
>   return stack_array[argc + 100]; // BOOM
> }
>
> The followin CMakeLists.txt works fine, but you can notice that
> target_compile_options takes a list, while target_link_libraries takes a
> string. Always using the string will result in a compilation error, because
> the compiler flags are passed quoted to the compiler. Always using the list
> doesn't work either, because the generator expression is evaluated as
> $<1:-fsanitize=address -fno-omit-frame-pointer> and then passed as-is to the
> linker, which doesn't know what to do with it.
> Is this supposed to be like this? If yes, what's the rationale?
> Thanks in advance!
>   Roberto
>
> cmake_minimum_required(VERSION 3.3 FATAL_ERROR)
>
> project(recipe-09 CXX)
>
> set(CMAKE_CXX_STANDARD 11)
> set(CMAKE_CXX_EXTENSIONS OFF)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
>
> list(APPEND CXX_BASIC_FLAGS "-g3" "-O1")
>
> include(CheckCXXCompilerFlag)
>
> set(ASAN_FLAGS "-fsanitize=address -fno-omit-frame-pointer")
> set(CMAKE_REQUIRED_FLAGS ${ASAN_FLAGS})
> check_cxx_compiler_flag(${ASAN_FLAGS} asan_works)
> unset(CMAKE_REQUIRED_FLAGS)
>
> add_executable(asan-example asan-example.cpp)
> string(REPLACE " " ";" _asan_flags ${ASAN_FLAGS})
> target_compile_options(asan-example
>   PUBLIC
> ${CXX_BASIC_FLAGS}
> $<$:${_asan_flags}>
>   )
> target_link_libraries(asan-example
>   PUBLIC
> $<$:${ASAN_FLAGS}>
>   )
>
> --
>
> 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.10.0-394-gbaa19f6

[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  baa19f658f947047dddac0228bcd52591829983d (commit)
   via  70f9f62da86d43c61435ea2d58782ba470d8d282 (commit)
  from  daeadde88871f4e2473ce429f459ae8d6ed0ffb8 (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=baa19f658f947047dddac0228bcd52591829983d
commit baa19f658f947047dddac0228bcd52591829983d
Merge: daeadde 70f9f62
Author: Brad King 
AuthorDate: Tue Nov 21 18:00:13 2017 +
Commit: Kitware Robot 
CommitDate: Tue Nov 21 13:00:24 2017 -0500

Merge topic 'gtest-fix-discovery'

70f9f62d GoogleTest: Fix multiple discovery on same target

Acked-by: Kitware Robot 
Merge-request: !1510


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70f9f62da86d43c61435ea2d58782ba470d8d282
commit 70f9f62da86d43c61435ea2d58782ba470d8d282
Author: Matthew Woehlke 
AuthorDate: Mon Nov 20 12:53:25 2017 -0500
Commit: Brad King 
CommitDate: Tue Nov 21 12:05:34 2017 -0500

GoogleTest: Fix multiple discovery on same target

According to the documentation, tests can be discovered for a target
multiple times by using a different prefix and/or suffix to ensure name
uniqueness. However, while this worked for gtest_add_tests, it did not
work with gtest_discover_tests because the generated file that sets up
the tests was named based only on the target name, and so subsequent
discovery from the same target would clobber earlier discovery.

Fix this by introducing a counter that records how many times discovery
has been used on a target, and use this to generate unique names of the
generated test list files.

diff --git a/Modules/GoogleTest.cmake b/Modules/GoogleTest.cmake
index 41bd1dc..3d47367 100644
--- a/Modules/GoogleTest.cmake
+++ b/Modules/GoogleTest.cmake
@@ -361,9 +361,32 @@ function(gtest_discover_tests TARGET)
 set(_TEST_LIST ${TARGET}_TESTS)
   endif()
 
+  get_property(
+has_counter
+TARGET ${TARGET}
+PROPERTY CTEST_DISCOVERED_TEST_COUNTER
+SET
+  )
+  if(has_counter)
+get_property(
+  counter
+  TARGET ${TARGET}
+  PROPERTY CTEST_DISCOVERED_TEST_COUNTER
+)
+math(EXPR counter "${counter} + 1")
+  else()
+set(counter 1)
+  endif()
+  set_property(
+TARGET ${TARGET}
+PROPERTY CTEST_DISCOVERED_TEST_COUNTER
+${counter}
+  )
+
   # Define rule to generate test list for aforementioned test executable
-  set(ctest_include_file "${CMAKE_CURRENT_BINARY_DIR}/${TARGET}_include.cmake")
-  set(ctest_tests_file "${CMAKE_CURRENT_BINARY_DIR}/${TARGET}_tests.cmake")
+  set(ctest_file_base "${CMAKE_CURRENT_BINARY_DIR}/${TARGET}[${counter}]")
+  set(ctest_include_file "${ctest_file_base}_include.cmake")
+  set(ctest_tests_file "${ctest_file_base}_tests.cmake")
   get_property(crosscompiling_emulator
 TARGET ${TARGET}
 PROPERTY CROSSCOMPILING_EMULATOR
diff --git a/Tests/RunCMake/GoogleTest/GoogleTest-test-stdout.txt 
b/Tests/RunCMake/GoogleTest/GoogleTest-test1-stdout.txt
similarity index 100%
rename from Tests/RunCMake/GoogleTest/GoogleTest-test-stdout.txt
rename to Tests/RunCMake/GoogleTest/GoogleTest-test1-stdout.txt
diff --git a/Tests/RunCMake/GoogleTest/GoogleTest-test2-stdout.txt 
b/Tests/RunCMake/GoogleTest/GoogleTest-test2-stdout.txt
new file mode 100644
index 000..960c0b9
--- /dev/null
+++ b/Tests/RunCMake/GoogleTest/GoogleTest-test2-stdout.txt
@@ -0,0 +1,25 @@
+Test project .*
+Start  9: TEST:basic\.case_foo!2
+1/8 Test  #9: TEST:basic\.case_foo!2 \.+ +Passed +[0-9.]+ sec
+Start 10: TEST:basic\.case_bar!2
+2/8 Test #10: TEST:basic\.case_bar!2 \.+ +Passed +[0-9.]+ sec
+Start 11: TEST:basic\.disabled_case!2
+3/8 Test #11: TEST:basic\.disabled_case!2 \.+\*+Not Run \(Disabled\) +[0-9.]+ 
sec
+Start 12: TEST:disabled\.case!2
+4/8 Test #12: TEST:disabled\.case!2 \.+\*+Not Run \(Disabled\) +[0-9.]+ sec
+Start 13: TEST:typed/short\.case!2
+5/8 Test #13: TEST:typed/short\.case!2 \.+ +Passed +[0-9.]+ sec
+Start 14: TEST:typed/float\.case!2
+6/8 Test #14: TEST:typed/float\.case!2 \.+ +Passed +[0-9.]+ sec
+Start 15: TEST:value/test\.case/1!2
+7/8 Test #15: TEST:value/test\.case/1!2 \.+ +Passed +[0-9.]+ sec
+Start 16: TEST:value/test\.case/"foo"!2
+8/8 Test #16: TEST:value/test\.case/"foo"!2 \.+ +Passed +[0-9.]+ sec
+
+100% tests passed, 0 tests failed out of 6
+
+Total Test time \(real\) = +[0-9.]+ sec
+
+The following tests did not run:
+.*11 - TEST:basic\.disabled_case!2 \(Disabled\)

Re: [CMake] CMake Monthly Meeting Summary

[Robert Maynard]

Sorry about this this was meant for an internal mailing list.

On Tue, Nov 21, 2017 at 12:11 PM, Robert Maynard
 wrote:
> Hi,
>
> The next CMake monthly meeting will occur on Dec 5th at 10am in the
> KHQ21 Conference Room ( meet.google.com/nak-crpy-ykz ). If you want to
> be added to the calendar invite don't hesitate to send me an email.
>
> The next monthly meeting currently doesn't have a agenda yet, so
> please suggest things to talk about. Currently on my list of items to
> talk about is:
>   - Setup a group of people to investigate the amount of work needed
> to support C++20 modules
>   - Should we schedule an internal CMake course
>   - Keep working on blog articles
>
> I wrote up some CMake 3.10 highlights slides which can be found at:
> https://docs.google.com/a/kitware.com/presentation/d/1gFe2XQBS_z97SGBRDrWyp3dvtax7K2uM77Omb6rKpo0/edit?usp=sharing
>
> My goal with these slides is to have material to help people
> disseminate new CMake features other Kitware teams and a keeping
> collaborators informed. I plan on making these slides for every
> significant CMake release.
>
> As far as the blog to book goes the following action items have been 
> organized:
> - Bill is working on a blog post for December that will cover clang
> tidy / use_what_you_include support in CMake
> - Chuck/Robert/Bill are working on a CMake style guideline blog post
> which is aiming for February
-- 

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] CMake Monthly Meeting Summary

[Robert Maynard]

Hi,

The next CMake monthly meeting will occur on Dec 5th at 10am in the
KHQ21 Conference Room ( meet.google.com/nak-crpy-ykz ). If you want to
be added to the calendar invite don't hesitate to send me an email.

The next monthly meeting currently doesn't have a agenda yet, so
please suggest things to talk about. Currently on my list of items to
talk about is:
  - Setup a group of people to investigate the amount of work needed
to support C++20 modules
  - Should we schedule an internal CMake course
  - Keep working on blog articles

I wrote up some CMake 3.10 highlights slides which can be found at:
https://docs.google.com/a/kitware.com/presentation/d/1gFe2XQBS_z97SGBRDrWyp3dvtax7K2uM77Omb6rKpo0/edit?usp=sharing

My goal with these slides is to have material to help people
disseminate new CMake features other Kitware teams and a keeping
collaborators informed. I plan on making these slides for every
significant CMake release.

As far as the blog to book goes the following action items have been organized:
- Bill is working on a blog post for December that will cover clang
tidy / use_what_you_include support in CMake
- Chuck/Robert/Bill are working on a CMake style guideline blog post
which is aiming for February
-- 

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] Finding package for 7-zip comprehension

[Michael Powell]

On Tue, Nov 21, 2017 at 10:54 AM, Michael Powell  wrote:
> On Tue, Nov 21, 2017 at 10:49 AM, Michael Powell  
> wrote:
>> On Tue, Nov 21, 2017 at 10:47 AM, CHEVRIER, Marc  
>> wrote:
>>> “cmake –E tar” supports 7-zip format. Use option –format=7zip (see 
>>> https://cmake.org/cmake/help/v3.9/manual/cmake.1.html).
>>
>> Ah! This I did not know. Thanks for pointing that out!

Oh, duh. I get it. CMake has this built in.

> Well, the version of Tar I am working with does not seem to have this
> feature implemented? I could be wrong, unless it is undocumented.
>
> Based on the version (1.29?) adopted in the Git for Windows distribution.
>
> C:\Dev\Git\usr\bin\tar.exe --help | C:\Dev\Git\usr\bin\grep.exe zip
>   -j, --bzip2filter the archive through bzip2
>   --lzip filter the archive through lzip
>   -z, --gzip, --gunzip, --ungzip   filter the archive through gzip
>
> G:\Source\Boost.Build\Prototype\repos\boost-1.65.1>C:\Dev\Git\usr\bin\tar.exe 
> --
> help | C:\Dev\Git\usr\bin\grep.exe zip
>   -j, --bzip2filter the archive through bzip2
>   --lzip filter the archive through lzip
>   -z, --gzip, --gunzip, --ungzip   filter the archive through gzip
>
> C:\Dev\Git\usr\bin\tar.exe --help | C:\Dev\Git\usr\bin\grep.exe format
>   -g, --listed-incremental=FILE   handle new GNU-format incremental backup
>   -G, --incremental  handle old GNU-format incremental backup
>  set version of the sparse format to use (implies
>  extract information about file permissions
>  Archive format selection:
>   -H, --format=FORMATcreate archive of the given format
> gnu  GNU tar 1.13.x format
> oldgnu   GNU format as per tar <= 1.12
> pax  POSIX 1003.1-2001 (pax) format
> ustarPOSIX 1003.1-1988 (ustar) format
> v7   old V7 tar format
>  same as --format=v7
>   --posixsame as --format=posix
>  File name transformations:
>  Informative output:
>  show file or archive names after transformation
> --format=gnu -f- -b20 --quoting-style=escape
>
>>> On 21/11/2017 16:43, "CMake on behalf of Konstantin Tokarev" 
>>>  wrote:
>>>
>>>
>>>
>>> 21.11.2017, 18:38, "Michael Powell" :
>>> > Hello,
>>> >
>>> > Does anyone happen to know, is there 7-zip comprehension in CMake
>>> > today? i.e., that something like this could be done:
>>> >
>>> > include (FindSevenZip.cmake)
>>> >
>>> > or:
>>> >
>>> > find_package (SevenZip)
>>> >
>>> > I've seen mention of it in places, but could not find it formally as
>>> > part of CMake itself, it seems.
>>> >
>>> > I am running the latest stable v3.9, that I know of.
>>>
>>> Not exactly 7-zip, but you can unpack tar.xz files via built-in cmake 
>>> -E tar command
>>>
>>> >
>>> > Thanks!
>>> >
>>> > Cheers,
>>> >
>>> > Michael Powell
>>> > --
>>> >
>>> > 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
>>>
>>> --
>>> 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
>>>
>>>
-- 

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 

Re: [cmake-developers] custom_command and compile_commands.json

[Brad King]

On 11/21/2017 05:31 AM, Máté Ferenc Nagy-Egri via cmake-developers wrote:
> can we export custom commands into compile_commands.json?

The purpose of that file is to make compile commands available to
tools like clang-tidy.  Custom commands do not belong in it.
Its purpose has been largely superseded by first-class support
for running such tools along with the compiler, e.g.

 https://cmake.org/cmake/help/v3.10/prop_tgt/LANG_CLANG_TIDY.html

It is also not produced by all generators.

> have the relevant Visual Studio Code extensions hook into
> ... LaTeX-Workshop extensino is not.

Please explain this use case.

-Brad
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

[Cmake-commits] CMake branch, master, updated. v3.10.0-392-gdaeadde

[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  daeadde88871f4e2473ce429f459ae8d6ed0ffb8 (commit)
   via  65c5833858a92dc15978f08fe2acdf852c930ee6 (commit)
   via  8f8f118327e25a3af912b504dcb3ebad5c841818 (commit)
   via  8e7e7af5c8b3ce20a5d6d449b74b861c71f86842 (commit)
   via  9b503cc86e047fb8d9929e49f96f82f2a74af562 (commit)
   via  f81d186b156af01027e76cb8407a3ae64ad74991 (commit)
  from  e91e69cfb5a9bdb1cad7a6442913c15af88ce5ad (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=daeadde88871f4e2473ce429f459ae8d6ed0ffb8
commit daeadde88871f4e2473ce429f459ae8d6ed0ffb8
Merge: 65c5833 8e7e7af
Author: Christian Pfeiffer 
AuthorDate: Tue Nov 21 10:56:00 2017 +
Commit: Kitware Robot 
CommitDate: Tue Nov 21 05:56:03 2017 -0500

Merge topic 'irsl-intel-1041-folder'

8e7e7af5 IRSL: Install the 1041 folder for Intel compilers

Acked-by: Kitware Robot 
Merge-request: !1509


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=65c5833858a92dc15978f08fe2acdf852c930ee6
commit 65c5833858a92dc15978f08fe2acdf852c930ee6
Merge: 8f8f118 f81d186
Author: Christian Pfeiffer 
AuthorDate: Tue Nov 21 10:55:20 2017 +
Commit: Kitware Robot 
CommitDate: Tue Nov 21 05:55:40 2017 -0500

Merge topic 'findqt4-dirs-fix'

f81d186b FindQt4: Set PLUGINS and IMPORTS dir even if empty

Acked-by: Kitware Robot 
Merge-request: !1503


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8f8f118327e25a3af912b504dcb3ebad5c841818
commit 8f8f118327e25a3af912b504dcb3ebad5c841818
Merge: e91e69c 9b503cc
Author: Christian Pfeiffer 
AuthorDate: Tue Nov 21 10:55:02 2017 +
Commit: Kitware Robot 
CommitDate: Tue Nov 21 05:55:12 2017 -0500

Merge topic 'wxwidgets-env-variables'

9b503cc8 wxWidgets: Respect WX_CONFIG and WXRC_CMD env vars

Acked-by: Kitware Robot 
Merge-request: !1504


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8e7e7af5c8b3ce20a5d6d449b74b861c71f86842
commit 8e7e7af5c8b3ce20a5d6d449b74b861c71f86842
Author: Christian Pfeiffer 
AuthorDate: Mon Nov 20 16:35:02 2017 +0100
Commit: Christian Pfeiffer 
CommitDate: Mon Nov 20 16:35:02 2017 +0100

IRSL: Install the 1041 folder for Intel compilers

The presence of the `1041` seems to solely depend on whether a given
Intel compiler release was available in Japanese or not. Install it if
it is present and silently ignore it otherwise.

Example: The Intel 2018.0 release did not ship it, but the 2018.1
compilers have it.

diff --git a/Modules/InstallRequiredSystemLibraries.cmake 
b/Modules/InstallRequiredSystemLibraries.cmake
index 1ba4877..38e0861 100644
--- a/Modules/InstallRequiredSystemLibraries.cmake
+++ b/Modules/InstallRequiredSystemLibraries.cmake
@@ -594,8 +594,11 @@ if(_IRSL_HAVE_Intel)
   endif()
   if(WIN32)
 set(__install_dirs "${_Intel_redistdir}/1033")
+if(EXISTS "${_Intel_redistdir}/1041")
+  list(APPEND __install_dirs "${_Intel_redistdir}/1041")
+endif()
 if(_Intel_compiler_ver VERSION_LESS 18)
-  list(APPEND __install_dirs "${_Intel_redistdir}/irml" 
"${_Intel_redistdir}/irml_c" "${_Intel_redistdir}/1041")
+  list(APPEND __install_dirs "${_Intel_redistdir}/irml" 
"${_Intel_redistdir}/irml_c")
 endif()
 foreach(__Intel_lib IN ITEMS cilkrts20.dll libchkp.dll libgfxoffload.dll 
libioffload_host.dll libirngmd.dll
   libmmd.dll libmmdd.dll libmpx.dll liboffload.dll svml_dispmd.dll)

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b503cc86e047fb8d9929e49f96f82f2a74af562
commit 9b503cc86e047fb8d9929e49f96f82f2a74af562
Author: Christian Pfeiffer 
AuthorDate: Sun Nov 19 23:05:31 2017 +0100
Commit: Christian Pfeiffer 
CommitDate: Sun Nov 19 23:05:31 2017 +0100

wxWidgets: Respect WX_CONFIG and WXRC_CMD env vars

Issue: #17492

diff --git a/Modules/FindwxWidgets.cmake b/Modules/FindwxWidgets.cmake
index e08afe4..e21ec38 100644
--- a/Modules/FindwxWidgets.cmake
+++ b/Modules/FindwxWidgets.cmake
@@ -751,7 +751,7 @@ else()
 #-
 # Support cross-compiling, only search in the target platform.
 find_program(wxWidgets_CONFIG_EXECUTABLE
-  NAMES wx-config wx-config-3.1 wx-config-3.0 wx-config-2.9 wx-config-2.8
+  NAMES 

[Cmake-commits] CMake branch, master, updated. v3.10.0-386-ge91e69c

[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  e91e69cfb5a9bdb1cad7a6442913c15af88ce5ad (commit)
   via  35b8a26be15e625bc087d9a8a8b8b15cebf033b4 (commit)
  from  9698eef88ad50d9d470a270c26d4f7023cddcd80 (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=e91e69cfb5a9bdb1cad7a6442913c15af88ce5ad
commit e91e69cfb5a9bdb1cad7a6442913c15af88ce5ad
Merge: 9698eef 35b8a26
Author: Christian Pfeiffer 
AuthorDate: Tue Nov 21 10:54:45 2017 +
Commit: Kitware Robot 
CommitDate: Tue Nov 21 05:54:50 2017 -0500

Merge topic 'imagemagick-6-freebsd-names'

35b8a26b FindImageMagick: Add more library names

Acked-by: Kitware Robot 
Merge-request: !1505


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35b8a26be15e625bc087d9a8a8b8b15cebf033b4
commit 35b8a26be15e625bc087d9a8a8b8b15cebf033b4
Author: Christian Pfeiffer 
AuthorDate: Sun Nov 19 23:12:58 2017 +0100
Commit: Christian Pfeiffer 
CommitDate: Mon Nov 20 14:44:54 2017 +0100

FindImageMagick: Add more library names

The port maintainers on FreeBSD normalize the library names to not
include the bit and HDRI options.

Furthermore, `--quantum-depth=32` and `--quantum-depth=64` will yield
`Q32` and `Q64` suffixes in the library names.

Issue: #17492

diff --git a/Modules/FindImageMagick.cmake b/Modules/FindImageMagick.cmake
index 7d5534b..c16bbf2 100644
--- a/Modules/FindImageMagick.cmake
+++ b/Modules/FindImageMagick.cmake
@@ -196,24 +196,33 @@ foreach(component ${ImageMagick_FIND_COMPONENTS}
   if(component STREQUAL "Magick++")
 FIND_IMAGEMAGICK_API(Magick++ Magick++.h
   Magick++ CORE_RL_Magick++_
+  Magick++-6 Magick++-7
   Magick++-Q8 Magick++-Q16 Magick++-Q16HDRI Magick++-Q8HDRI
+  Magick++-6.Q64 Magick++-6.Q32 Magick++-6.Q64HDRI Magick++-6.Q32HDRI
   Magick++-6.Q16 Magick++-6.Q8 Magick++-6.Q16HDRI Magick++-6.Q8HDRI
+  Magick++-7.Q64 Magick++-7.Q32 Magick++-7.Q64HDRI Magick++-7.Q32HDRI
   Magick++-7.Q16 Magick++-7.Q8 Magick++-7.Q16HDRI Magick++-7.Q8HDRI
   )
 list(APPEND ImageMagick_REQUIRED_VARS ImageMagick_Magick++_LIBRARY)
   elseif(component STREQUAL "MagickWand")
 FIND_IMAGEMAGICK_API(MagickWand "wand/MagickWand.h;MagickWand/MagickWand.h"
   Wand MagickWand CORE_RL_wand_
+  MagickWand-6 MagickWand-7
   MagickWand-Q16 MagickWand-Q8 MagickWand-Q16HDRI MagickWand-Q8HDRI
+  MagickWand-6.Q64 MagickWand-6.Q32 MagickWand-6.Q64HDRI 
MagickWand-6.Q32HDRI
   MagickWand-6.Q16 MagickWand-6.Q8 MagickWand-6.Q16HDRI MagickWand-6.Q8HDRI
+  MagickWand-7.Q64 MagickWand-7.Q32 MagickWand-7.Q64HDRI 
MagickWand-7.Q32HDRI
   MagickWand-7.Q16 MagickWand-7.Q8 MagickWand-7.Q16HDRI MagickWand-7.Q8HDRI
   )
 list(APPEND ImageMagick_REQUIRED_VARS ImageMagick_MagickWand_LIBRARY)
   elseif(component STREQUAL "MagickCore")
 FIND_IMAGEMAGICK_API(MagickCore 
"magick/MagickCore.h;MagickCore/MagickCore.h"
   Magick MagickCore CORE_RL_magick_
+  MagickCore-6 MagickCore-7
   MagickCore-Q16 MagickCore-Q8 MagickCore-Q16HDRI MagickCore-Q8HDRI
+  MagickCore-6.Q64 MagickCore-6.Q32 MagickCore-6.Q64HDRI 
MagickCore-6.Q32HDRI
   MagickCore-6.Q16 MagickCore-6.Q8 MagickCore-6.Q16HDRI MagickCore-6.Q8HDRI
+  MagickCore-7.Q64 MagickCore-7.Q32 MagickCore-7.Q64HDRI 
MagickCore-7.Q32HDRI
   MagickCore-7.Q16 MagickCore-7.Q8 MagickCore-7.Q16HDRI MagickCore-7.Q8HDRI
   )
 list(APPEND ImageMagick_REQUIRED_VARS ImageMagick_MagickCore_LIBRARY)

---

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


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

Re: [cmake-developers] FW: [CMake] custom_command andcompile_commands.json

[Máté Ferenc Nagy-Egri via cmake-developers]

Allow me to bump this message. The question is very simple; can we export 
custom commands into compile_commands.json?

Feladó: Máté Ferenc Nagy-Egri via cmake-developers
Elküldve: 2017. november 14., kedd 10:25
Címzett: CMake Developers
Tárgy: [cmake-developers] FW: [CMake] custom_command andcompile_commands.json

This thread on the CMake users mailing list has been silent for the past week. 
I wanted to bring it over to the dev list, because there might be more 
expertise here on the subject at hand.

tl;dr: can custom_commands be exported into compile_commands.json? This is 
another projection of the problem: how to add new languages to CMake 
conveniently. If I need to make LaTeX a first-class language to make the 
export, it’s an awful lot of work only to make IDE extensions LaTeX aware (and 
I could go on with SYCL, GnuPlot, etc.).

Cheers,
Máté

Feladó: Moreland, Kenneth
Elküldve: 2017. november 6., hétfő 18:28
Címzett: Nagy-Egri Máté Ferenc
Másolatot kap: cm...@cmake.org
Tárgy: RE: [CMake] custom_command and compile_commands.json

Máté,

I don’t know anything about the CMAKE_EXPORT_COMPILE_COMMANDS feature, but I 
can attest that the UseLATEX commands are all created with add_custom_command 
(with some add_custom_target commands to set up the targets). Someone who knows 
the CMAKE_EXPORT_COMPILE_COMMANDS feature will have to answer whether it is 
possible to export custom commands.

-Ken

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Nagy-Egri Máté Ferenc 
via CMake
Sent: Sunday, November 5, 2017 11:07 AM
To: Cmake Mailing List 
Subject: [EXTERNAL] [CMake] custom_command and compile_commands.json

Hi!

I am trying to export a custom_command to the compile_commands.json database, 
but no luck up until now. The only similar question I found on the web is a 
Stackoverflow thread named „cmake clang-tidy (or other script) as custom 
target”.

I am trying to bring together C/C++ compilation, GnuPlot and LaTeX into a 
single Cmake script (done), and have the relevant Visual Studio Code extensions 
hook into the compile_commands.json file to recognize CMakes machinery and that 
they themselves are not responsible for kicking off the compilation of their 
respective source files. Microsofts C++ extension is compile_commands.json 
aware, but the LaTeX-Workshop extensino is not. I wanted to do the research 
before jumping to feature requests: is it possible to export @kmorel Github 
users UseLATEX custom_commands into the compile_commands.json database? As far 
as I saw, setting CMAKE_EXPORT_COMPILE_COMMANDS to ON right before 
add_latex_document() is not enough. Does LATEX need to be a first-class CMake 
language in order for this machinery to kick off?


Tanks in advance,
Máté


-- 

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