Re: [CMake] Fake dependencies of executables to static libs

[Stephan Menzel]

Hello again,

no ideas so far? Perhaps I can elaborate. I have tried multiple approaches
over the years. Most recently adding the source files of the lib explicitly
as dependencies to the created executable.

Like this:

set (SRC
MySource1.cpp
MySource2.cpp
)

set (HDR
MySource1.hpp
MySource2.hpp
)

add_library(mylib STATIC ${SRC} ${HDR})

add_executable(myexecutable main.cpp)
target_link_libraries(myexecutable
mylib
)

add_dependencies(myexecutable ${SRC})

This leads to errors though:

CMake Error at CMakeLists.txt:79 (add_dependencies):
  The dependency target "MySource1.cpp" of target "myexecutable" does not
exist.

Obviously, I cannot simply state a filename and treat it as a target. I
have however seen something similar been done when it comes to code
generation. I have also seen explicit subtargets for files being created
and then depend on those subtargets. But I don't really know how to do this
the right way.

Alternatively I would also appreciate input about what exactly the problem
with depending on static libs is. The explanations I remember from my last
efforts to tackle this weren't really satisfying. If I understood in more
detail why this isn't possible I may be able to better craft a workaround
on my own.

Really, anything helps. I am losing time and nerve every day because of
this and have been paying this price for so many years that I think it
really is time to come up with a solution.

Cheers,
Stephan






On Tue, Apr 2, 2019 at 5:54 AM Stephan Menzel 
wrote:

> Hello List,
>
> In our projects we are using static linkage on Windows (MSVC) and Linux. A
> number of static libs are created and then linked into executables, such as
> unit tests, tools and the actual production artifacts. Very normal stuff.
>
> add_library(mylib STATIC mysources)
> add_excecutable(mytest mytest.cpp)
> target_link_libraries(mytest mylib)
>
> Now although I don't understand the exact reasons behind that, over the
> years came to accept that depedencies between the lib and the resulting
> artifcats are not working. Like, when I change a source file to mylib, the
> lib will get rebuilt but the resulting test tool won't be relinked.
> For test driven development or busy change cycles that can put quite a
> strain on effort, especially on windows. My normal workflow is that I
> always click in mytest.cpp, add and remove a space to mark it dirty as
> quickly as possible and thereby cause the rebuild. But sometimes I forget
> this and this caused me quite a bit of extra work.
> My question is, can I fake that dependency somehow? Perhaps by some hack
> or using some workaround?
>
> What I want to achieve is that when I change the lib, the unit test (or
> any other test tool using it) that depends on it will be relinked, even if
> it has not changed.
>
> Is that possible somehow?
>
> Cheers,
> Stephan
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, master, updated. v3.14.1-577-g3d6d7c1

[Kitware Robot via Cmake-commits]

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  3d6d7c170ca9ad291a0deedd125b8f9ce82d15bb (commit)
  from  6fdba8b8beb6d971a3c2efe8973cdee970dfd40a (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=3d6d7c170ca9ad291a0deedd125b8f9ce82d15bb
commit 3d6d7c170ca9ad291a0deedd125b8f9ce82d15bb
Author: Kitware Robot 
AuthorDate: Thu Apr 4 00:01:07 2019 -0400
Commit: Kitware Robot 
CommitDate: Thu Apr 4 00:01:07 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index f7c65f5..3ba392e 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 14)
-set(CMake_VERSION_PATCH 20190403)
+set(CMake_VERSION_PATCH 20190404)
 #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
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] CPack/WiX shortcuts with custom arguments

[Cook, Steven (G)]

To follow up on this, I tried creating a .bat file to run my program with the 
required command line arguments, but I was unable to add a shortcut to the .bat 
file because cmake appends ".exe" to the name of the executable in 
CPACK_PACKAGE_EXECUTABLES.

I think the only way to make it work is to create an executable that doesn't 
require command line parameters.

Steve

From: Cook, Steven (G)
Sent: Friday, 22 March 2019 11:17 AM
To: 'cmake@cmake.org' 
Subject: CPack/WiX shortcuts with custom arguments

Hi,

I'm attempting to transition from NSIS to WiX for our Windows installer and 
have been unable to find a way to create customised shortcuts with WiX (I would 
like to specify both the working directory and command line parameters).

Some approaches I've tried are:

* Specifying CPACK_PACKAGE_EXECUTABLES, and then using 
CPACK_WIX_PATCH_FILE to modify the shortcut. This approach doesn't work because 
the patching mechanism can only add new XML tags; it is unable to add or modify 
properties on existing tags.

* Creating the shortcut myself via CPACK_WIX_EXTRA_SOURCES. This 
doesn't work because PROGRAM_MENU_FOLDER is not defined in directories.wxs 
unless cpack is creating shortcuts itself. And I can't define this directory 
myself because the patching mechanism doesn't allow modifications to the top 
level TARGETDIR directory.

Ideas of things that might work but which are not ideal:

* Create an unwanted shortcut with cpack and then define my own 
shortcuts with CPACK_WIX_EXTRA_SOURCES. But then there is an unwanted shortcut.

* Create separate .bat files for each start menu item so that working 
directory and command line parameters are not required.

Is there anything else I can try?

Thanks
Steve
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Eclipse generator question

[Benjamin Shadwick]

On Wed, Apr 3, 2019 at 2:50 PM Martin Weber 
wrote:

> To implement the 'index only files referenced through the build script'
> view,
> *any* IDE would have to *interpret* the build scripts.
> Just choose an IDE that has a build script interpreter to solve your use
> case.
>
Qt Creator and Visual Studio Code (with the appropriate plugins installed)
seem to be able to do this. I now use them at home in preference over
Eclipse CDT because of this, but Eclipse CDT is currently the path of least
resistance at work.


> > cmake4eclipse are taking advantage of what modern Eclipse versions can
> do.
>
> Sounds promising. What is it that _modern Eclipse versions can do_?
>

It looks like you can compose the Eclipse project tree to look any way you
want via use of linked resources. Apparently when doing this in older
versions of Eclipse, it would break its version control integration. This
no longer seems to be the case.

When using the CMake Eclipse project generator via its default settings, I
get a "[Targets]" virtual directory in the Eclipse project that actually
shows the source files under their respective targets, in a structure that
is closer to that defined in the CMake project than what is on the
filesystem. Unfortunately it also generates a bunch of *other* garbage to
make things work in older Eclipse releases that just create a bunch of
noise in new releases that make the project almost unusable for anything
but building.
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Fwd: Eclipse generator question

[Benjamin Shadwick]

Oops, meant to send this to the mailing list, but GMail keeps trying to
divert me.

-- Forwarded message -
From: Benjamin Shadwick 
Date: Wed, Apr 3, 2019 at 2:52 PM
Subject: Re: [CMake] Eclipse generator question
To: Martin Weber 


On Wed, Apr 3, 2019 at 2:18 PM Martin Weber 
wrote:

> Am Mittwoch, 3. April 2019, 22:26:59 CEST schrieb Benjamin Shadwick:
> > I tried cmake4eclipse, and it's a mixed bag. It requires a lot of
> tweaking
>
> Really? Just set _CMake Builder (portable)_ as the current builder and
> build.
>

It required a lot more tweaking than that for an out of source build,
including manually enabling the CMAKE includes and defines providers.


> > of the Eclipse project after you create it, and I'm pretty sure it
> suffers
> > from the same problem of leaving you with an Eclipse project whose source
> > tree reflects what is in the filesystem rather than what is defined in
> the
> > CMake project.
>
> What does that mean: _an Eclipse project whose source tree reflects what
> is in
> the filesystem rather than what is defined in the CMake project._ ??
>

This is exactly what I'm getting at: People have marinated so much in the
way Eclipse works by default that what I'm saying sounds like a non
sequitur.

I'll try to explain:
- I have a repository with a large source tree that contains hundreds of
leaf directories.
- Each leaf directory contains source that needs to be built into a shared
library or an executable binary.
- The source tree contains a superset of the functionality that is needed
by all configurations.
- Any particular configuration of the CMake project will result in only a
subset of the libraries and/or binaries being built.
- The subset being built is defined via CMake option() commands that set
(or don't) cache variables that control which subdirectories are added to
the CMake project.

What I want from Eclipse:
- Only show in the project tree and Open Resource dialog the subset of
source files that belong to the current configuration of the CMake project,
so that developers don't get confused about what is relevant or not to the
configuration of CMake they are working in.
- Only index the subset of source files that belong to the current
configuration of the CMake project, so that resources are not wasted
indexing irrelevant sources, and so that developers are not flooded with
irrelevant indexer errors.
- Show header files that are assigned to a target, including custom
header-only targets ("custom_target(... SOURCES)"), as is done by other
IDEs.


> If the IDE indexing all source files takes too long, I would say it is a
> problem with the IDE; but not a problem of cmake's IDE project generator
> (as
> the topic states).
>

Time is only one aspect (see above), although it's particularly bad with
the out-of-box Eclipse project generated by CMake's default settings
because it indexes every source file 3 times.


> That's the only way to go in your case. How should the CDT4 project
> generator
> know about all your source files that do not take part in a build?
>

The point I'm trying to make is that I *don't* want Eclipse to know about
source files that are *not* being built, but it *does* know about them
because all solutions (CMake generator, cmake4eclipse) just point Eclipse
at the source tree *in the filesystem*, and not at the conceptual project
tree defined via the CMakeLists.txt hierarchy. Remember that for me, the
filesystem contains lots of sources that are *not* relevant to any one
CMake configuration that developers will be working with.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Eclipse generator question

[Martin Weber]

Am Mittwoch, 3. April 2019, 22:55:45 CEST schrieb Benjamin Shadwick:
> FYI,
> 
> I opened a bug on CMake's tracker about updating the CMake generator since
> its outputs are kind of garbage for modern CDT releases:
> https://gitlab.kitware.com/cmake/cmake/issues/19107
> 
> Unfortunately the only feedback I got was that there is a push to remove
> *all* generators in favor of forcing IDEs to use cmake-file-api. I opened a

+1 from me for removing IDE project generators.

[...]
> Maybe being tied to the filesystem view is an inherent limitation of
> Eclipse (and/or CDT), or maybe it was at one time and neither CMake nor

To implement the 'index only files referenced through the build script' view, 
*any* IDE would have to *interpret* the build scripts. 
Just choose an IDE that has a build script interpreter to solve your use case.

> cmake4eclipse are taking advantage of what modern Eclipse versions can do.

Sounds promising. What is it that _modern Eclipse versions can do_?

-- 
Cd wrttn wtht vwls s mch trsr.




-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Eclipse generator question

[Martin Weber]

Am Mittwoch, 3. April 2019, 22:26:59 CEST schrieb Benjamin Shadwick:
> I tried cmake4eclipse, and it's a mixed bag. It requires a lot of tweaking

Really? Just set _CMake Builder (portable)_ as the current builder and build.

> of the Eclipse project after you create it, and I'm pretty sure it suffers
> from the same problem of leaving you with an Eclipse project whose source
> tree reflects what is in the filesystem rather than what is defined in the
> CMake project.

What does that mean: _an Eclipse project whose source tree reflects what is in 
the filesystem rather than what is defined in the CMake project._ ??

 
> It's really annoying that I spent all this time building a CMake project
> for a complex codebase, only to have the IDE present and index the entire
> source tree on the filesystem instead of the subset that is actually being
> built by the CMake configuration.

If the IDE indexing all source files takes too long, I would say it is a 
problem with the IDE; but not a problem of cmake's IDE project generator (as 
the topic states).

> I should probably enhance my project-tweaking python script to add filters
> to the generated Eclipse project to hide anything that isn't in the CMake
> project.

That's the only way to go in your case. How should the CDT4 project generator 
know about all your source files that do not take part in a build?



-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Eclipse generator question

[Benjamin Shadwick]

FYI,

I opened a bug on CMake's tracker about updating the CMake generator since
its outputs are kind of garbage for modern CDT releases:
https://gitlab.kitware.com/cmake/cmake/issues/19107

Unfortunately the only feedback I got was that there is a push to remove
*all* generators in favor of forcing IDEs to use cmake-file-api. I opened a
bug on the Eclipse tracker asking if they knew about this push and whether
anyone was working on it from the CDT end, and they aren't but are
receptive: https://bugs.eclipse.org/bugs/show_bug.cgi?id=545905

None of that helps me, though, because I'm stuck on CMake 2.8.12.2 for now.

I think my main philosophical issue is that CMake lets you define a
project, and I'd like to see that definition reflected in Eclipse.
Unfortunately, both the CMake Eclipse generator and cmake4eclipse plugin
leave you with a filesystem-oriented view of the source instead of a CMake
project oriented view. You can get most of this from importing a CMake
project into something more primitive like NetBeans.

Maybe being tied to the filesystem view is an inherent limitation of
Eclipse (and/or CDT), or maybe it was at one time and neither CMake nor
cmake4eclipse are taking advantage of what modern Eclipse versions can do.

On Wed, Apr 3, 2019 at 1:32 PM Martin Weber 
wrote:

> Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick:
> > Update - I think I found a tolerable workaround:
> >
> > If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and
> > then inject a link to my include directory into the .project file, things
> > work a lot better:
>
> You (and other having problems with eclipse projects generated by cmake)
> might
> want to read these posts of the CDT project lead concerning cmake's CDT4
> generator [1] [2].
>
> Martin
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530090#c3
> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530090#c5
>
>
> --
> Cd wrttn wtht vwls s mch trsr.
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Eclipse generator question

[Martin Weber]

Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick:
> Update - I think I found a tolerable workaround:
> 
> If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and
> then inject a link to my include directory into the .project file, things
> work a lot better:

You (and other having problems with eclipse projects generated by cmake) might 
want to read these posts of the CDT project lead concerning cmake's CDT4 
generator [1] [2].

Martin

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530090#c3
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530090#c5


-- 
Cd wrttn wtht vwls s mch trsr.




-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Eclipse generator question

[Benjamin Shadwick]

I tried cmake4eclipse, and it's a mixed bag. It requires a lot of tweaking
of the Eclipse project after you create it, and I'm pretty sure it suffers
from the same problem of leaving you with an Eclipse project whose source
tree reflects what is in the filesystem rather than what is defined in the
CMake project.

It's really annoying that I spent all this time building a CMake project
for a complex codebase, only to have the IDE present and index the entire
source tree on the filesystem instead of the subset that is actually being
built by the CMake configuration.

I should probably enhance my project-tweaking python script to add filters
to the generated Eclipse project to hide anything that isn't in the CMake
project.

On Wed, Apr 3, 2019 at 1:02 PM Martin Weber 
wrote:

> Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick:
> > Update - I think I found a tolerable workaround:
> >
> > If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and
> > then inject a link to my include directory into the .project file, things
> > work a lot better:
> > - I get only one copy of each source file in the Open Resource dialog.
> > - I get source and header files in the Open Resource dialog.
> > - I can toggle between source and header.
> > - I can build from Eclipse.
> > - I get version control support, even in my include tree.
> > - Indexing is fast.
> >
> > It seems that Eclipse improved version control support quite a bit since
> > the CMake Eclipse generator was last touched. Unfortunately this seems to
> > also mean that a lot of the linked resources that CMake generates by
> > default now just add noise (hence my better results from turning them
> off).
>
> Newer versions of CDT (9.1+) seem to have trouble to properly read the
> .cproject file generated by cmake [1] [2].
>
> Forget about running cmake manually and install _cmake4eclipse_ from the
> eclipse marketplace. It runs cmake automatically [3] and comes with
> support
> for the eclipse indexer. Some people even use it for CUDA in the nvidia
> insight IDE. (Disclaimer: I am the maintainer)
> Just try it with one of the example projects [4].
>
> Martin
>
> [1] 
> [2]  

[CMake] Android NDK --gcc-toolchain issue with Clang

[Stephen White]

Hi there,

Apologies in advance if this is not the correct mailing list.

I'm working on a C++ project which has existing CMake files and works on
Linux and Mac. I was attempting to build it on the Android NDK
cross-compiling to ARM64, and ran into an issue.

In particular, the toolchain determination for test compilation fails as
follows:


$HOME/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
--target=aarch64-none-linux-android
--gcc-toolchain=$HOME/Android/Sdk/ndk-bundle/toolchains//prebuilt/linux-x86_64
--sysroot=$HOME/Android/Sdk/ndk-bundle/platforms/android-28/arch-arm64
-funwind-tables -no-canonical-prefixes -D__ANDROID_API__=28 -fexceptions
-g  -fPIE -pie -Wl,--gc-sections
CMakeFiles/cmTC_34db0.dir/testCCompiler.c.o  -o cmTC_34db0
/usr/bin/ld: unrecognised emulation mode: aarch64linux

The problem seems to be where --gcc-toolchain is set to:

$HOME/Android/Sdk/ndk-bundle/toolchains//prebuilt/linux-x86_64

(note the double slash).

On my installation of the NDK (r19c, Linux), the toolchain seems to be in:

$HOME/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/

My android.toolchain.cmake file is as follows:

set(CMAKE_SYSTEM_NAME Android)

set(CMAKE_ANDROID_NDK $ENV{HOME}/Android/Sdk/ndk-bundle)

set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang)

set(CMAKE_ANDROID_ARCH_ABI arm64-v8a)

set(CMAKE_ANDROID_STL_TYPE c++_shared)

I was able to get it to work by applying the small patch below:

diff --git a/Modules/Platform/Android/Determine-Compiler-NDK.cmake
b/Modules/Platform/Android/Determine-Compiler-NDK.cmake

index 5f2cc524e5..c211bbceee 100644

--- a/Modules/Platform/Android/Determine-Compiler-NDK.cmake

+++ b/Modules/Platform/Android/Determine-Compiler-NDK.cmake

@@ -239,7 +239,7 @@ set(_ANDROID_TOOL_CXX_TOOLCHAIN_SUFFIX
"${_ANDROID_TOOL_C_TOOLCHAIN_SUFFIX}")

 if(_ANDROID_TOOL_CLANG_NAME)

   message(STATUS "Android: Selected Clang toolchain
'${_ANDROID_TOOL_CLANG_NAME}' with GCC toolchain '${_ANDROID_TOOL_NAME}'")

   set(_ANDROID_TOOL_C_COMPILER
"${CMAKE_ANDROID_NDK}/toolchains/${_ANDROID_TOOL_LLVM_NAME}/prebuilt/${_ANDROID_HOST_DIR}/bin/clang${_ANDROID_HOST_EXT}")

-  set(_ANDROID_TOOL_C_COMPILER_EXTERNAL_TOOLCHAIN
${CMAKE_ANDROID_NDK}/toolchains/${_ANDROID_TOOL_NAME}/prebuilt/${_ANDROID_HOST_DIR})

+  set(_ANDROID_TOOL_C_COMPILER_EXTERNAL_TOOLCHAIN
${CMAKE_ANDROID_NDK}/toolchains/${_ANDROID_TOOL_LLVM_NAME}/prebuilt/${_ANDROID_HOST_DIR})

   set(_ANDROID_TOOL_CXX_COMPILER
"${CMAKE_ANDROID_NDK}/toolchains/${_ANDROID_TOOL_LLVM_NAME}/prebuilt/${_ANDROID_HOST_DIR}/bin/clang++${_ANDROID_HOST_EXT}")

   set(_ANDROID_TOOL_CXX_COMPILER_EXTERNAL_TOOLCHAIN
"${_ANDROID_TOOL_C_COMPILER_EXTERNAL_TOOLCHAIN}")

 else()


The reason seems to be that if ANDROID_TOOL_NAME contains -clang, it is set
to the empty string on line 120 (CMake 10.13), so the external toolchain
path contains an empty directory element (//). ANDROID_TOOL_LLVM_NAME
contains "llvm", which is the correct string to make the above path correct
on my installation.


If I'm doing something wrong and there's a better way to do this which
doesn't require patching CMake, please let me know.


Thanks,


Stephen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Eclipse generator question

[Martin Weber]

Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick:
> Update - I think I found a tolerable workaround:
> 
> If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and
> then inject a link to my include directory into the .project file, things
> work a lot better:
> - I get only one copy of each source file in the Open Resource dialog.
> - I get source and header files in the Open Resource dialog.
> - I can toggle between source and header.
> - I can build from Eclipse.
> - I get version control support, even in my include tree.
> - Indexing is fast.
> 
> It seems that Eclipse improved version control support quite a bit since
> the CMake Eclipse generator was last touched. Unfortunately this seems to
> also mean that a lot of the linked resources that CMake generates by
> default now just add noise (hence my better results from turning them off).

Newer versions of CDT (9.1+) seem to have trouble to properly read the 
.cproject file generated by cmake [1] [2]. 

Forget about running cmake manually and install _cmake4eclipse_ from the 
eclipse marketplace. It runs cmake automatically [3] and comes with support 
for the eclipse indexer. Some people even use it for CUDA in the nvidia 
insight IDE. (Disclaimer: I am the maintainer)
Just try it with one of the example projects [4].

Martin

[1] 
[2] 

[Cmake-commits] CMake branch, master, updated. v3.14.1-576-g6fdba8b

[Kitware Robot via Cmake-commits]

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  6fdba8b8beb6d971a3c2efe8973cdee970dfd40a (commit)
   via  058217669fdb089f652c68b9eb0a3231a7172c91 (commit)
   via  707283981fd455bf0bf3ec62a669cf1c0a2e1edb (commit)
   via  8ca1b262863d8a5cbb8306a52873101c2e940f78 (commit)
   via  37da6af17d0d2cc8b499dc58f74866351e06c288 (commit)
  from  d724060459f6adb5e7d99efde08c8fbacc4fdb5d (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=6fdba8b8beb6d971a3c2efe8973cdee970dfd40a
commit 6fdba8b8beb6d971a3c2efe8973cdee970dfd40a
Merge: 0582176 7072839
Author: Brad King 
AuthorDate: Wed Apr 3 18:06:38 2019 +
Commit: Kitware Robot 
CommitDate: Wed Apr 3 14:07:11 2019 -0400

Merge topic 'refactor-lang-flags'

707283981f VS: Use AddLanguageFlags to de-duplicate CMAKE__FLAGS* 
lookup
8ca1b26286 cmLocalGenerator: Factor IPO logic out of AddLanguageFlags

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=058217669fdb089f652c68b9eb0a3231a7172c91
commit 058217669fdb089f652c68b9eb0a3231a7172c91
Merge: d724060 37da6af
Author: Brad King 
AuthorDate: Wed Apr 3 18:05:32 2019 +
Commit: Kitware Robot 
CommitDate: Wed Apr 3 14:05:57 2019 -0400

Merge topic 'find-dependency-fix-17583'

37da6af17d find_dependency: Always search dependencies

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=707283981fd455bf0bf3ec62a669cf1c0a2e1edb
commit 707283981fd455bf0bf3ec62a669cf1c0a2e1edb
Author: Brad King 
AuthorDate: Mon Apr 1 13:38:55 2019 -0400
Commit: Brad King 
CommitDate: Tue Apr 2 14:23:46 2019 -0400

VS: Use AddLanguageFlags to de-duplicate CMAKE__FLAGS* lookup

diff --git a/Source/cmLocalVisualStudio7Generator.cxx 
b/Source/cmLocalVisualStudio7Generator.cxx
index e519d78..7ba3471 100644
--- a/Source/cmLocalVisualStudio7Generator.cxx
+++ b/Source/cmLocalVisualStudio7Generator.cxx
@@ -662,14 +662,7 @@ void cmLocalVisualStudio7Generator::WriteConfiguration(
 langForClCompile = linkLanguage;
 if (langForClCompile == "C" || langForClCompile == "CXX" ||
 langForClCompile == "Fortran") {
-  std::string baseFlagVar = "CMAKE_";
-  baseFlagVar += langForClCompile;
-  baseFlagVar += "_FLAGS";
-  flags = this->Makefile->GetRequiredDefinition(baseFlagVar);
-  std::string flagVar =
-baseFlagVar + std::string("_") + cmSystemTools::UpperCase(configName);
-  flags += " ";
-  flags += this->Makefile->GetRequiredDefinition(flagVar);
+  this->AddLanguageFlags(flags, target, langForClCompile, configName);
 }
 // set the correct language
 if (linkLanguage == "C") {
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx 
b/Source/cmVisualStudio10TargetGenerator.cxx
index 8804e6c..5195957 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -2540,14 +2540,8 @@ bool cmVisualStudio10TargetGenerator::ComputeClOptions(
   }
   this->LangForClCompile = langForClCompile;
   if (!langForClCompile.empty()) {
-std::string baseFlagVar = "CMAKE_";
-baseFlagVar += langForClCompile;
-baseFlagVar += "_FLAGS";
-flags = this->Makefile->GetRequiredDefinition(baseFlagVar);
-std::string flagVar =
-  baseFlagVar + "_" + cmSystemTools::UpperCase(configName);
-flags += " ";
-flags += this->Makefile->GetRequiredDefinition(flagVar);
+this->LocalGenerator->AddLanguageFlags(flags, this->GeneratorTarget,
+   langForClCompile, configName);
 this->LocalGenerator->AddCompileOptions(flags, this->GeneratorTarget,
 langForClCompile, configName);
   }

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8ca1b262863d8a5cbb8306a52873101c2e940f78
commit 8ca1b262863d8a5cbb8306a52873101c2e940f78
Author: Brad King 
AuthorDate: Mon Apr 1 13:37:02 2019 -0400
Commit: Brad King 
CommitDate: Tue Apr 2 14:23:32 2019 -0400

cmLocalGenerator: Factor IPO logic out of AddLanguageFlags

The IPO flag logic was added to `AddLanguageFlags` based on my advice.
However, this method should really only be about `CMAKE__FLAGS*`
variables.  Move the IPO logic out to its call sites.

diff --git a/Source/cmGlobalXCodeGenerator.cxx 
b/Source/cmGlobalXCodeGenerator.cxx
index af165f6..2fc6121 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -1800,6 +1800,10 @@ void 

Re: [CMake] Eclipse generator question

[Benjamin Shadwick]

Update - I think I found a tolerable workaround:

If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and
then inject a link to my include directory into the .project file, things
work a lot better:
- I get only one copy of each source file in the Open Resource dialog.
- I get source and header files in the Open Resource dialog.
- I can toggle between source and header.
- I can build from Eclipse.
- I get version control support, even in my include tree.
- Indexing is fast.

It seems that Eclipse improved version control support quite a bit since
the CMake Eclipse generator was last touched. Unfortunately this seems to
also mean that a lot of the linked resources that CMake generates by
default now just add noise (hence my better results from turning them off).

There are still some aspects that are not ideal. In particular, CMake
brings the source files into the project via the "[Source directory]"
virtual folder, which just points to the CMake project root directory on
the filesystem. This approach has a number of issues:
- Source files that are not part of the CMake project show up in Open
Resource and possibly the Eclipse CDT index.
- A view of the sources/headers belonging to each CMake target is not
really provided (although you can glean the sources part somewhat by
looking at the detailed target tree).

On Tue, Apr 2, 2019 at 9:04 AM Benjamin Shadwick 
wrote:

> I've recently converted a complex C++ codebase to CMake. I'm stuck using
> 2.8.12.2.
>
> The codebase has a source tree, whose leaf directories each build a shared
> library or an executable binary. The source lives in src/ while the headers
> live in a separate tree under a sibling include/ directory.
>
> Based on advice from the Internet, I am trying to do out-of-source builds,
> with the debug flavor in a debug/ sibling directory, and release in release/
>
> This all works from the command line, but I am using Eclipse CDT as my
> primary IDE and would like to get decent integration between that and CMake.
>
> When I use CMake's Eclipse generator and then import the project into
> Eclipse, there are some serious issues. The primary issue is that when I
> hit Ctrl+Shift+R to bring up the Open Resource dialog and then type in the
> name of a source file, I get 3 results: one under each of [Source files],
> [Subprojects], and [Targets]. This is awful, especially since picking the
> wrong one results in weird behavior like inability to resolve include
> directives or inability to toggle between source and corresponding header
> file.
>
> Is there some way to address this without resulting to in-source builds?
> I'm even willing to butcher the project files post-generate using Python if
> it would help.
>
> Thanks,
> - Ben S.
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Querying targets for Fortran module files & module file installation advice

[Zaak Beekman]

Awesome, thanks!
On Wed, Apr 3, 2019 at 10:26 AM Brad King  wrote:

> On 4/3/19 10:09 AM, Zaak Beekman wrote:
> > They contain the mod files. I didn't ask for a $ directory to
> > be created for me within the CMAKE_Fortran_MODULE_DIRECTORY but it's
> > there, and all the .mod files are inside it, so `install(DIRECTORY
> > ...)` is incapable (at least in my testing) of fetching them out of
> > the $ subdirectory.
>
> The VS generator supports multiple separate configurations being
> built under the same build tree, so all artifacts such as object
> files, libraries, executables, and Fortran modules need to have
> a per-config location.
>
> For libraries and executables we already have ways for projects
> to specify per-config locations such that no per-config
> subdirectory is added.  I've opened an issue to do the same for
> Fortran modules:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/19126
>
> Meanwhile you may be able to use `$` in the source directory
> specified by `install(DIRECTORY)` when CMAKE_GENERATOR is a
> Visual Studio generator.
>
> -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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Querying targets for Fortran module files & module file installation advice

[Brad King via CMake]

On 4/3/19 10:09 AM, Zaak Beekman wrote:
> They contain the mod files. I didn't ask for a $ directory to
> be created for me within the CMAKE_Fortran_MODULE_DIRECTORY but it's
> there, and all the .mod files are inside it, so `install(DIRECTORY
> ...)` is incapable (at least in my testing) of fetching them out of
> the $ subdirectory.

The VS generator supports multiple separate configurations being
built under the same build tree, so all artifacts such as object
files, libraries, executables, and Fortran modules need to have
a per-config location.

For libraries and executables we already have ways for projects
to specify per-config locations such that no per-config
subdirectory is added.  I've opened an issue to do the same for
Fortran modules:

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

Meanwhile you may be able to use `$` in the source directory
specified by `install(DIRECTORY)` when CMAKE_GENERATOR is a
Visual Studio generator.

-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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Querying targets for Fortran module files & module file installation advice

[Zaak Beekman]

Thanks so much Brad!

On Wed, Apr 3, 2019 at 9:35 AM Brad King  wrote:

> The `install(DIRECTORY)` approach is the current recommendation.

OK

> Do those directories contain the `.mod` files or are they extra?
> In the latter case, use `install(DIRECTORY)`'s options for excluding
> content by pattern or regex.

They contain the mod files. I didn't ask for a $ directory to
be created for me within the CMAKE_Fortran_MODULE_DIRECTORY but it's
there, and all the .mod files are inside it, so `install(DIRECTORY
...)` is incapable (at least in my testing) of fetching them out of
the $ subdirectory.

> Set the per-target Fortran_MODULE_DIRECTORY property to keep private
> modules out of the installed directory.

That's the plan.

> We don't have that information at CMake time.  The set of files is
> not discovered until the build, and there is no one place that has
> the full set.

H ok, thanks for the info. Fortran, always making tooling hard...

Well thank you SO MUCH once again for the response.

Best,
Zaak
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Querying targets for Fortran module files & module file installation advice

[Brad King via CMake]

On 3/31/19 5:10 PM, Zaak Beekman wrote:
> What's the best approach for handling cross-platform (i.e., MSVS, Mac,
>  Linux) installation of Fortran module files associated with
> libraries?

The `install(DIRECTORY)` approach is the current recommendation.

> problems and drawbacks remain:
> 
> 1. With IDEs like MSVS, I always seem to end up getting an additional
> directory installed under ${CMAKE_INSTALL_INCLUDE_DIR} with the name
> of the build configuration (e.g., `debug`)

Do those directories contain the `.mod` files or are they extra?
In the latter case, use `install(DIRECTORY)`'s options for excluding
content by pattern or regex.

> 2. Utility/test modules may have generic names (e.g. assertions.mod)
> that probably should not get installed and will very likely lead to
> name  clashes with consuming projects

Set the per-target Fortran_MODULE_DIRECTORY property to keep private
modules out of the installed directory.

> 3. Lack of standard definition of module file format and Fortran ABI
> makes portability dicey, at least until ISO_Fortran_BINDING is widely
> available and adopted

That seems orthogonal.  It's a reason to not install them at all.

> It would be great if there were a target property that could be
> queried for associated module and submodule files.

We don't have that information at CMake time.  The set of files is
not discovered until the build, and there is no one place that has
the full set.

-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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Querying targets for Fortran module files & module file installation advice

[Zaak Beekman]

Hi all,

This didn't get any bites, so I'm re-sending it. Any thoughts, however
short they may be would be appreciated. Right now, the only obvious
solution to me is to use `install(SCRIPT ...)` where a script uses
`file(GLOB_RECURSE ...)` to enumerate modules and submodules in the
build path, followed by a `foreach(...)` loop over all the found
artifacts to install them with `file(INSTALL ...)`. This feels
fragile, and un-idiomatic. Am I missing a better way to do this?

Thanks,
Zaak

On Sun, Mar 31, 2019 at 5:10 PM Zaak Beekman  wrote:
>
> Hi all,
>
> What's the best approach for handling cross-platform (i.e., MSVS, Mac,
>  Linux) installation of Fortran module files associated with
> libraries?
>
> After searching the docs, I couldn't find any good and obvious way to
> handle installation of Fortran module files associated with library
> targets. These are compiler specific, and, perhaps a better approach
> might be to ship all executable code compiled into libraries and put
> inside submodules, and ship a free/open parent module with interface,
> type, class, constant, etc. definitions.
>
> But, at any rate, it would be nice if there were a better way to
> install Fortran module files besides something like:
>
> ```
> set(CMAKE_Fortran_MODULE_DIRECTORY "${CMAKE_BINARY_DIR}/include")
>
> ...
>
> install(DIRECTORY ${CMAKE_Fortran_MODULE_DIRECTORY} DESTINATION
> ${CMAKE_INSTALL_INCLUDE_DIR})
> ```
>
> In particular, it is hard to know which .mod and .smod files will be
> produced ahead of time without parsing the source, or manually
> enumerating them. One can use the approach outlined above, but a few
> problems and drawbacks remain:
>
> 1. With IDEs like MSVS, I always seem to end up getting an additional
> directory installed under ${CMAKE_INSTALL_INCLUDE_DIR} with the name
> of the build configuration (e.g., `debug`)
> 2. Utility/test modules may have generic names (e.g. assertions.mod)
> that probably should not get installed and will very likely lead to
> name  clashes with consuming projects
> 3. Lack of standard definition of module file format and Fortran ABI
> makes portability dicey, at least until ISO_Fortran_BINDING is widely
> available and adopted
>
> It would be great if there were a target property that could be
> queried for associated module and submodule files. In addition
> additional "it just works" logic around installing Fortran targets and
> how modules are handled would be really nice. This obviously isn't an
> easy/trivial question to answer, but being able to query targets for
> module file build artifacts would be a great starting point.
>
> In the mean time, I think my only acceptable options to handle IDEs
> like MSVS is to use the `SCRIPT` signature of `install()` where I can
> use `file(GLOB_RECURSE ...)` to find module files and strip out any
> build configuration specific directory structure. (Or at least adopt
> my own logic and conventions for this...)
>
> Any tips or advice would be very appreciated!
>
> Thanks,
> Zaak
-- 

Powered by www.kitware.com

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

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

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

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

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