From post at hendrik-sattler.de  Sat Oct  1 04:49:46 2016
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Sat, 01 Oct 2016 10:49:46 +0200
Subject: [CMake] try_compile additional include FILES
In-Reply-To: <CAA2GJqXBdnmHSgkBdnmHr-57geyWCShwfRTgq+Kn92+BfSUUtg@mail.gmail.com>
References: <CAA2GJqXBdnmHSgkBdnmHr-57geyWCShwfRTgq+Kn92+BfSUUtg@mail.gmail.com>
Message-ID: <C7AF05F5-48FB-4E55-96DD-6911B3FEC906@hendrik-sattler.de>

Hi,

If you know that you are on Windows and know all that, why do you want an expensive check for it?

HS


Am 30. September 2016 19:57:07 MESZ, schrieb J Decker <d3ck0r at gmail.com>:
>I've been playing with libressl; which has quite a few
>'check_function_exists'
>
>In particular 'check-function-exists( inet_pton HAVE_INET_PTON )'
>
>this is failing, because, directly, there is no 'inet_pton' in windows,
>but
>by including ws2tcpip.h there is a #define that changes it to
>InetPton[A/W]
>
>but I don't see any way to specify additional files to include.
>
>
>------------------------------------------------------------------------

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

From d3ck0r at gmail.com  Sat Oct  1 05:12:05 2016
From: d3ck0r at gmail.com (J Decker)
Date: Sat, 1 Oct 2016 02:12:05 -0700
Subject: [CMake] try_compile additional include FILES
In-Reply-To: <C7AF05F5-48FB-4E55-96DD-6911B3FEC906@hendrik-sattler.de>
References: <CAA2GJqXBdnmHSgkBdnmHr-57geyWCShwfRTgq+Kn92+BfSUUtg@mail.gmail.com>
 <C7AF05F5-48FB-4E55-96DD-6911B3FEC906@hendrik-sattler.de>
Message-ID: <CAA2GJqXmeu_WQYHJ-uMmXCeQ7Ayij1uy-g3MzbffW8JFWT-KBQ@mail.gmail.com>

to fit in with the exsting schema.
Docs also say it's only available after 8.1 so.... it's really not; and
depending on the toolkit used .. which I guess is another version that
could be checked instead.

On Sat, Oct 1, 2016 at 1:49 AM, Hendrik Sattler <post at hendrik-sattler.de>
wrote:

> Hi,
>
> If you know that you are on Windows and know all that, why do you want an
> expensive check for it?
>
> HS
>
>
> Am 30. September 2016 19:57:07 MESZ, schrieb J Decker <d3ck0r at gmail.com>:
> >I've been playing with libressl; which has quite a few
> >'check_function_exists'
> >
> >In particular 'check-function-exists( inet_pton HAVE_INET_PTON )'
> >
> >this is failing, because, directly, there is no 'inet_pton' in windows,
> >but
> >by including ws2tcpip.h there is a #define that changes it to
> >InetPton[A/W]
> >
> >but I don't see any way to specify additional files to include.
> >
> >
> >------------------------------------------------------------------------
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161001/dc9a8a3b/attachment.html>

From steveire at gmail.com  Mon Oct  3 08:43:13 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 03 Oct 2016 14:43:13 +0200
Subject: [CMake] Editing IMPORTED targets
References: <1474862988.10826.5.camel@intelfx.name>
Message-ID: <nstjov$vnt$1@blaine.gmane.org>

Ivan Shapovalov wrote:

> Hello!
> 
> Using find modules to detect dependencies has a nice feature: it is
> then possible to edit the resulting cache entries to link to different
> libraries (or add other libraries along the found ones, for whatever
> purposes), or change directories, or flags, or whatever.
> 
> Using find configs and IMPORTED targets, however, prevents doing this,
> because IMPORTED targets are not stored in CMake cache. This can be a
> significant disadvantage at times.

Can you be more specific?

Why can the user provide better information than the supplier of the 
IMPORTED target?

Thanks,

Steve.



From craig.scott at crascit.com  Tue Oct  4 03:01:04 2016
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 4 Oct 2016 18:01:04 +1100
Subject: [CMake] RPATH handling differences
Message-ID: <CA+dygYkJrU7cDj8jMtDHuRDpBjDCGpDutDz523PFbctj4WHzvw@mail.gmail.com>

Can anyone confirm whether invoking cpack directly rather than "cmake
--build . --target package" would still give the same RPATH handling?
Specifically, the install/packaging step rewrites the rpaths in at least
some cases (e.g. see the docs for CMAKE_BUILD_WITH_INSTALL_RPATH) and I'm
wanting to ensure I still get this if I just run cpack directly.

Ref:
https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_WITH_INSTALL_RPATH.html

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161004/d399ee59/attachment.html>

From robert.maynard at kitware.com  Tue Oct  4 16:32:25 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 4 Oct 2016 16:32:25 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.7.0-rc1 now ready for testing!
Message-ID: <CAFzjYVo=9Ror1gjyy7+MftJOkPVYSoQNHjYRSkHaz7RJfRxDzw@mail.gmail.com>

I am proud to announce the first CMake 3.7 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.7

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.7/release/3.7.html

Some of the more significant changes in CMake 3.7 are:

* CMake now supports Cross Compiling for Android with simple
  toolchain files.

* The "Ninja" generator learned to conditionally support Fortran
  when using a "ninja" tool that has the necessary features. See
  generator documentation for details.

* The "if()" command gained new boolean comparison operations
  "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL",
  "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL".

* The "try_compile()" command source file signature now honors
  configuration-specific flags (e.g. "CMAKE_<LANG>_FLAGS_DEBUG") in
  the generated test project.  Previously only the default such flags
  for the current toolchain were used.  See policy "CMP0066".

* "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT",
  "CMAKE_SHARED_LINKER_FLAGS_INIT", and
  "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the
  "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and
  "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language
  is enabled in a build tree.

* CTest now supports test fixtures through the new "FIXTURES_SETUP",
  "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When
  using regular expressions or "--rerun-failed" to limit the tests to
  be run, a fixture's setup and cleanup tests will automatically be
  added to the execution set if any test requires that fixture.

* We no longer provide Linux i386 binaries for download from
  "cmake.org" for new versions of CMake.

* Vim support files "cmake-indent.vim", "cmake-syntax.vim", and
  "cmake-help.vim" have been removed in favor of the files now
  provided from the vim-cmake-syntax project.

* Support for building CMake itself with some compilers was dropped:

  * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above

  * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64

  CMake still supports generating build systems for other projects
  using these compilers.





CMake 3.7 Release Notes
***********************

Changes made since CMake 3.6 include the following.


New Features
============


Platforms
---------

* CMake now supports Cross Compiling for Android with simple
  toolchain files.

* The Clang compiler is now supported on AIX.


Generators
----------

* The "Ninja" generator learned to conditionally support Fortran
  when using a "ninja" tool that has the necessary features. See
  generator documentation for details.

* The "Ninja" generator learned to produce phony targets of the form
  "sub/dir/{test,install,package}" to drive the build of a
  subdirectory installation, test or packaging target. This is
  equivalent to "cd sub/dir; make {test,install,package}" with
  Makefile Generators.

* The "Visual Studio 15" generator was added.  This is experimental
  and based on Preview 4 because this version of VS has not been
  released.

* Visual Studio Generators for VS 2010 and above learned to place
  ".natvis" source files into VS project files properly.

* The "Xcode" generator's rudimentary Swift language support learned
  to honor a new "CMAKE_Swift_LANGUAGE_VERSION" variable to tell Xcode
  what version of Swift is used by the source.

* The "CodeLite" generator gained a new "CMAKE_CODELITE_USE_TARGETS"
  option to change project creation from projects to targets.


Commands
--------

* The "add_custom_command()" command gained a new "DEPFILE" option
  that works with the "Ninja" generator to provide implicit dependency
  information to the build tool.

* The "cmake_parse_arguments()" command gained a new "PARSE_ARGV"
  mode to read arguments directly from "ARGC" and "ARGV#" variables
  inside a "function()" body.

* The "export()" command gained an "ANDROID_MK" option to generate
  "Android.mk" files referencing CMake-built libraries as prebuilts
  for the Android NDK build system.

* The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained
  "HTTPHEADER <HTTP-header>" and "USERPWD <username>:<password>"
  options.

* The "find_library()" and "find_package()" commands learned to
  search in "lib32/" directories when the build targets a 32-bit
  architecture.  See the "FIND_LIBRARY_USE_LIB32_PATHS" global
  property.

* The "find_package()" command gained the possibility of sorting
  compatible libraries by "NAME" or by "NATURAL" sorting by setting
  the two new variables "CMAKE_FIND_PACKAGE_SORT_ORDER" and
  "CMAKE_FIND_PACKAGE_SORT_DIRECTION".

* The "if()" command gained new boolean comparison operations
  "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL",
  "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL".

* The "install()" command gained an "EXPORT_ANDROID_MK" subcommand
  to install "Android.mk" files referencing installed libraries as
  prebuilts for the Android NDK build system.

* The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained
  support for the "%a" and "%b" placeholders. These are the
  abbreviated weekday and month names.

* The "try_compile()" command source file signature now honors
  configuration-specific flags (e.g. "CMAKE_<LANG>_FLAGS_DEBUG") in
  the generated test project.  Previously only the default such flags
  for the current toolchain were used.  See policy "CMP0066".


Variables
---------

* Variable "CMAKE_FIND_PACKAGE_SORT_ORDER" was added to control the
  sorting mode of the "find_package()" command.

* Variable "CMAKE_FIND_PACKAGE_SORT_DIRECTION" was added to control
  the sorting direction the "find_package()" command.

* "Toolchain files" may now set a "CMAKE_<LANG>_FLAGS_INIT" variable
  to initialize the "CMAKE_<LANG>_FLAGS" cache entry the first time a
  language is enabled in a build tree.

* "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT",
  "CMAKE_SHARED_LINKER_FLAGS_INIT", and
  "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the
  "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and
  "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language
  is enabled in a build tree.


Properties
----------

* On Apple platforms the "BUNDLE_EXTENSION" target property now also
  applies to Frameworks and App Bundles.

* A "BINARY_DIR" directory property was added to get the absolute
  path to the binary directory corresponding to the source directory
  on which the property is read.

* A "BUILDSYSTEM_TARGETS" directory property was added to get the
  list of logical buildsystem target names added by the project in a
  directory.

* A "LINK_WHAT_YOU_USE" target property and supporting
  "CMAKE_LINK_WHAT_YOU_USE" variable were introduced to detect (on
  UNIX) shared libraries that are linked but not needed by running
  "ldd -r -u".

* A "SOURCE_DIR" directory property was added to get the absolute
  path to the source directory associated with a directory.

* A "SUBDIRECTORIES" directory property was added to get the list of
  subdirectories added by a project in a directory.

* A "VS_SDK_REFERENCES" target property was added to tell Visual
  Studio Generators to reference the named SDKs.

* A "VS_TOOL_OVERRIDE" source file property was created to tell
  Visual Studio Generators what tool to use for a source file.

* The "WINDOWS_EXPORT_ALL_SYMBOLS" target property now applies to
  executable targets with the "ENABLE_EXPORTS" property set.

* A "XCODE_FILE_ATTRIBUTES" source file property was added to tell
  the "Xcode" generator to generate custom content in the Xcode
  project attributes for the file.


Modules
-------

* An "AndroidTestUtilities" module was added to manage transfer of
  test data to an Android device.

* The "CheckFortranSourceCompiles" module macro
  "CHECK_Fortran_SOURCE_COMPILES" gained a "SRC_EXT" option to specify
  a custom test Fortran source file extension.

* The "ExternalProject" module gained "HTTP_USERNAME" and
  "HTTP_PASSWORD" options to set http download credentials.

* The "ExternalProject" module gained a "HTTP_HEADER" option to add
  http download headers.

* The "FindBISON" module "BISON_TARGET" macro learned a new
  "REPORT_FILE" option to specify the bison "--report-file=" option.

* The "FindBZip2" module now provides imported targets.

* A "FindICU" module was introduced to find the International
  Components for Unicode (ICU) libraries and programs.

* The "FindMatlab" module learned to find a SIMULINK component.

* The "FindOpenCL" module now provides imported targets.

* The "FindOpenMP" module learned to detect the OpenMP version
  (specification date) from the compiler.

* A "FindVulkan" module was added.

* The "GenerateExportHeader" module learned a new
  "CUSTOM_CONTENT_FROM_VARIABLE" option to specify a variable
  containing custom content for inclusion in the generated header.

* The "GNUInstallDirs" module gained a new
  "GNUInstallDirs_get_absolute_install_dir()" command.

* The "UseJava" module gained APIs to "export" jar targets for use
  by external CMake projects.  See the "install_jar_exports" and
  "export_jars" functions.


CTest
-----

* CTest now supports test fixtures through the new "FIXTURES_SETUP",
  "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When
  using regular expressions or "--rerun-failed" to limit the tests to
  be run, a fixture's setup and cleanup tests will automatically be
  added to the execution set if any test requires that fixture.

* The "ctest_configure()", "ctest_build()", "ctest_test()",
  "ctest_coverage()", and "ctest_upload()" commands gained a new
  "CAPTURE_CMAKE_ERROR" option to capture any errors that occur as the
  commands run into a variable and avoid affecting the return code of
  the "ctest(1)" process.


CPack
-----

* CPack gained a "productbuild" generator on OS X, configured by the
  "CPackProductBuild" module.

* CPack gained a new "CPACK_PACKAGE_CHECKSUM" variable to enable
  generation of a checksum file for each package file.

* The "CPackDeb" module learned to support long file names when
  archive format is set to GNU tar. See "CPACK_DEBIAN_ARCHIVE_TYPE"

* The "CPackIFW" module gained a new
  "cpack_ifw_add_package_resources()" command to include additional
  resources in the installer binary.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands gained a new
  "USER_INTERFACES" option to add a list of additonal pages to the IFW
  installer.

* The "CPackRPM" module learned to generate debuginfo packages on
  demand. See "CPACK_RPM_DEBUGINFO_PACKAGE" and its per component
  version.

* The "CPackRPM" module learned to generate source rpm (SRPM)
  packages on demand. See "CPACK_RPM_PACKAGE_SOURCES",
  "CPACK_RPM_SOURCE_PKG_BUILD_PARAMS" and
  "CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX".

* The CPack NSIS generator now supports
  "CPACK_NSIS_<compName>_INSTALL_DIRECTORY". This can be used to set
  component specific installation directories.

* The CPack WIX generator now supports
  "CPACK_WIX_SKIP_PROGRAM_FOLDER" to allow specification of a custom
  absolute installation prefix outside of the ProgramFiles folders.

* The CPack WIX generator now supports
  "CPACK_COMPONENT_<compName>_DISABLED". This can be used to deselect
  a component from being installed by default.

* The CPack WIX generator now supports "CPACK_WIX_PATCH_FILE"
  fragments for Feature elements.

* The CPack WIX generator now supports
  "CPACK_WIX_ROOT_FEATURE_TITLE" and
  "CPACK_WIX_ROOT_FEATURE_DESCRIPTION" to allow the specification of a
  custom title and description for the root feature element.


Other
-----

* "cmake(1)" gained a "-E capabilities" option to provide a machine-
  readable (JSON) description of the capabilities of the cmake tool
  (available generators, etc.).

* A new "cmake-server(7)" mode was added to provide semantic
  information about a CMake-generated buildsystem to clients through a
  JSON protocol.  Currently all protocols are experimental and subject
  to change.

* The "cmake(1)" command learned a "--trace-source=<file>" option.

* "ccmake(1)" learned to support vim-like navigation bindings.

* "cmake-gui(1)" gained a button to open the generated project file
  for Visual Studio Generators and the "Xcode" generator.


Deprecated and Removed Features
===============================

* We no longer provide Linux i386 binaries for download from
  "cmake.org" for new versions of CMake.

* Vim support files "cmake-indent.vim", "cmake-syntax.vim", and
  "cmake-help.vim" have been removed in favor of the files now
  provided from the vim-cmake-syntax project.

* Support for building CMake itself with some compilers was dropped:

  * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above

  * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64

  CMake still supports generating build systems for other projects
  using these compilers.


Other Changes
=============

* The Fortran dependency scanner learned to support the syntax of
  Fortran Submodules.

* Vim support files "indent/cmake.vim" and "syntax/cmake.vim" from
  the vim-cmake-syntax project are now distributed with CMake.

From louis at opter.org  Tue Oct  4 22:12:33 2016
From: louis at opter.org (Louis Opter)
Date: Tue, 4 Oct 2016 19:12:33 -0700
Subject: [CMake] False positives with CheckFunctionExists and dynamic linking
Message-ID: <20161004191233.4eed40db@wintermute.kalessin.fr>

Hello,

My laptop is running on Mac OS 10.11 with the latest Xcode 8 release.

This version of Xcode ships the Mac OS 10.12 API/SDKs which includes
the clock_gettime function which I check for availability using
check_function_exists.

Even though clock_gettime doesn?t exist on Mac OS 10.11,
check_function_exists successfully finds it because clock_gettime is
defined in headers, and is then dynamically linked. So, try_compile
works but the executable simply can?t run:

---8<---

tessa:0:/tmp/louis/tmp% xcodebuild -version ; sw_vers -productVersion
Xcode 8.0
Build version 8A218a
10.11.6
tessa:0:/tmp/louis/tmp% clang -Wall -Wextra -o test test.c
tessa:0:/tmp/louis/tmp% ./test
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
  Referenced from: /private/tmp/louis/tmp/./test (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _clock_gettime
  Referenced from: /private/tmp/louis/tmp/./test (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib

zsh: trace trap (core dumped)  ./test
tessa:0:/tmp/louis/tmp% cat test.c
#include <time.h>

int
main(void)
{
    struct timespec tp;
    return clock_gettime(CLOCK_MONOTONIC, &tp);
}
tessa:0:/tmp/louis/tmp% 

--->8---

(clang is shipped with Xcode).

IMO, it?s an issue on Apple side, I don?t even know why it?s building
10.12 executables while I?m running 10.11, this broke on me when Xcode
upgraded itself and I didn?t configure anything.

I have worked around the issue by forcing static linking for that
particular function before calling check_function_exists:

---8<---

IF (APPLE)
    # Hopefully my intuition is right and this fixes false positives on
    # mac os < 10.12 with X Code >= 8 (where clock_gettime is defined
    # in the SDKs but actually doesn't exists so dyld blows up at run
    # time).
    # -u symbol_name
    #         Specified that symbol symbol_name must be defined for the
    #         link to succeed.  This is useful to force selected
    #         functions to be loaded from a static library.
    SET(CMAKE_REQUIRED_FLAGS "-Wl,-u=clock_gettime")
ENDIF ()

--->8---

This fix works for me, but it doesn?t feel like a very durable nor
generic solution to the problem.

I wonder if we could something in CMake to handle that weird aspect of
Mac OS.

I can?t think of anything better than the linker flag I used to solve
the problem.

Best

-- 
Louis Opter

From piponazo at gmail.com  Wed Oct  5 10:39:53 2016
From: piponazo at gmail.com (=?UTF-8?B?THVpcyBEw61heiBNw6Fz?=)
Date: Wed, 5 Oct 2016 16:39:53 +0200
Subject: [CMake] Error with ninja generator when using target_link_library
 with the debug keyword
Message-ID: <CAGBsks8WEdb9z-LgjEowp--fP_9XG5cTcRtJjUmpJ6Y+cAkQig@mail.gmail.com>

Hi all,

I have found a problem while configuring a project and I want to share the
experience with you to figure out whether it is a known problem or a bug in
CMake.

In some cases I use the cmake command *target_link_libraries *specifying
different libraries for the *debug* and *optimized* modes. This normally
work as expected. However recently we got a problem with the Ninja
generator. This is what I could see in the console when I try to compile
the project:

ninja: error: build.ninja:4956: bad $-escape (literal $ must be written as
$$)


The content of the file in that particular line has something like this:

$<$<CONFIG:DEBUG>:/home/luis/xxxx//lib/libCGAL.so>

Examining my cmake configuration I noticed that a colleague introduced
something like that in the *target_link_libraries* call:

            ${ZLIB_LIBRARIES}
            debug;${CGAL_LIB}
            ${GMP_LIB}

If we specify the debug & optimized modes we do not have problems. However
in this particular case, it seems that we only need to link against the
CGAL in debug mode and not in release mode. Note that with a Make generator
we can compile normally the project.

The work around for this case is to link normally against CGAL when we are
in Debug mode:

        if (${CMAKE_BUILD_TYPE} STREQUAL Debug)
            target_link_libraries(myTarget ${CGAL_LIB}
        endif()

So ... the questions are:


   - Is it possible to use *target_link_libraries *only with one of the
   modes (debug  / optimized) ?
   - The Make generator works properly for this case. Could it be a bug
   with the Ninja generator? I tried with the most recent versions of CMake &
   Ninja.

Best regards,
Luis Diaz Mas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161005/51c8f9c5/attachment.html>

From tgwozdz at bigvikinggames.com  Wed Oct  5 12:10:51 2016
From: tgwozdz at bigvikinggames.com (Tom Gwozdz)
Date: Wed, 5 Oct 2016 12:10:51 -0400
Subject: [CMake] cmake install multiple artifacts
Message-ID: <CAKJn17Y9QRnKJxFkKM3EbTRhVHkp6KqawOm7ZeB7JbfBVTseHA@mail.gmail.com>

Hello,

I'm using CMake to cross compile some code using Emscripten.  Emscripten
generates html/javascript files from c++ input files.  In my case, my
generated binary output is an html file that loads in a javascript file.
Both files are generated from the final link step.

When I do the following:

install(TARGETS target
EXPORT export
ARCHIVE DESTINATION lib
LIBRARY DESTINATION lib
RUNTIME DESTINATION bin
)

The bin directory contains the html file, but not the js file.  Is there
some way of telling CMake that the final link step actually generated
multiple files, and that all of them should be installed to the final bin
directory?

Thanks!
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161005/eebeea52/attachment.html>

From roman.wueger at gmx.at  Wed Oct  5 14:56:26 2016
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Wed, 5 Oct 2016 20:56:26 +0200
Subject: [CMake] Problems with icons for Windows Store 10.0
Message-ID: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at>

Hello,

I tried the following to copy the required app icons to the required destination:

configure_file(Logo.png ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)

The CMake process itself overrides those files at the end with the files from the CMake's Template directory, which are empty.

So, how could I use my icon files and/or what is the preferred way of doing this?

Thanks in advance

Best Regards
Roman

From brad.king at kitware.com  Wed Oct  5 15:09:18 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 5 Oct 2016 15:09:18 -0400
Subject: [CMake] [cmake-developers] Problems with icons for Windows
	Store 10.0
In-Reply-To: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at>
References: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at>
Message-ID: <9e890c5e-bc99-b862-dbc8-9f1ddf54520c@kitware.com>

On 10/05/2016 02:56 PM, Roman W?ger wrote:
> I tried the following to copy the required app icons to the required destination:
> 
> configure_file(Logo.png ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)

That's a CMake-private directory whose location is an implementation detail.
Some other interface for configuring this behavior will be needed.

> The CMake process itself overrides those files at the end with the files from the
> CMake's Template directory, which are empty.

>From the current implementation it doesn't look like there is anyway to prevent
that.  We'll need to have some configuration of where it gets those files.

> So, how could I use my icon files and/or what is the preferred way of doing this?

Gilles?

-Brad


From gilles.khouzam at microsoft.com  Wed Oct  5 15:19:45 2016
From: gilles.khouzam at microsoft.com (Gilles Khouzam)
Date: Wed, 5 Oct 2016 19:19:45 +0000
Subject: [CMake] [cmake-developers] Problems with icons for Windows
	Store 10.0
In-Reply-To: <9e890c5e-bc99-b862-dbc8-9f1ddf54520c@kitware.com>
References: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at>
 <9e890c5e-bc99-b862-dbc8-9f1ddf54520c@kitware.com>
Message-ID: <CY1PR03MB1406096E96A3E4B92F27443698C40@CY1PR03MB1406.namprd03.prod.outlook.com>

That's most likely because you're missing an AppxManifest.

In order to build the CMake detection projects, we inject some necessary files into the project when they aren't specified. This includes the manifest and the icons. Can you add your app manifest to the project (look at Tests\VSWinStorePhone if you want an example) and the icons should not be overridden then.

Thanks

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Wednesday, October 5, 2016 12:09
To: Roman W?ger <roman.wueger at gmx.at>; Gilles Khouzam <gilles.khouzam at microsoft.com>
Cc: CMake Developer MailingList <cmake-developers at cmake.org>; CMake MailingList <cmake at cmake.org>
Subject: Re: [cmake-developers] Problems with icons for Windows Store 10.0

On 10/05/2016 02:56 PM, Roman W?ger wrote:
> I tried the following to copy the required app icons to the required destination:
> 
> configure_file(Logo.png 
> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)

That's a CMake-private directory whose location is an implementation detail.
Some other interface for configuring this behavior will be needed.

> The CMake process itself overrides those files at the end with the 
> files from the CMake's Template directory, which are empty.

>From the current implementation it doesn't look like there is anyway to prevent that.  We'll need to have some configuration of where it gets those files.

> So, how could I use my icon files and/or what is the preferred way of doing this?

Gilles?

-Brad


From roman.wueger at gmx.at  Thu Oct  6 01:39:07 2016
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Thu, 6 Oct 2016 07:39:07 +0200
Subject: [CMake] [cmake-developers] Problems with icons for Windows
	Store 10.0
In-Reply-To: <CY1PR03MB1406096E96A3E4B92F27443698C40@CY1PR03MB1406.namprd03.prod.outlook.com>
References: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at>
 <9e890c5e-bc99-b862-dbc8-9f1ddf54520c@kitware.com>
 <CY1PR03MB1406096E96A3E4B92F27443698C40@CY1PR03MB1406.namprd03.prod.outlook.com>
Message-ID: <2CA63915-C4DF-4400-BCE2-D01251941B15@gmx.at>

Thanks Gilles,

I added a custom appxmanifest as you mentioned and it works, but it would nevertheless very helpful to customize such things via variables and let CMake fill out the rest.

Regards
Roman

> Am 05.10.2016 um 21:19 schrieb Gilles Khouzam <gilles.khouzam at microsoft.com>:
> 
> That's most likely because you're missing an AppxManifest.
> 
> In order to build the CMake detection projects, we inject some necessary files into the project when they aren't specified. This includes the manifest and the icons. Can you add your app manifest to the project (look at Tests\VSWinStorePhone if you want an example) and the icons should not be overridden then.
> 
> Thanks
> 
> -----Original Message-----
> From: Brad King [mailto:brad.king at kitware.com] 
> Sent: Wednesday, October 5, 2016 12:09
> To: Roman W?ger <roman.wueger at gmx.at>; Gilles Khouzam <gilles.khouzam at microsoft.com>
> Cc: CMake Developer MailingList <cmake-developers at cmake.org>; CMake MailingList <cmake at cmake.org>
> Subject: Re: [cmake-developers] Problems with icons for Windows Store 10.0
> 
>> On 10/05/2016 02:56 PM, Roman W?ger wrote:
>> I tried the following to copy the required app icons to the required destination:
>> 
>> configure_file(Logo.png 
>> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)
> 
> That's a CMake-private directory whose location is an implementation detail.
> Some other interface for configuring this behavior will be needed.
> 
>> The CMake process itself overrides those files at the end with the 
>> files from the CMake's Template directory, which are empty.
> 
> From the current implementation it doesn't look like there is anyway to prevent that.  We'll need to have some configuration of where it gets those files.
> 
>> So, how could I use my icon files and/or what is the preferred way of doing this?
> 
> Gilles?
> 
> -Brad
> 


From gilles.khouzam at microsoft.com  Thu Oct  6 01:56:28 2016
From: gilles.khouzam at microsoft.com (Gilles Khouzam)
Date: Thu, 6 Oct 2016 05:56:28 +0000
Subject: [CMake] [cmake-developers] Problems with icons for Windows
	Store 10.0
In-Reply-To: <2CA63915-C4DF-4400-BCE2-D01251941B15@gmx.at>
References: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at>
 <9e890c5e-bc99-b862-dbc8-9f1ddf54520c@kitware.com>
 <CY1PR03MB1406096E96A3E4B92F27443698C40@CY1PR03MB1406.namprd03.prod.outlook.com>
 <2CA63915-C4DF-4400-BCE2-D01251941B15@gmx.at>
Message-ID: <CY1PR03MB140622A6E6E5F0D889B4BDCA98C70@CY1PR03MB1406.namprd03.prod.outlook.com>

Hi Roman,

Glad to hear that it works.

We discussed this when I implemented the feature, the only reason the functionality has been implemented is to supplement the intermediate projects that CMake produces that cannot easily be adapted for the requirements of a Windows Store application.

For a user's project, the AppXManifest is a critical piece that describes the application. There are some fields that need to be appropriately set (publisher Id, application name and version), even the icons need to be properly specified unless you use the exact same name for the files and don't look at having different tile sizes.

For prototyping this might seem like an unnecessary step, but once you start customizing the parts of the application, it seems counter intuitive to have customizations only apply under certain conditions. Perhaps a better solution would be to give an error message if any of the defaults are replaced but a manifest is not specified.

-----Original Message-----
From: Roman W?ger [mailto:roman.wueger at gmx.at] 
Sent: Wednesday, October 5, 2016 22:39
To: Gilles Khouzam <gilles.khouzam at microsoft.com>
Cc: Brad King <brad.king at kitware.com>; CMake Developer MailingList <cmake-developers at cmake.org>; CMake MailingList <cmake at cmake.org>
Subject: Re: [cmake-developers] Problems with icons for Windows Store 10.0

Thanks Gilles,

I added a custom appxmanifest as you mentioned and it works, but it would nevertheless very helpful to customize such things via variables and let CMake fill out the rest.

Regards
Roman

> Am 05.10.2016 um 21:19 schrieb Gilles Khouzam <gilles.khouzam at microsoft.com>:
> 
> That's most likely because you're missing an AppxManifest.
> 
> In order to build the CMake detection projects, we inject some necessary files into the project when they aren't specified. This includes the manifest and the icons. Can you add your app manifest to the project (look at Tests\VSWinStorePhone if you want an example) and the icons should not be overridden then.
> 
> Thanks
> 
> -----Original Message-----
> From: Brad King [mailto:brad.king at kitware.com]
> Sent: Wednesday, October 5, 2016 12:09
> To: Roman W?ger <roman.wueger at gmx.at>; Gilles Khouzam 
> <gilles.khouzam at microsoft.com>
> Cc: CMake Developer MailingList <cmake-developers at cmake.org>; CMake 
> MailingList <cmake at cmake.org>
> Subject: Re: [cmake-developers] Problems with icons for Windows Store 
> 10.0
> 
>> On 10/05/2016 02:56 PM, Roman W?ger wrote:
>> I tried the following to copy the required app icons to the required destination:
>> 
>> configure_file(Logo.png
>> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)
> 
> That's a CMake-private directory whose location is an implementation detail.
> Some other interface for configuring this behavior will be needed.
> 
>> The CMake process itself overrides those files at the end with the 
>> files from the CMake's Template directory, which are empty.
> 
> From the current implementation it doesn't look like there is anyway to prevent that.  We'll need to have some configuration of where it gets those files.
> 
>> So, how could I use my icon files and/or what is the preferred way of doing this?
> 
> Gilles?
> 
> -Brad
> 


From james at pspdfkit.com  Thu Oct  6 03:42:48 2016
From: james at pspdfkit.com (James Swift)
Date: Thu, 6 Oct 2016 09:42:48 +0200
Subject: [CMake] Repeating pre-processor definitions in MSVC generated
	projects
Message-ID: <CAKJSxP-=5C34b6ErENSWLcjwP+UrpiZ+4WzD5KU=WH4kc+58Gg@mail.gmail.com>

Hi,

I have some curious behaviour here. I generate MSVC project files, then run
cmake once more and a pre-processor define is duplicated and appended to
the list in the `<PreprocessorDefinitiion>` tag in ".vcproj"
Run cmake again without changing the CMake files and another is appended.

First generation...


<PreprocessorDefinitions>WIN32;_WINDOWS;_DEBUG;DEBUG......;CMAKE_INTDIR=\"Debug\";%(PreprocessorDefinitions)</PreprocessorDefinitions>

Second generation...

    <PreprocessorDefinitions>WIN32;_WINDOWS;_DEBUG;DEBUG;*DEBUG*
......;CMAKE_INTDIR=\"Debug\";%(PreprocessorDefinitions)</PreprocessorDefinitions>

Unfortunately I can't share the `CMakeLists.txt` files with you but hoped
that maybe someone was aware of this issue or if it's a common user mistake.

Of course this causes MSVC to rebuild the entire project even if that
shouldn't be necessary.
Any ideas?

kind regards,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161006/8938b4b3/attachment.html>

From jbarrett at pivotal.io  Fri Oct  7 14:01:45 2016
From: jbarrett at pivotal.io (Jacob Barrett)
Date: Fri, 07 Oct 2016 18:01:45 +0000
Subject: [CMake] CTest Fail Fast
Message-ID: <CAA1wVxpOY4kxPZ+2tUT1yP9q0Oy1Fr2tFJsnP8-dowCv=R8z5A@mail.gmail.com>

Is there a way to execute CTest on a series of tests and have it fail fast?
I would like CTest to immediately when any single test fails.

Thanks,
Jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161007/44090aed/attachment.html>

From Robert.Bielik at dirac.com  Sat Oct  8 11:34:00 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Sat, 8 Oct 2016 15:34:00 +0000
Subject: [CMake] Get targets added in subdirectory
Message-ID: <2e1080aa253145819d919cafee995e59@hosted3-mb01.itm.host>

Is there a way to get a list of targets added via add_subdirectory ? My goal is to place all targets in a subdirectory in a special folder in the VS IDE...

Regards
/Robert


From Robert.Bielik at dirac.com  Sat Oct  8 13:11:43 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Sat, 8 Oct 2016 17:11:43 +0000
Subject: [CMake] [SOLVED] RE: Get targets added in subdirectory
Message-ID: <98a6b4c48bb940368f1dc2b0e12206db@hosted3-mb01.itm.host>

I ended up solving this with the "wrapped cmake function" pattern, works nicely.

/R

>-----Original Message-----
>From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Bielik
>Sent: den 8 oktober 2016 17:34
>To: Cmake at cmake.org
>Subject: [CMake] Get targets added in subdirectory
>
>Is there a way to get a list of targets added via add_subdirectory ? My goal is
>to place all targets in a subdirectory in a special folder in the VS IDE...
>
>Regards
>/Robert
>
>--
>
>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

From Robert.Bielik at dirac.com  Sat Oct  8 13:41:55 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Sat, 8 Oct 2016 17:41:55 +0000
Subject: [CMake] [SOLVED] RE: Get targets added in subdirectory
In-Reply-To: <98a6b4c48bb940368f1dc2b0e12206db@hosted3-mb01.itm.host>
References: <98a6b4c48bb940368f1dc2b0e12206db@hosted3-mb01.itm.host>
Message-ID: <49ab2669e9b844c78a42ef3349c81999@hosted3-mb01.itm.host>

For reference, I ended up doing a special add_subdirectory_with_folder function, like so:

function (add_subdirectory_with_folder folder_name)
  function (add_library name type)
    _add_library (${ARGV})
    # Do not wrap creation of INTERFACE libraries
    if (type STREQUAL INTERFACE)
      return()
    endif()

    set_target_properties(${name}
      PROPERTIES
      FOLDER "${folder_name}"
    )
  endfunction()

  function (add_executable name)
    _add_executable (${ARGV})
    set_target_properties(${name}
      PROPERTIES
      FOLDER "${folder_name}"
    )
  endfunction()

  add_subdirectory (${ARGN})
endfunction()

#Usage
add_subdirectory_with_folder("My solution folder" <path to subdirectory>)

The nice thing is that it *seems* like the wrapper functions are scoped within the add_subdirectory_with_folder function, thus
not affecting targets defined later.

Regards
/R



>-----Original Message-----
>From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Bielik
>Sent: den 8 oktober 2016 19:12
>To: Cmake at cmake.org
>Subject: [CMake] [SOLVED] RE: Get targets added in subdirectory
>
>I ended up solving this with the "wrapped cmake function" pattern, works
>nicely.
>
>/R
>
>>-----Original Message-----
>>From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert
>Bielik
>>Sent: den 8 oktober 2016 17:34
>>To: Cmake at cmake.org
>>Subject: [CMake] Get targets added in subdirectory
>>
>>Is there a way to get a list of targets added via add_subdirectory ? My
>>goal is to place all targets in a subdirectory in a special folder in the VS IDE...
>>
>>Regards
>>/Robert
>>
>>--
>>
>>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

From Robert.Bielik at dirac.com  Mon Oct 10 04:29:11 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Mon, 10 Oct 2016 08:29:11 +0000
Subject: [CMake] Crosscompilation woes
Message-ID: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>

Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration tools within the project (together with add_custom_command). Of course, this will fail, since the tools are compiled for arm also and thus won't execute on my host system. So the tools need to be compiled for i686 whilst the rest for arm. I'm sure this can be handled by CMake although haven't done it before so would appreciate pointers :)

Regards
/Robert


From craig.scott at crascit.com  Mon Oct 10 04:46:33 2016
From: craig.scott at crascit.com (Craig Scott)
Date: Mon, 10 Oct 2016 19:46:33 +1100
Subject: [CMake] Crosscompilation woes
In-Reply-To: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
References: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
Message-ID: <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>

Here's one possible solution (not perfect, but has been working in
production for us for a while now for a similar scenario to what you
describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level
project to drive two sub-builds brought in via ExternalProject
<https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one for
the host and the other for arm. This is both better and worse, depending on
your point of view, so you may need to do some research/experimenting to
see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <Robert.Bielik at dirac.com>
wrote:

> Hi all,
>
> I am crosscompiling a project for arm (on linux i686), and use
> codegeneration tools within the project (together with add_custom_command).
> Of course, this will fail, since the tools are compiled for arm also and
> thus won't execute on my host system. So the tools need to be compiled for
> i686 whilst the rest for arm. I'm sure this can be handled by CMake
> although haven't done it before so would appreciate pointers :)
>
> Regards
> /Robert
>
> --
>
> 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
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/cc0bcf8d/attachment.html>

From Robert.Bielik at dirac.com  Mon Oct 10 05:10:06 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Mon, 10 Oct 2016 09:10:06 +0000
Subject: [CMake] Crosscompilation woes
In-Reply-To: <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
References: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
 <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
Message-ID: <7ab91f3c9c194fc3824da377170e8036@hosted3-mb01.itm.host>

Thanks Craig,

Your solution will work for me I think.

Regards
/R

From: Craig Scott [mailto:craig.scott at crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik <Robert.Bielik at dirac.com>
Cc: Cmake at cmake.org
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level project to drive two sub-builds brought in via ExternalProject<https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one for the host and the other for arm. This is both better and worse, depending on your point of view, so you may need to do some research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration tools within the project (together with add_custom_command). Of course, this will fail, since the tools are compiled for arm also and thus won't execute on my host system. So the tools need to be compiled for i686 whilst the rest for arm. I'm sure this can be handled by CMake although haven't done it before so would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com<http://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



--
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/e005b0fc/attachment.html>

From Robert.Bielik at dirac.com  Mon Oct 10 05:30:24 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Mon, 10 Oct 2016 09:30:24 +0000
Subject: [CMake] Crosscompilation woes
In-Reply-To: <c1f16514-526e-a9cc-8009-c4413b92cfcd@imag.fr>
References: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
 <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
 <7ab91f3c9c194fc3824da377170e8036@hosted3-mb01.itm.host>
 <c1f16514-526e-a9cc-8009-c4413b92cfcd@imag.fr>
Message-ID: <4671236c83d94d60abd40279f16b66a8@hosted3-mb01.itm.host>

Thank you Michele,

This is exactly what I'm after. You specify cmake v3.6 docs ? Is it only working from 3.6.x ? I have 3.5.2 on my build system.

Regards
/Robert

From: portolan [mailto:michele.portolan at imag.fr]
Sent: den 10 oktober 2016 11:27
To: Robert Bielik <Robert.Bielik at dirac.com>; Craig Scott <craig.scott at crascit.com>
Cc: Cmake at cmake.org
Subject: Re: [CMake] Crosscompilation woes


In my project I build on Linux i686 and I use a Toolchain file to specify the ARM cross-compiler

https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html
The nice thing is that if you mark some files as "generated" CMAKE will automatically use the build rather than the target toolchains. For instance, I have a Flex/Byson compiler that is generated locally on i686 , but then compiled for ARM.

Regards,

Michele
Le 10/10/2016 ? 11:10, Robert Bielik a ?crit :
Thanks Craig,

Your solution will work for me I think.

Regards
/R

From: Craig Scott [mailto:craig.scott at crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik <Robert.Bielik at dirac.com><mailto:Robert.Bielik at dirac.com>
Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level project to drive two sub-builds brought in via ExternalProject<https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one for the host and the other for arm. This is both better and worse, depending on your point of view, so you may need to do some research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration tools within the project (together with add_custom_command). Of course, this will fail, since the tools are compiled for arm also and thus won't execute on my host system. So the tools need to be compiled for i686 whilst the rest for arm. I'm sure this can be handled by CMake although haven't done it before so would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com<http://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



--
Craig Scott
Melbourne, Australia
https://crascit.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/b5ead10e/attachment-0001.html>

From michele.portolan at imag.fr  Mon Oct 10 05:33:05 2016
From: michele.portolan at imag.fr (portolan)
Date: Mon, 10 Oct 2016 11:33:05 +0200
Subject: [CMake] Crosscompilation woes
In-Reply-To: <4671236c83d94d60abd40279f16b66a8@hosted3-mb01.itm.host>
References: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
 <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
 <7ab91f3c9c194fc3824da377170e8036@hosted3-mb01.itm.host>
 <c1f16514-526e-a9cc-8009-c4413b92cfcd@imag.fr>
 <4671236c83d94d60abd40279f16b66a8@hosted3-mb01.itm.host>
Message-ID: <a220d4db-979d-7311-b897-4d21e4dcfc8f@imag.fr>

I cannot answer your question: I am a newcomer to Cmake (I have been 
using it for less than 6 months) and on my build system I have 3.6, so I 
never really looked at the previous versions.

Sorry,


Michele


Le 10/10/2016 ? 11:30, Robert Bielik a ?crit :
>
> Thank you Michele,
>
> This is exactly what I?m after. You specify cmake v3.6 docs ? Is it 
> only working from 3.6.x ? I have 3.5.2 on my build system.
>
> Regards
>
> /Robert
>
> *From:*portolan [mailto:michele.portolan at imag.fr]
> *Sent:* den 10 oktober 2016 11:27
> *To:* Robert Bielik <Robert.Bielik at dirac.com>; Craig Scott 
> <craig.scott at crascit.com>
> *Cc:* Cmake at cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
> In my project I build on Linux i686 and I use a Toolchain file to 
> specify the ARM cross-compiler
>
> https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html
>
> The nice thing is that if you mark some files as "generated" CMAKE 
> will automatically use the build rather than the target toolchains. 
> For instance, I have a Flex/Byson compiler that is generated locally 
> on i686 , but then compiled for ARM.
>
> Regards,
>
> Michele
>
> Le 10/10/2016 ? 11:10, Robert Bielik a ?crit :
>
>     Thanks Craig,
>
>     Your solution will work for me I think.
>
>     Regards
>
>     /R
>
>     *From:*Craig Scott [mailto:craig.scott at crascit.com]
>     *Sent:* den 10 oktober 2016 10:47
>     *To:* Robert Bielik <Robert.Bielik at dirac.com>
>     <mailto:Robert.Bielik at dirac.com>
>     *Cc:* Cmake at cmake.org <mailto:Cmake at cmake.org>
>     *Subject:* Re: [CMake] Crosscompilation woes
>
>     Here's one possible solution (not perfect, but has been working in
>     production for us for a while now for a similar scenario to what
>     you describe):
>
>     http://stackoverflow.com/q/36084785/1938798
>
>     An alternative is a superbuild arrangement which would require a
>     top level project to drive two sub-builds brought in via
>     ExternalProject
>     <https://cmake.org/cmake/help/latest/module/ExternalProject.html>,
>     one for the host and the other for arm. This is both better and
>     worse, depending on your point of view, so you may need to do some
>     research/experimenting to see which is a better fit for your
>     situation.
>
>     On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik
>     <Robert.Bielik at dirac.com <mailto:Robert.Bielik at dirac.com>> wrote:
>
>         Hi all,
>
>         I am crosscompiling a project for arm (on linux i686), and use
>         codegeneration tools within the project (together with
>         add_custom_command). Of course, this will fail, since the
>         tools are compiled for arm also and thus won't execute on my
>         host system. So the tools need to be compiled for i686 whilst
>         the rest for arm. I'm sure this can be handled by CMake
>         although haven't done it before so would appreciate pointers :)
>
>         Regards
>         /Robert
>
>         --
>
>         Powered by www.kitware.com <http://www.kitware.com>
>
>         Please keep messages on-topic and check the CMake FAQ at:
>         http://www.cmake.org/Wiki/CMake_FAQ
>         <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
>         <http://cmake.org/cmake/help/support.html>
>         CMake Consulting: http://cmake.org/cmake/help/consulting.html
>         <http://cmake.org/cmake/help/consulting.html>
>         CMake Training Courses:
>         http://cmake.org/cmake/help/training.html
>         <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
>
>
>
>     -- 
>
>     Craig Scott
>
>     Melbourne, Australia
>
>     https://crascit.com
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/936ecc52/attachment.html>

From michele.portolan at imag.fr  Mon Oct 10 05:27:08 2016
From: michele.portolan at imag.fr (portolan)
Date: Mon, 10 Oct 2016 11:27:08 +0200
Subject: [CMake] Crosscompilation woes
In-Reply-To: <7ab91f3c9c194fc3824da377170e8036@hosted3-mb01.itm.host>
References: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
 <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
 <7ab91f3c9c194fc3824da377170e8036@hosted3-mb01.itm.host>
Message-ID: <c1f16514-526e-a9cc-8009-c4413b92cfcd@imag.fr>

In my project I build on Linux i686 and I use a Toolchain file to 
specify the ARM cross-compiler

https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html

The nice thing is that if you mark some files as "generated" CMAKE will 
automatically use the build rather than the target toolchains. For 
instance, I have a Flex/Byson compiler that is generated locally on i686 
, but then compiled for ARM.

Regards,

Michele

Le 10/10/2016 ? 11:10, Robert Bielik a ?crit :
>
> Thanks Craig,
>
> Your solution will work for me I think.
>
> Regards
>
> /R
>
> *From:*Craig Scott [mailto:craig.scott at crascit.com]
> *Sent:* den 10 oktober 2016 10:47
> *To:* Robert Bielik <Robert.Bielik at dirac.com>
> *Cc:* Cmake at cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
> Here's one possible solution (not perfect, but has been working in 
> production for us for a while now for a similar scenario to what you 
> describe):
>
> http://stackoverflow.com/q/36084785/1938798
>
> An alternative is a superbuild arrangement which would require a top 
> level project to drive two sub-builds brought in via ExternalProject 
> <https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one 
> for the host and the other for arm. This is both better and worse, 
> depending on your point of view, so you may need to do some 
> research/experimenting to see which is a better fit for your situation.
>
> On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik 
> <Robert.Bielik at dirac.com <mailto:Robert.Bielik at dirac.com>> wrote:
>
>     Hi all,
>
>     I am crosscompiling a project for arm (on linux i686), and use
>     codegeneration tools within the project (together with
>     add_custom_command). Of course, this will fail, since the tools
>     are compiled for arm also and thus won't execute on my host
>     system. So the tools need to be compiled for i686 whilst the rest
>     for arm. I'm sure this can be handled by CMake although haven't
>     done it before so would appreciate pointers :)
>
>     Regards
>     /Robert
>
>     --
>
>     Powered by www.kitware.com <http://www.kitware.com>
>
>     Please keep messages on-topic and check the CMake FAQ at:
>     http://www.cmake.org/Wiki/CMake_FAQ
>     <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
>     <http://cmake.org/cmake/help/support.html>
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     <http://cmake.org/cmake/help/consulting.html>
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
>     <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
>
>
>
> -- 
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/bb9e7484/attachment-0001.html>

From ew at omikron.net  Mon Oct 10 05:40:35 2016
From: ew at omikron.net (Eduard Wirch)
Date: Mon, 10 Oct 2016 09:40:35 +0000
Subject: [CMake] CMake doesn't detect Microsoft Build Tools 2015 on Windows
	10
Message-ID: <886021DC2383654B9694A31CAFE4E89F0102FF501B@Pegasus.omikron.net>

Hi

I've installed build tools from here: http://landinghub.visualstudio.com/visual-cpp-build-tools
But CMake will automatically detect (and choose) Visual Studio 8 (installed here as well) instead.

Looking into the source:

    const std::string vsregBase =
      "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\";
    std::vector<std::string> vsVerions;
    vsVerions.push_back("VisualStudio\\");
    vsVerions.push_back("VCExpress\\");
    vsVerions.push_back("WDExpress\\");
    struct VSRegistryEntryName
    {
      const char* MSVersion;
      const char* GeneratorName;
    };
    VSRegistryEntryName version[] = {
      /* clang-format needs this comment to break after the opening brace */
      { "7.1", "Visual Studio 7 .NET 2003" },
      { "8.0", "Visual Studio 8 2005" },
      { "9.0", "Visual Studio 9 2008" },
      { "10.0", "Visual Studio 10 2010" },
      { "11.0", "Visual Studio 11 2012" },
      { "12.0", "Visual Studio 12 2013" },
      { "14.0", "Visual Studio 14 2015" },
      { "15.0", "Visual Studio 15" },
      { 0, 0 }
    };
    for (int i = 0; version[i].MSVersion != 0; i++) {
      for (size_t b = 0; b < vsVerions.size(); b++) {
        std::string reg = vsregBase + vsVerions[b] + version[i].MSVersion;
        reg += ";InstallDir]";
        cmSystemTools::ExpandRegistryValues(reg, cmSystemTools::KeyWOW64_32);
        if (!(reg == "/registry")) {
          installedCompiler = version[i].GeneratorName;
          break;
        }
      }
    }

CMake will look for 'HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\InstallDir'. This key is not present indeed. When specified explicitly:
    cmake . -G "Visual Studio 14 2015"
CMake will correctly detect the compiler and build without problems.

These keys might be helpful when looking for Build Tools:

    [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\VC]
    "ProductDir"="C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\"

    [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\SSDT]
    "InstallDir"="C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\"
    "VersionNumber"="14.0.50616.0"

Am I missing something or is this a bug which should be reported to issue tracker?

Cheers,
Eduard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/82aea69e/attachment.html>

From Robert.Bielik at dirac.com  Mon Oct 10 06:48:22 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Mon, 10 Oct 2016 10:48:22 +0000
Subject: [CMake] Crosscompilation woes
In-Reply-To: <a220d4db-979d-7311-b897-4d21e4dcfc8f@imag.fr>
References: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
 <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
 <7ab91f3c9c194fc3824da377170e8036@hosted3-mb01.itm.host>
 <c1f16514-526e-a9cc-8009-c4413b92cfcd@imag.fr>
 <4671236c83d94d60abd40279f16b66a8@hosted3-mb01.itm.host>
 <a220d4db-979d-7311-b897-4d21e4dcfc8f@imag.fr>
Message-ID: <499fa9b6ed12467baa13928e9b1fb739@hosted3-mb01.itm.host>

Ok, I cannot get this to work. The source files to be generated with add_custom_command have property GENERATED set to ON, but cmake does not adhere, and tries to use the tool binaries of the target system.

Michele, would you be ok with sharing your cmake code for this particular bit ?

Regards
/R

From: portolan [mailto:michele.portolan at imag.fr]
Sent: den 10 oktober 2016 11:33
To: Robert Bielik <Robert.Bielik at dirac.com>; Craig Scott <craig.scott at crascit.com>
Cc: Cmake at cmake.org
Subject: Re: [CMake] Crosscompilation woes


I cannot answer your question: I am a newcomer to Cmake (I have been using it for less than 6 months) and on my build system I have 3.6, so I never really looked at the previous versions.

Sorry,



Michele

Le 10/10/2016 ? 11:30, Robert Bielik a ?crit :
Thank you Michele,

This is exactly what I'm after. You specify cmake v3.6 docs ? Is it only working from 3.6.x ? I have 3.5.2 on my build system.

Regards
/Robert

From: portolan [mailto:michele.portolan at imag.fr]
Sent: den 10 oktober 2016 11:27
To: Robert Bielik <Robert.Bielik at dirac.com><mailto:Robert.Bielik at dirac.com>; Craig Scott <craig.scott at crascit.com><mailto:craig.scott at crascit.com>
Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes


In my project I build on Linux i686 and I use a Toolchain file to specify the ARM cross-compiler

https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html
The nice thing is that if you mark some files as "generated" CMAKE will automatically use the build rather than the target toolchains. For instance, I have a Flex/Byson compiler that is generated locally on i686 , but then compiled for ARM.

Regards,

Michele
Le 10/10/2016 ? 11:10, Robert Bielik a ?crit :
Thanks Craig,

Your solution will work for me I think.

Regards
/R

From: Craig Scott [mailto:craig.scott at crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik <Robert.Bielik at dirac.com><mailto:Robert.Bielik at dirac.com>
Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level project to drive two sub-builds brought in via ExternalProject<https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one for the host and the other for arm. This is both better and worse, depending on your point of view, so you may need to do some research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration tools within the project (together with add_custom_command). Of course, this will fail, since the tools are compiled for arm also and thus won't execute on my host system. So the tools need to be compiled for i686 whilst the rest for arm. I'm sure this can be handled by CMake although haven't done it before so would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com<http://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



--
Craig Scott
Melbourne, Australia
https://crascit.com





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/c3daa3bb/attachment-0001.html>

From michele.portolan at imag.fr  Mon Oct 10 07:13:34 2016
From: michele.portolan at imag.fr (portolan)
Date: Mon, 10 Oct 2016 13:13:34 +0200
Subject: [CMake] Crosscompilation woes
In-Reply-To: <499fa9b6ed12467baa13928e9b1fb739@hosted3-mb01.itm.host>
References: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
 <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
 <7ab91f3c9c194fc3824da377170e8036@hosted3-mb01.itm.host>
 <c1f16514-526e-a9cc-8009-c4413b92cfcd@imag.fr>
 <4671236c83d94d60abd40279f16b66a8@hosted3-mb01.itm.host>
 <a220d4db-979d-7311-b897-4d21e4dcfc8f@imag.fr>
 <499fa9b6ed12467baa13928e9b1fb739@hosted3-mb01.itm.host>
Message-ID: <cafed2a5-698e-03b8-7c79-d7d5d7a2b87d@imag.fr>

It is pretty much standard. I wrote the toolchain file adapting 
different examples.

the Cmakelist is for the subdirectory of my parser (called SIT_parser). 
The trick si that I use a custom command for Lex/Yacc, so even when 
cross-compiling it is still correctly called.


Michele



Le 10/10/2016 ? 12:48, Robert Bielik a ?crit :
>
> Ok, I cannot get this to work. The source files to be generated with 
> add_custom_command have property GENERATED set to ON, but cmake does 
> not adhere, and tries to use the tool binaries of the target system.
>
> Michele, would you be ok with sharing your cmake code for this 
> particular bit ?
>
> Regards
>
> /R
>
> *From:*portolan [mailto:michele.portolan at imag.fr]
> *Sent:* den 10 oktober 2016 11:33
> *To:* Robert Bielik <Robert.Bielik at dirac.com>; Craig Scott 
> <craig.scott at crascit.com>
> *Cc:* Cmake at cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
> I cannot answer your question: I am a newcomer to Cmake (I have been 
> using it for less than 6 months) and on my build system I have 3.6, so 
> I never really looked at the previous versions.
>
> Sorry,
>
> Michele
>
> Le 10/10/2016 ? 11:30, Robert Bielik a ?crit :
>
>     Thank you Michele,
>
>     This is exactly what I?m after. You specify cmake v3.6 docs ? Is
>     it only working from 3.6.x ? I have 3.5.2 on my build system.
>
>     Regards
>
>     /Robert
>
>     *From:*portolan [mailto:michele.portolan at imag.fr]
>     *Sent:* den 10 oktober 2016 11:27
>     *To:* Robert Bielik <Robert.Bielik at dirac.com>
>     <mailto:Robert.Bielik at dirac.com>; Craig Scott
>     <craig.scott at crascit.com> <mailto:craig.scott at crascit.com>
>     *Cc:* Cmake at cmake.org <mailto:Cmake at cmake.org>
>     *Subject:* Re: [CMake] Crosscompilation woes
>
>     In my project I build on Linux i686 and I use a Toolchain file to
>     specify the ARM cross-compiler
>
>     https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html
>
>     The nice thing is that if you mark some files as "generated" CMAKE
>     will automatically use the build rather than the target
>     toolchains. For instance, I have a Flex/Byson compiler that is
>     generated locally on i686 , but then compiled for ARM.
>
>     Regards,
>
>     Michele
>
>     Le 10/10/2016 ? 11:10, Robert Bielik a ?crit :
>
>         Thanks Craig,
>
>         Your solution will work for me I think.
>
>         Regards
>
>         /R
>
>         *From:*Craig Scott [mailto:craig.scott at crascit.com]
>         *Sent:* den 10 oktober 2016 10:47
>         *To:* Robert Bielik <Robert.Bielik at dirac.com>
>         <mailto:Robert.Bielik at dirac.com>
>         *Cc:* Cmake at cmake.org <mailto:Cmake at cmake.org>
>         *Subject:* Re: [CMake] Crosscompilation woes
>
>         Here's one possible solution (not perfect, but has been
>         working in production for us for a while now for a similar
>         scenario to what you describe):
>
>         http://stackoverflow.com/q/36084785/1938798
>
>         An alternative is a superbuild arrangement which would require
>         a top level project to drive two sub-builds brought in via
>         ExternalProject
>         <https://cmake.org/cmake/help/latest/module/ExternalProject.html>,
>         one for the host and the other for arm. This is both better
>         and worse, depending on your point of view, so you may need to
>         do some research/experimenting to see which is a better fit
>         for your situation.
>
>         On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik
>         <Robert.Bielik at dirac.com <mailto:Robert.Bielik at dirac.com>> wrote:
>
>             Hi all,
>
>             I am crosscompiling a project for arm (on linux i686), and
>             use codegeneration tools within the project (together with
>             add_custom_command). Of course, this will fail, since the
>             tools are compiled for arm also and thus won't execute on
>             my host system. So the tools need to be compiled for i686
>             whilst the rest for arm. I'm sure this can be handled by
>             CMake although haven't done it before so would appreciate
>             pointers :)
>
>             Regards
>             /Robert
>
>             --
>
>             Powered by www.kitware.com <http://www.kitware.com>
>
>             Please keep messages on-topic and check the CMake FAQ at:
>             http://www.cmake.org/Wiki/CMake_FAQ
>             <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
>             <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
>
>
>
>         -- 
>
>         Craig Scott
>
>         Melbourne, Australia
>
>         https://crascit.com
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/f5ef7a62/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Toolchain-arm.cmake
Type: text/x-cmake
Size: 1022 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/f5ef7a62/attachment-0001.bin>
-------------- next part --------------
cmake_minimum_required(VERSION 3.5)
project(SIT_parser)

find_package(FLEX)
find_package(BISON)
if ( NOT FLEX_FOUND)
 message( FATAL_ERROR "Flex not found")
endif()

if (NOT BISON_FOUND)
 message( FATAL_ERROR "Bison not found")
endif()

add_definitions(${P_WARNINGS})
set (P_WARNINGS "-Wall -Wno-sign-compare -Wnon-virtual-dtor -Wredundant-decls -Wundef -Wmissing-declarations -Wmissing-include-dirs")
add_definitions(${P_CFLAGS})
set (P_CFLAGS "${P_WARNINGS} -std=c++14")

add_definitions(${Flex_Switches})
if (WIN32)
#+  set (P_CFLAGS ${P_CFLAGS} -DBUILD_DLL)
  set (P_CFLAGS ${P_CFLAGS})
	set (Flex_Switches -v -L)
else()
  set (P_CFLAGS "${P_CFLAGS} -fPIC")
	set (Flex_Switches -v -L)
endif()


set (LEX_YACC_SRC_DIR  "${CMAKE_CURRENT_SOURCE_DIR}/")

# Create custom command for flex/lex (note the outputs)
ADD_CUSTOM_TARGET(SIT_Lexer_class echo "Creating SIT_lexer")
add_custom_command(
  OUTPUT ${LEX_YACC_SRC_DIR}SIT_lexer.yy.cc
  COMMAND flex ${Flex_Switches}  -o${LEX_YACC_SRC_DIR}SIT_lexer.yy.cc ${LEX_YACC_SRC_DIR}SIT_lexer.l
  DEPENDS SIT_lexer.l
)

# Create target for the parser
ADD_CUSTOM_TARGET(SIT_Parser_class echo "Creating SIT_parser")
add_custom_command(
  OUTPUT ${LEX_YACC_SRC_DIR}SIT_parser.tab.cc ${LEX_YACC_SRC_DIR}SIT_parser.tab.hh
  COMMAND bison -d -v -l ${LEX_YACC_SRC_DIR}SIT_parser.yy -o ${LEX_YACC_SRC_DIR}SIT_parser.tab.cc
  DEPENDS SIT_parser.yy
)

# Add parser.c to the list of sources
#+SET(SIT_parser_SRCS ${SIT_parser_SRC} ${LEX_YACC_SRC_DIR}SIT_parser.tab.cc ${LEX_YACC_SRC_DIR}SIT_lexer.yy.cc)

# Since parser.c does not exists yet when cmake is run, mark it as generated
SET_SOURCE_FILES_PROPERTIES(${LEX_YACC_SRC_DIR}SIT_parser.tab.cc GENERATED)
SET_SOURCE_FILES_PROPERTIES(${LEX_YACC_SRC_DIR}SIT_lexer.yy.cc 	 GENERATED)

# Include binary directory to include lexer.c in parser.c
#+include_directories(${CMAKE_BINARY_DIR}/SIT_parser/)

include_directories(${CMAKE_CURRENT_SOURCE_DIR}/)

add_executable 	(SIT_reader_demo 	${LEX_YACC_SRC_DIR}main.cpp)

set_target_properties(SIT_reader_demo PROPERTIES COMPILE_FLAGS "${P_CFLAGS}" )

From Robert.Bielik at dirac.com  Mon Oct 10 07:18:31 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Mon, 10 Oct 2016 11:18:31 +0000
Subject: [CMake] Crosscompilation woes
In-Reply-To: <cafed2a5-698e-03b8-7c79-d7d5d7a2b87d@imag.fr>
References: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
 <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
 <7ab91f3c9c194fc3824da377170e8036@hosted3-mb01.itm.host>
 <c1f16514-526e-a9cc-8009-c4413b92cfcd@imag.fr>
 <4671236c83d94d60abd40279f16b66a8@hosted3-mb01.itm.host>
 <a220d4db-979d-7311-b897-4d21e4dcfc8f@imag.fr>
 <499fa9b6ed12467baa13928e9b1fb739@hosted3-mb01.itm.host>
 <cafed2a5-698e-03b8-7c79-d7d5d7a2b87d@imag.fr>
Message-ID: <f5f513c5706d44b884d40dd398cffc38@hosted3-mb01.itm.host>

Aha, I see. You're using find_package. That will automatically get you the binaries for your host system.

My problem is different, I need to build my binaries with CMake before using them, and I need to build them with i686 (instead of arm).

Regards
/R

From: portolan [mailto:michele.portolan at imag.fr]
Sent: den 10 oktober 2016 13:14
To: Robert Bielik <Robert.Bielik at dirac.com>; Cmake at cmake.org
Subject: Re: [CMake] Crosscompilation woes


It is pretty much standard. I wrote the toolchain file adapting different examples.

the Cmakelist is for the subdirectory of my parser (called SIT_parser). The trick si that I use a custom command for Lex/Yacc, so even when cross-compiling it is still correctly called.



Michele



Le 10/10/2016 ? 12:48, Robert Bielik a ?crit :
Ok, I cannot get this to work. The source files to be generated with add_custom_command have property GENERATED set to ON, but cmake does not adhere, and tries to use the tool binaries of the target system.

Michele, would you be ok with sharing your cmake code for this particular bit ?

Regards
/R

From: portolan [mailto:michele.portolan at imag.fr]
Sent: den 10 oktober 2016 11:33
To: Robert Bielik <Robert.Bielik at dirac.com><mailto:Robert.Bielik at dirac.com>; Craig Scott <craig.scott at crascit.com><mailto:craig.scott at crascit.com>
Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes


I cannot answer your question: I am a newcomer to Cmake (I have been using it for less than 6 months) and on my build system I have 3.6, so I never really looked at the previous versions.

Sorry,



Michele

Le 10/10/2016 ? 11:30, Robert Bielik a ?crit :
Thank you Michele,

This is exactly what I'm after. You specify cmake v3.6 docs ? Is it only working from 3.6.x ? I have 3.5.2 on my build system.

Regards
/Robert

From: portolan [mailto:michele.portolan at imag.fr]
Sent: den 10 oktober 2016 11:27
To: Robert Bielik <Robert.Bielik at dirac.com><mailto:Robert.Bielik at dirac.com>; Craig Scott <craig.scott at crascit.com><mailto:craig.scott at crascit.com>
Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes


In my project I build on Linux i686 and I use a Toolchain file to specify the ARM cross-compiler

https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html
The nice thing is that if you mark some files as "generated" CMAKE will automatically use the build rather than the target toolchains. For instance, I have a Flex/Byson compiler that is generated locally on i686 , but then compiled for ARM.

Regards,

Michele
Le 10/10/2016 ? 11:10, Robert Bielik a ?crit :
Thanks Craig,

Your solution will work for me I think.

Regards
/R

From: Craig Scott [mailto:craig.scott at crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik <Robert.Bielik at dirac.com><mailto:Robert.Bielik at dirac.com>
Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level project to drive two sub-builds brought in via ExternalProject<https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one for the host and the other for arm. This is both better and worse, depending on your point of view, so you may need to do some research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration tools within the project (together with add_custom_command). Of course, this will fail, since the tools are compiled for arm also and thus won't execute on my host system. So the tools need to be compiled for i686 whilst the rest for arm. I'm sure this can be handled by CMake although haven't done it before so would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com<http://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



--
Craig Scott
Melbourne, Australia
https://crascit.com









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/b6537a30/attachment-0001.html>

From Robert.Bielik at dirac.com  Mon Oct 10 07:50:59 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Mon, 10 Oct 2016 11:50:59 +0000
Subject: [CMake] Crosscompilation woes
In-Reply-To: <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
References: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
 <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
Message-ID: <8e503e56a186425fb4ae7b500262462f@hosted3-mb01.itm.host>

I?m trying to do this, but since I setup a cross compiling env. by setting C&C++ compiler, these settings get used when I run execute_process to setup the host build !! Thus I get the ARM version of the build tools anyway! :(

It seems that when execute_process is executed, the CC and CXX environment variables are set, which makes cmake use those when generating the makefiles.

Ideas are most welcome!

Regards
/R

From: Craig Scott [mailto:craig.scott at crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik <Robert.Bielik at dirac.com>
Cc: Cmake at cmake.org
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level project to drive two sub-builds brought in via ExternalProject<https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one for the host and the other for arm. This is both better and worse, depending on your point of view, so you may need to do some research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration tools within the project (together with add_custom_command). Of course, this will fail, since the tools are compiled for arm also and thus won't execute on my host system. So the tools need to be compiled for i686 whilst the rest for arm. I'm sure this can be handled by CMake although haven't done it before so would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com<http://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



--
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/1251bb33/attachment.html>

From craig.scott at crascit.com  Mon Oct 10 07:56:14 2016
From: craig.scott at crascit.com (Craig Scott)
Date: Mon, 10 Oct 2016 22:56:14 +1100
Subject: [CMake] Crosscompilation woes
In-Reply-To: <8e503e56a186425fb4ae7b500262462f@hosted3-mb01.itm.host>
References: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
 <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
 <8e503e56a186425fb4ae7b500262462f@hosted3-mb01.itm.host>
Message-ID: <CA+dygYkWC7YQc7xe695WjFQ08aJE=AJSCuy+k5vquoReYG+95g@mail.gmail.com>

Don't use environment variables to set the ARM compilers in your situation,
use a toolchain file to specify them instead. Your CMake experience will
generally be smoother if you specify cross-compile details via toolchain
files. If you are following the method in the stackoverflow link I
mentioned last time, the host part of the build will then pick up the host
compilers and the ARM part of the build will use the compilers from the
toolchain file.


On Mon, Oct 10, 2016 at 10:50 PM, Robert Bielik <Robert.Bielik at dirac.com>
wrote:

> I?m trying to do this, but since I setup a cross compiling env. by setting
> C&C++ compiler, these settings get used when I run execute_process to setup
> the host build !! Thus I get the ARM version of the build tools anyway! :(
>
>
>
> It seems that when execute_process is executed, the CC and CXX environment
> variables are set, which makes cmake use those when generating the
> makefiles.
>
>
>
> Ideas are most welcome!
>
>
>
> Regards
>
> /R
>
>
>
> *From:* Craig Scott [mailto:craig.scott at crascit.com]
> *Sent:* den 10 oktober 2016 10:47
> *To:* Robert Bielik <Robert.Bielik at dirac.com>
> *Cc:* Cmake at cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
>
>
> Here's one possible solution (not perfect, but has been working in
> production for us for a while now for a similar scenario to what you
> describe):
>
>
>
> http://stackoverflow.com/q/36084785/1938798
>
>
>
> An alternative is a superbuild arrangement which would require a top level
> project to drive two sub-builds brought in via ExternalProject
> <https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one
> for the host and the other for arm. This is both better and worse,
> depending on your point of view, so you may need to do some
> research/experimenting to see which is a better fit for your situation.
>
>
>
>
>
> On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <Robert.Bielik at dirac.com>
> wrote:
>
> Hi all,
>
> I am crosscompiling a project for arm (on linux i686), and use
> codegeneration tools within the project (together with add_custom_command).
> Of course, this will fail, since the tools are compiled for arm also and
> thus won't execute on my host system. So the tools need to be compiled for
> i686 whilst the rest for arm. I'm sure this can be handled by CMake
> although haven't done it before so would appreciate pointers :)
>
> Regards
> /Robert
>
> --
>
> 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
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/c0716530/attachment-0001.html>

From Robert.Bielik at dirac.com  Mon Oct 10 08:00:20 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Mon, 10 Oct 2016 12:00:20 +0000
Subject: [CMake] Crosscompilation woes
In-Reply-To: <CA+dygYkWC7YQc7xe695WjFQ08aJE=AJSCuy+k5vquoReYG+95g@mail.gmail.com>
References: <fd6c62a9a2de4441a7a1349d62448c5d@hosted3-mb01.itm.host>
 <CA+dygY=fGCfK-G7hqHVdgVR2fFB1MqrZzO4QuL-QDSTB8zF-6Q@mail.gmail.com>
 <8e503e56a186425fb4ae7b500262462f@hosted3-mb01.itm.host>
 <CA+dygYkWC7YQc7xe695WjFQ08aJE=AJSCuy+k5vquoReYG+95g@mail.gmail.com>
Message-ID: <9f6f039ba3de463b91c7e9b7e62a1d0b@hosted3-mb01.itm.host>

I am using a toolchain file! The CC and CXX environment variables are set by CMake (I assume, because I haven?t touched them).

I?ll disect the link to see what I?ve missed.

Regards
/R

From: Craig Scott [mailto:craig.scott at crascit.com]
Sent: den 10 oktober 2016 13:56
To: Robert Bielik <Robert.Bielik at dirac.com>
Cc: Cmake at cmake.org
Subject: Re: [CMake] Crosscompilation woes

Don't use environment variables to set the ARM compilers in your situation, use a toolchain file to specify them instead. Your CMake experience will generally be smoother if you specify cross-compile details via toolchain files. If you are following the method in the stackoverflow link I mentioned last time, the host part of the build will then pick up the host compilers and the ARM part of the build will use the compilers from the toolchain file.


On Mon, Oct 10, 2016 at 10:50 PM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
I?m trying to do this, but since I setup a cross compiling env. by setting C&C++ compiler, these settings get used when I run execute_process to setup the host build !! Thus I get the ARM version of the build tools anyway! :(

It seems that when execute_process is executed, the CC and CXX environment variables are set, which makes cmake use those when generating the makefiles.

Ideas are most welcome!

Regards
/R

From: Craig Scott [mailto:craig.scott at crascit.com<mailto:craig.scott at crascit.com>]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>>
Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level project to drive two sub-builds brought in via ExternalProject<https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one for the host and the other for arm. This is both better and worse, depending on your point of view, so you may need to do some research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration tools within the project (together with add_custom_command). Of course, this will fail, since the tools are compiled for arm also and thus won't execute on my host system. So the tools need to be compiled for i686 whilst the rest for arm. I'm sure this can be handled by CMake although haven't done it before so would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com<http://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



--
Craig Scott
Melbourne, Australia
https://crascit.com



--
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/3024965c/attachment-0001.html>

From piponazo at gmail.com  Mon Oct 10 08:46:01 2016
From: piponazo at gmail.com (=?UTF-8?B?THVpcyBEw61heiBNw6Fz?=)
Date: Mon, 10 Oct 2016 14:46:01 +0200
Subject: [CMake] Error with ninja generator when using
 target_link_library with the debug keyword
Message-ID: <CAGBsks8toTqR-k-8-EhbkQbs-3fBuAB37BSQ+C4Oq5TXuhmJAw@mail.gmail.com>

Hi,

I just want to confirm that I have the same problem on Windows with the
Ninja generator. Even when I always use both keywords (debug & optimized)
in my *target_link_libraries *commands I still got a *ninja.build *file
that has bad $-escape characters.

I think that this problem is happening only when I tried to compile a
library twice (shared and static) and I tried to propagate the
*LINK_LIBRARIES* property from the shared library to the static one:

        add_library(mylib SHARED ${mylib_all_sources})
        add_library(mylib_static STATIC EXCLUDE_FROM_ALL ${mylib
_all_sources})

        target_link_libraries(mylib PUBLIC ${SOME_LIBS})
        target_link_libraries(mylib_static PUBLIC
$<TARGET_PROPERTY:mylib,LINK_LIBRARIES>)

Only in that situation is when I got the weird bad $-escape characters on
the ninja.build file. This is an example of the line with these problems:

  LINK_LIBRARIES = C:\myProject\buildRelease\bin64\library1.lib
  C:\myProject\buildRelease\bin64\library2.lib
  C:\myProject\libs\gmock.lib
  C:\myProject\libs\CGAL-vc120-mt-4.4.lib
  C:\myProject\libs\exiv2.lib
  C:\myProject\libs\ceres.lib
  ... // removing some lines
  $<$<NOT:$<CONFIG:DEBUG>>:C:/myProject\libs/CGAL-vc120-mt-4.4.lib>
  $<$<CONFIG:DEBUG>:C:/myProject\libs/CGAL-vc120-mt-gd-4.4.lib>
  ... // removing some lines
  $<$<NOT:$<CONFIG:DEBUG>>:C:/myProject\libs/exiv2.lib>
  $<$<CONFIG:DEBUG>:C:/myProject\libs/exiv2d.lib>
  $<$<NOT:$<CONFIG:DEBUG>>:C:/myProject\libs/ceres.lib>
  $<$<CONFIG:DEBUG>:C:/myProject\libs/ceres-debug.lib>
  ...
  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib

I will try to create a minimum example to reproduce this issue.

Cheers,
Luis


2016-10-05 16:39 GMT+02:00 Luis D?az M?s <piponazo at gmail.com>:

> Hi all,
>
> I have found a problem while configuring a project and I want to share the
> experience with you to figure out whether it is a known problem or a bug in
> CMake.
>
> In some cases I use the cmake command *target_link_libraries *specifying
> different libraries for the *debug* and *optimized* modes. This normally
> work as expected. However recently we got a problem with the Ninja
> generator. This is what I could see in the console when I try to compile
> the project:
>
> ninja: error: build.ninja:4956: bad $-escape (literal $ must be written as
> $$)
>
>
> The content of the file in that particular line has something like this:
>
> $<$<CONFIG:DEBUG>:/home/luis/xxxx//lib/libCGAL.so>
>
> Examining my cmake configuration I noticed that a colleague introduced
> something like that in the *target_link_libraries* call:
>
>             ${ZLIB_LIBRARIES}
>             debug;${CGAL_LIB}
>             ${GMP_LIB}
>
> If we specify the debug & optimized modes we do not have problems. However
> in this particular case, it seems that we only need to link against the
> CGAL in debug mode and not in release mode. Note that with a Make generator
> we can compile normally the project.
>
> The work around for this case is to link normally against CGAL when we are
> in Debug mode:
>
>         if (${CMAKE_BUILD_TYPE} STREQUAL Debug)
>             target_link_libraries(myTarget ${CGAL_LIB}
>         endif()
>
> So ... the questions are:
>
>
>    - Is it possible to use *target_link_libraries *only with one of the
>    modes (debug  / optimized) ?
>    - The Make generator works properly for this case. Could it be a bug
>    with the Ninja generator? I tried with the most recent versions of CMake &
>    Ninja.
>
> Best regards,
> Luis Diaz Mas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/1c025eae/attachment.html>

From Robert.Bielik at dirac.com  Mon Oct 10 09:56:08 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Mon, 10 Oct 2016 13:56:08 +0000
Subject: [CMake] [SOLVED] RE:  Crosscompilation woes
Message-ID: <dfdc68c716eb4ebc858ed0b72f29220b@hosted3-mb01.itm.host>

For reference: I went with Brads suggestion: https://gitlab.kitware.com/cmake/cmake/issues/16356

which seems to be working fine.

Regards
/R

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Bielik
Sent: den 10 oktober 2016 14:00
To: Craig Scott <craig.scott at crascit.com>
Cc: Cmake at cmake.org
Subject: Re: [CMake] Crosscompilation woes

I am using a toolchain file! The CC and CXX environment variables are set by CMake (I assume, because I haven?t touched them).

I?ll disect the link to see what I?ve missed.

Regards
/R

From: Craig Scott [mailto:craig.scott at crascit.com]
Sent: den 10 oktober 2016 13:56
To: Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>>
Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes

Don't use environment variables to set the ARM compilers in your situation, use a toolchain file to specify them instead. Your CMake experience will generally be smoother if you specify cross-compile details via toolchain files. If you are following the method in the stackoverflow link I mentioned last time, the host part of the build will then pick up the host compilers and the ARM part of the build will use the compilers from the toolchain file.


On Mon, Oct 10, 2016 at 10:50 PM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
I?m trying to do this, but since I setup a cross compiling env. by setting C&C++ compiler, these settings get used when I run execute_process to setup the host build !! Thus I get the ARM version of the build tools anyway! :(

It seems that when execute_process is executed, the CC and CXX environment variables are set, which makes cmake use those when generating the makefiles.

Ideas are most welcome!

Regards
/R

From: Craig Scott [mailto:craig.scott at crascit.com<mailto:craig.scott at crascit.com>]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>>
Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level project to drive two sub-builds brought in via ExternalProject<https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one for the host and the other for arm. This is both better and worse, depending on your point of view, so you may need to do some research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration tools within the project (together with add_custom_command). Of course, this will fail, since the tools are compiled for arm also and thus won't execute on my host system. So the tools need to be compiled for i686 whilst the rest for arm. I'm sure this can be handled by CMake although haven't done it before so would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com<http://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



--
Craig Scott
Melbourne, Australia
https://crascit.com



--
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/007eb082/attachment-0001.html>

From gilles.khouzam at microsoft.com  Mon Oct 10 11:35:58 2016
From: gilles.khouzam at microsoft.com (Gilles Khouzam)
Date: Mon, 10 Oct 2016 15:35:58 +0000
Subject: [CMake] CMake doesn't detect Microsoft Build Tools 2015 on
 Windows	10
In-Reply-To: <886021DC2383654B9694A31CAFE4E89F0102FF501B@Pegasus.omikron.net>
References: <886021DC2383654B9694A31CAFE4E89F0102FF501B@Pegasus.omikron.net>
Message-ID: <CY1PR03MB1406F4D3329B8F38D51CD77B98DB0@CY1PR03MB1406.namprd03.prod.outlook.com>

Please open a bug, I can take a look at it.

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Eduard Wirch
Sent: Monday, October 10, 2016 02:41
To: cmake at cmake.org
Subject: [CMake] CMake doesn't detect Microsoft Build Tools 2015 on Windows 10

Hi

I've installed build tools from here: http://landinghub.visualstudio.com/visual-cpp-build-tools
But CMake will automatically detect (and choose) Visual Studio 8 (installed here as well) instead.

Looking into the source:

    const std::string vsregBase =
      "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\";
    std::vector<std::string> vsVerions;
    vsVerions.push_back("VisualStudio\\");
    vsVerions.push_back("VCExpress\\");
    vsVerions.push_back("WDExpress\\");
    struct VSRegistryEntryName
    {
      const char* MSVersion;
      const char* GeneratorName;
    };
    VSRegistryEntryName version[] = {
      /* clang-format needs this comment to break after the opening brace */
      { "7.1", "Visual Studio 7 .NET 2003" },
      { "8.0", "Visual Studio 8 2005" },
      { "9.0", "Visual Studio 9 2008" },
      { "10.0", "Visual Studio 10 2010" },
      { "11.0", "Visual Studio 11 2012" },
      { "12.0", "Visual Studio 12 2013" },
      { "14.0", "Visual Studio 14 2015" },
      { "15.0", "Visual Studio 15" },
      { 0, 0 }
    };
    for (int i = 0; version[i].MSVersion != 0; i++) {
      for (size_t b = 0; b < vsVerions.size(); b++) {
        std::string reg = vsregBase + vsVerions[b] + version[i].MSVersion;
        reg += ";InstallDir]";
        cmSystemTools::ExpandRegistryValues(reg, cmSystemTools::KeyWOW64_32);
        if (!(reg == "/registry")) {
          installedCompiler = version[i].GeneratorName;
          break;
        }
      }
    }

CMake will look for 'HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\InstallDir'. This key is not present indeed. When specified explicitly:
    cmake . -G "Visual Studio 14 2015"
CMake will correctly detect the compiler and build without problems.

These keys might be helpful when looking for Build Tools:

    [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\VC]
    "ProductDir"="C:\\Program Files (x86)\\Microsoft<file://Microsoft> Visual Studio 14.0\\VC\\"

    [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\SSDT]
    "InstallDir"="C:\\Program Files (x86)\\Microsoft<file://Microsoft> Visual Studio 14.0\\"
    "VersionNumber"="14.0.50616.0"

Am I missing something or is this a bug which should be reported to issue tracker?

Cheers,
Eduard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161010/c5fb4cd2/attachment.html>

From chuck.atkins at kitware.com  Tue Oct 11 11:10:22 2016
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Tue, 11 Oct 2016 11:10:22 -0400
Subject: [CMake] [SOLVED] RE: Crosscompilation woes
In-Reply-To: <dfdc68c716eb4ebc858ed0b72f29220b@hosted3-mb01.itm.host>
References: <dfdc68c716eb4ebc858ed0b72f29220b@hosted3-mb01.itm.host>
Message-ID: <CAOXZzG5L2mXYx8PAAC72U81Bd9gUkPfhiKPCMuu+eCmRBXyCSg@mail.gmail.com>

In VTK and ParaView we use a manual two-step build.  The first pass
configures a host build of the cross-compile utilities and the second pass
configures a target build with a toolchain file, which requires you tell it
where the host tools are.  So the build process looks like this:

mkdir build_host
cd build_host
cmake -DBUILD_CROSSTOOLS=ON /path/to/source
make
cd ..
mkdir build_target
cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/tolchain.cmake
-DFOO_CROSSTOOLS_DIR=/path/to/build_host
make

You should be able to adapt this to a superbuild scenario with two external
projects and it seems like that's exactly what you've done.  Just
confirming that yes that's a sane approach and that's how we do it to.


----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.


On Mon, Oct 10, 2016 at 9:56 AM, Robert Bielik <Robert.Bielik at dirac.com>
wrote:

> For reference: I went with Brads suggestion: https://gitlab.kitware.com/
> cmake/cmake/issues/16356
>
>
>
> which seems to be working fine.
>
>
>
> Regards
>
> /R
>
>
>
> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Robert
> Bielik
> *Sent:* den 10 oktober 2016 14:00
> *To:* Craig Scott <craig.scott at crascit.com>
>
> *Cc:* Cmake at cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
>
>
> I am using a toolchain file! The CC and CXX environment variables are set
> by CMake (I assume, because I haven?t touched them).
>
>
>
> I?ll disect the link to see what I?ve missed.
>
>
>
> Regards
>
> /R
>
>
>
> *From:* Craig Scott [mailto:craig.scott at crascit.com
> <craig.scott at crascit.com>]
> *Sent:* den 10 oktober 2016 13:56
> *To:* Robert Bielik <Robert.Bielik at dirac.com>
> *Cc:* Cmake at cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
>
>
> Don't use environment variables to set the ARM compilers in your
> situation, use a toolchain file to specify them instead. Your CMake
> experience will generally be smoother if you specify cross-compile details
> via toolchain files. If you are following the method in the stackoverflow
> link I mentioned last time, the host part of the build will then pick up
> the host compilers and the ARM part of the build will use the compilers
> from the toolchain file.
>
>
>
>
>
> On Mon, Oct 10, 2016 at 10:50 PM, Robert Bielik <Robert.Bielik at dirac.com>
> wrote:
>
> I?m trying to do this, but since I setup a cross compiling env. by setting
> C&C++ compiler, these settings get used when I run execute_process to setup
> the host build !! Thus I get the ARM version of the build tools anyway! :(
>
>
>
> It seems that when execute_process is executed, the CC and CXX environment
> variables are set, which makes cmake use those when generating the
> makefiles.
>
>
>
> Ideas are most welcome!
>
>
>
> Regards
>
> /R
>
>
>
> *From:* Craig Scott [mailto:craig.scott at crascit.com]
> *Sent:* den 10 oktober 2016 10:47
> *To:* Robert Bielik <Robert.Bielik at dirac.com>
> *Cc:* Cmake at cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
>
>
> Here's one possible solution (not perfect, but has been working in
> production for us for a while now for a similar scenario to what you
> describe):
>
>
>
> http://stackoverflow.com/q/36084785/1938798
>
>
>
> An alternative is a superbuild arrangement which would require a top level
> project to drive two sub-builds brought in via ExternalProject
> <https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one
> for the host and the other for arm. This is both better and worse,
> depending on your point of view, so you may need to do some
> research/experimenting to see which is a better fit for your situation.
>
>
>
>
>
> On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <Robert.Bielik at dirac.com>
> wrote:
>
> Hi all,
>
> I am crosscompiling a project for arm (on linux i686), and use
> codegeneration tools within the project (together with add_custom_command).
> Of course, this will fail, since the tools are compiled for arm also and
> thus won't execute on my host system. So the tools need to be compiled for
> i686 whilst the rest for arm. I'm sure this can be handled by CMake
> although haven't done it before so would appreciate pointers :)
>
> Regards
> /Robert
>
> --
>
> 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
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161011/6bc1500d/attachment-0001.html>

From Robert.Bielik at dirac.com  Tue Oct 11 11:16:51 2016
From: Robert.Bielik at dirac.com (Robert Bielik)
Date: Tue, 11 Oct 2016 15:16:51 +0000
Subject: [CMake] [SOLVED] RE: Crosscompilation woes
In-Reply-To: <CAOXZzG5L2mXYx8PAAC72U81Bd9gUkPfhiKPCMuu+eCmRBXyCSg@mail.gmail.com>
References: <dfdc68c716eb4ebc858ed0b72f29220b@hosted3-mb01.itm.host>
 <CAOXZzG5L2mXYx8PAAC72U81Bd9gUkPfhiKPCMuu+eCmRBXyCSg@mail.gmail.com>
Message-ID: <06c74a4f66504067a427d80201b030b6@hosted3-mb01.itm.host>

Thanks Chuck,

It now actually is a one step automatic build, where the CMake initial pass creates the host tools, sets up CMake cache vars for them, then when the CMake step is finished I can just run make and it all works out fine.

The key issue was unsetting CC and CXX env vars during the creation of the cmake files for the host tools, so that the native build system was being used.

All the best
/Robert

From: Chuck Atkins [mailto:chuck.atkins at kitware.com]
Sent: den 11 oktober 2016 17:10
To: Robert Bielik <Robert.Bielik at dirac.com>
Cc: Cmake at cmake.org
Subject: Re: [CMake] [SOLVED] RE: Crosscompilation woes

In VTK and ParaView we use a manual two-step build.  The first pass configures a host build of the cross-compile utilities and the second pass configures a target build with a toolchain file, which requires you tell it where the host tools are.  So the build process looks like this:
mkdir build_host
cd build_host
cmake -DBUILD_CROSSTOOLS=ON /path/to/source
make
cd ..
mkdir build_target
cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/tolchain.cmake -DFOO_CROSSTOOLS_DIR=/path/to/build_host
make
You should be able to adapt this to a superbuild scenario with two external projects and it seems like that's exactly what you've done.  Just confirming that yes that's a sane approach and that's how we do it to.

----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.

On Mon, Oct 10, 2016 at 9:56 AM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
For reference: I went with Brads suggestion: https://gitlab.kitware.com/cmake/cmake/issues/16356

which seems to be working fine.

Regards
/R

From: CMake [mailto:cmake-bounces at cmake.org<mailto:cmake-bounces at cmake.org>] On Behalf Of Robert Bielik
Sent: den 10 oktober 2016 14:00
To: Craig Scott <craig.scott at crascit.com<mailto:craig.scott at crascit.com>>

Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes

I am using a toolchain file! The CC and CXX environment variables are set by CMake (I assume, because I haven?t touched them).

I?ll disect the link to see what I?ve missed.

Regards
/R

From: Craig Scott [mailto:craig.scott at crascit.com]
Sent: den 10 oktober 2016 13:56
To: Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>>
Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes

Don't use environment variables to set the ARM compilers in your situation, use a toolchain file to specify them instead. Your CMake experience will generally be smoother if you specify cross-compile details via toolchain files. If you are following the method in the stackoverflow link I mentioned last time, the host part of the build will then pick up the host compilers and the ARM part of the build will use the compilers from the toolchain file.


On Mon, Oct 10, 2016 at 10:50 PM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
I?m trying to do this, but since I setup a cross compiling env. by setting C&C++ compiler, these settings get used when I run execute_process to setup the host build !! Thus I get the ARM version of the build tools anyway! :(

It seems that when execute_process is executed, the CC and CXX environment variables are set, which makes cmake use those when generating the makefiles.

Ideas are most welcome!

Regards
/R

From: Craig Scott [mailto:craig.scott at crascit.com<mailto:craig.scott at crascit.com>]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>>
Cc: Cmake at cmake.org<mailto:Cmake at cmake.org>
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level project to drive two sub-builds brought in via ExternalProject<https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one for the host and the other for arm. This is both better and worse, depending on your point of view, so you may need to do some research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <Robert.Bielik at dirac.com<mailto:Robert.Bielik at dirac.com>> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration tools within the project (together with add_custom_command). Of course, this will fail, since the tools are compiled for arm also and thus won't execute on my host system. So the tools need to be compiled for i686 whilst the rest for arm. I'm sure this can be handled by CMake although haven't done it before so would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com<http://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



--
Craig Scott
Melbourne, Australia
https://crascit.com



--
Craig Scott
Melbourne, Australia
https://crascit.com

--

Powered by www.kitware.com<http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161011/be8be05f/attachment-0001.html>

From salazardetro1 at llnl.gov  Tue Oct 11 16:33:17 2016
From: salazardetro1 at llnl.gov (Salazar De Troya, Miguel)
Date: Tue, 11 Oct 2016 20:33:17 +0000
Subject: [CMake] How to use the plugin Geodesic Measurement
Message-ID: <D42297B9.877A%salazardetro1@llnl.gov>

Hello

I loaded the Geodesic Measurement plugin with the Plugin Manager, but I do not know how to use it. I see it as a filter option, but it is disabled even for point-based data. I haven?t been able to find an example either. I am interested in finding the shortest path between two points in a surface.

Thanks
MIguel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161011/44b05c21/attachment.html>

From dave.demarle at kitware.com  Tue Oct 11 16:56:06 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 11 Oct 2016 16:56:06 -0400
Subject: [CMake] How to use the plugin Geodesic Measurement
In-Reply-To: <D42297B9.877A%salazardetro1@llnl.gov>
References: <D42297B9.877A%salazardetro1@llnl.gov>
Message-ID: <CANjZAi_Qy41hLrMzsMMXQOO9UxEubF07SPGbRrZizXoeVqSCsw@mail.gmail.com>

I Miguel,

I think you intended this question for the ParaView mailing list, not the
CMake one.

cheers

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Tue, Oct 11, 2016 at 4:33 PM, Salazar De Troya, Miguel <
salazardetro1 at llnl.gov> wrote:

> Hello
>
> I loaded the Geodesic Measurement plugin with the Plugin Manager, but I do
> not know how to use it. I see it as a filter option, but it is disabled
> even for point-based data. I haven?t been able to find an example either. I
> am interested in finding the shortest path between two points in a surface.
>
> Thanks
> MIguel
>
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161011/2578c6a2/attachment.html>

From paulo.waelkens at gmail.com  Tue Oct 11 18:21:24 2016
From: paulo.waelkens at gmail.com (Paulo Waelkens)
Date: Wed, 12 Oct 2016 00:21:24 +0200
Subject: [CMake] make_directory deprecated. What's the correct solution to
 generate directories at build time now?
Message-ID: <CAO3jT8JDNzyj8S+37gxLWX3fcwe5VJq0+7W-oY70+ZiS+XF0DA@mail.gmail.com>

Hello,

to create a cmake directory *at build time* (
http://stackoverflow.com/questions/3702115/creating-a-directory-in-cmake)
you could use

add_custom_target(build-time-make-directory ALL
    COMMAND ${CMAKE_COMMAND} -E make_directory ${directory})

*"make_directory"* is now listed as deprecated in the new cmake
documentation (https://cmake.org/cmake/help/v3.6/command/make_directory.html
).

How exactly could I repeat the original behaviour without using deprecated
functionality?
I understand that I'm supposed to use *file(MAKE_DIRECTORY ${directory})*
somehow, but don't understand how exactly to connect this with COMMAND.

I've tried to use
*COMMAND ${CMAKE_COMMAND} -E file ...       *(definitely wrong, because
cmake.exe -E <command> [args...] does not list "file" as an available
command)
*COMMAND file(MAKE_DIRECTORY ${directory})*   (wrong, again, *'file' is not
recognized as an internal or external command*)

Does anyone know how to do this right? I'll keep using the deprecated stuff
for now, but that's kind of sad.

Thanks for the help! Cheers,
Paulo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161012/ddd47417/attachment.html>

From iosif.neitzke+cmake at gmail.com  Tue Oct 11 18:57:10 2016
From: iosif.neitzke+cmake at gmail.com (iosif neitzke)
Date: Tue, 11 Oct 2016 17:57:10 -0500
Subject: [CMake] make_directory deprecated. What's the correct solution
 to generate directories at build time now?
In-Reply-To: <CAO3jT8JDNzyj8S+37gxLWX3fcwe5VJq0+7W-oY70+ZiS+XF0DA@mail.gmail.com>
References: <CAO3jT8JDNzyj8S+37gxLWX3fcwe5VJq0+7W-oY70+ZiS+XF0DA@mail.gmail.com>
Message-ID: <CAGyo1owDYymA1EP6eBxkmCfDVcFuyLHBj-pPKy5GZduPWxUgMw@mail.gmail.com>

I think only the cmake script command make_directory is deprecated, not
the cmake command-line tool -E mode make_directory?

On Tue, Oct 11, 2016 at 5:21 PM, Paulo Waelkens
<paulo.waelkens at gmail.com> wrote:
> Hello,
>
> to create a cmake directory at build time
> (http://stackoverflow.com/questions/3702115/creating-a-directory-in-cmake)
> you could use
>
> add_custom_target(build-time-make-directory ALL
>     COMMAND ${CMAKE_COMMAND} -E make_directory ${directory})
>
> "make_directory" is now listed as deprecated in the new cmake documentation
> (https://cmake.org/cmake/help/v3.6/command/make_directory.html).
>
> How exactly could I repeat the original behaviour without using deprecated
> functionality?
> I understand that I'm supposed to use file(MAKE_DIRECTORY ${directory})
> somehow, but don't understand how exactly to connect this with COMMAND.
>
> I've tried to use
> COMMAND ${CMAKE_COMMAND} -E file ...       (definitely wrong, because
> cmake.exe -E <command> [args...] does not list "file" as an available
> command)
> COMMAND file(MAKE_DIRECTORY ${directory})   (wrong, again, 'file' is not
> recognized as an internal or external command)
>
> Does anyone know how to do this right? I'll keep using the deprecated stuff
> for now, but that's kind of sad.
>
> Thanks for the help! Cheers,
> Paulo
>
>
> --
>
> 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

From alexshaver at gmail.com  Wed Oct 12 10:30:19 2016
From: alexshaver at gmail.com (Alex Shaver)
Date: Wed, 12 Oct 2016 14:30:19 +0000
Subject: [CMake] Protobufs and nested file structure
Message-ID: <CACvCP1aepyOw4MAjDAfYnS90tKmHQ0F6UkUzGF_uOEZzOBr==g@mail.gmail.com>

(cmake 3.5, but tested from repo and had same issue, generating UNIX
Makefiles, protobuf 3)

When I have protobufs more than one folder deep (eg, folder with cmake has
folder with protobufs and another folder which also has more protobufs),
cmake has some trouble generating the correct make files.

Suppose in my folder 'protos' with the CMakeLists.txt that generates from
protobuf, I have folders Alpha and Beta. Beta contains Ball.proto; Alpha
contains Axle.proto and folder Aleph with Anchor.proto. When CMake
generates the build directory for protos, it puts Ball.pb.{h,cpp} and
Axle.pb.* in the top level of the protos build folder, a folder Aleph with
Anchor.pb.* . However, the make instructions look for Anchor.pb.* in the
top-level folder, and it fails to find Anchor.pb.cpp for Anchor.pb.o . If I
go in and manually edit the failing line of the make file, make is
successful.

Second, supposing within these directories there are two messages with the
same name, but belonging to separate protobuf 'packages.' CMake complains
that it has already generated a build rule for the given protobuf. I think
this shares the same root issue of cmake respecting nested folder
structures within.

I can think of various solutions to these problems on my end, but it would
be ideal not to have to rearrange the file structure, nor build many
subprojects linked together. Is there a way to get cmake to reproduce the
existing file structure and build as one project?

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161012/f6363ce1/attachment.html>

From annulen at yandex.ru  Wed Oct 12 11:28:09 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Wed, 12 Oct 2016 18:28:09 +0300
Subject: [CMake] Proper way to find system copy of libxml2 on macOS
Message-ID: <5469081476286089@web7g.yandex.ru>

Hello,

In my cmake project I need to use system version of libxml2 on macOS (/usr/lib/libxml2.dylib), however in case it is installed in MacPorts the latter version is picked by find_package. On the other hand I'd like to avoid hardcoding absolute path, just in case Apple changes some path or file name in future OS version.

I've tried 

find_package(LibXml2 2.8.0 REQUIRED PATHS "/usr" NO_DEFAULT_PATH)

however it fails to find anything at all. Any ideas?

-- 
Regards,
Konstantin

From eric.noulard at gmail.com  Wed Oct 12 11:48:41 2016
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 12 Oct 2016 17:48:41 +0200
Subject: [CMake] Proper way to find system copy of libxml2 on macOS
In-Reply-To: <5469081476286089@web7g.yandex.ru>
References: <5469081476286089@web7g.yandex.ru>
Message-ID: <CAPASGLra=N8G_7L2DKE+hQtaEfZ05A9WC2KDxyZ44wtWpbQzDg@mail.gmail.com>

2016-10-12 17:28 GMT+02:00 Konstantin Tokarev <annulen at yandex.ru>:

> Hello,
>
> In my cmake project I need to use system version of libxml2 on macOS
> (/usr/lib/libxml2.dylib), however in case it is installed in MacPorts the
> latter version is picked by find_package. On the other hand I'd like to
> avoid hardcoding absolute path, just in case Apple changes some path or
> file name in future OS version.
>
> I've tried
>
> find_package(LibXml2 2.8.0 REQUIRED PATHS "/usr" NO_DEFAULT_PATH)
>
> however it fails to find anything at all. Any ideas?
>

My guess is that your find_package call end up in "Module mode"  because
there is a FindLibXml2.cmake module bundled with cmake does not honor all
options of the find_package when in this mode.

So I bet FindLibXml2.cmake does not handle the given
"PATHS "/usr" NO_DEFAULT_PATH" part.

Which are handled by find_package when running in "Config mode".

I suggest you to try patch and update the FindLibXml2.cmake module.
Or simply craft your own

find_library(...) call.if you only need the libxml2.
Eric


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



-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161012/00e4d1a7/attachment.html>

From annulen at yandex.ru  Wed Oct 12 12:04:57 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Wed, 12 Oct 2016 19:04:57 +0300
Subject: [CMake] Proper way to find system copy of libxml2 on macOS
In-Reply-To: <CAPASGLra=N8G_7L2DKE+hQtaEfZ05A9WC2KDxyZ44wtWpbQzDg@mail.gmail.com>
References: <5469081476286089@web7g.yandex.ru>
 <CAPASGLra=N8G_7L2DKE+hQtaEfZ05A9WC2KDxyZ44wtWpbQzDg@mail.gmail.com>
Message-ID: <5615741476288297@web7g.yandex.ru>



12.10.2016, 18:48, "Eric Noulard" <eric.noulard at gmail.com>:
> 2016-10-12 17:28 GMT+02:00 Konstantin Tokarev <annulen at yandex.ru>:
>> Hello,
>>
>> In my cmake project I need to use system version of libxml2 on macOS (/usr/lib/libxml2.dylib), however in case it is installed in MacPorts the latter version is picked by find_package. On the other hand I'd like to avoid hardcoding absolute path, just in case Apple changes some path or file name in future OS version.
>>
>> I've tried
>>
>> find_package(LibXml2 2.8.0 REQUIRED PATHS "/usr" NO_DEFAULT_PATH)
>>
>> however it fails to find anything at all. Any ideas?
>
> My guess is that your find_package call end up in "Module mode" ?because there is a FindLibXml2.cmake module bundled with cmake does not honor all options of the find_package when in this mode.
>
> So I bet?FindLibXml2.cmake does not handle the given
> "PATHS "/usr" NO_DEFAULT_PATH" part.
>
> Which are handled by find_package when running in "Config mode".
>
> I suggest you to try patch and update the?FindLibXml2.cmake module.

Could anyone point me to module example that handles NO_DEFAULT_PATH correctly?

> Or simply craft your own
>
> find_library(...) call.if you only need the libxml2.

That's not an elegant solution as I need to find include dir as well, and also do the same for libxslt which is in the same boat.

> Eric
>
>> --
>> 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
>
> --
> Eric


-- 
Regards,
Konstantin

From annulen at yandex.ru  Wed Oct 12 12:07:38 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Wed, 12 Oct 2016 19:07:38 +0300
Subject: [CMake] Proper way to find system copy of libxml2 on macOS
In-Reply-To: <5db80a04f0dc689e5c434b4ef8a6ee02@codelibre.net>
References: <5469081476286089@web7g.yandex.ru>
 <5db80a04f0dc689e5c434b4ef8a6ee02@codelibre.net>
Message-ID: <5626581476288458@web7g.yandex.ru>



12.10.2016, 19:04, "rleigh at codelibre.net" <rleigh at codelibre.net>:
> On 2016-10-12 15:28, Konstantin Tokarev wrote:
>> ?Hello,
>>
>> ?In my cmake project I need to use system version of libxml2 on macOS
>> ?(/usr/lib/libxml2.dylib), however in case it is installed in MacPorts
>> ?the latter version is picked by find_package. On the other hand I'd
>> ?like to avoid hardcoding absolute path, just in case Apple changes
>> ?some path or file name in future OS version.
>>
>> ?I've tried
>>
>> ?find_package(LibXml2 2.8.0 REQUIRED PATHS "/usr" NO_DEFAULT_PATH)
>>
>> ?however it fails to find anything at all. Any ideas?
>
> Use
>
> ???find_package(LibXml2 2.8.0 REQUIRED)
>
> and then use CMAKE_PREFIX_PATH to define the search locations (in your
> environment or on the command-line; not in the script).

That would be great if CMake didn't add Fink and MacPorts paths to
CMAKE_SYSTEM_PREFIX_PATH out of the box unconditionally.

> If you
> hardcode paths in the script, you make it break on other systems.
> That might not be a consideration in this case, but the less
> assumptions you make, the more flexible it will be.

Of course, this hack would be guarded with if (APPLE), and other systems
would continue using normal find_package call.

>
> Regards,
> Roger

-- 
Regards,
Konstantin

From eric.noulard at gmail.com  Wed Oct 12 12:15:58 2016
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 12 Oct 2016 18:15:58 +0200
Subject: [CMake] Proper way to find system copy of libxml2 on macOS
In-Reply-To: <5615741476288297@web7g.yandex.ru>
References: <5469081476286089@web7g.yandex.ru>
 <CAPASGLra=N8G_7L2DKE+hQtaEfZ05A9WC2KDxyZ44wtWpbQzDg@mail.gmail.com>
 <5615741476288297@web7g.yandex.ru>
Message-ID: <CAPASGLpVdOakdi6MQgnXuJip7Yw0SL8zqA45Mh+J9x5dJjoijA@mail.gmail.com>

2016-10-12 18:04 GMT+02:00 Konstantin Tokarev <annulen at yandex.ru>:

>
>
> 12.10.2016, 18:48, "Eric Noulard" <eric.noulard at gmail.com>:
> > 2016-10-12 17:28 GMT+02:00 Konstantin Tokarev <annulen at yandex.ru>:
>
> >
> > My guess is that your find_package call end up in "Module mode"  because
> there is a FindLibXml2.cmake module bundled with cmake does not honor all
> options of the find_package when in this mode.
> >
> > So I bet FindLibXml2.cmake does not handle the given
> > "PATHS "/usr" NO_DEFAULT_PATH" part.
> >
> > Which are handled by find_package when running in "Config mode".
> >
> > I suggest you to try patch and update the FindLibXml2.cmake module.
>
> Could anyone point me to module example that handles NO_DEFAULT_PATH
> correctly?
>

Wait for other answers but from my understanding the "Module" mode does not
handle such find_package parameter.


>
> > Or simply craft your own
> >
> > find_library(...) call.if you only need the libxml2.
>
> That's not an elegant solution as I need to find include dir as well, and
> also do the same for libxslt which is in the same boat.
>

I see.
Then provided that module mode does not handle the "NO_DEFAULT_PATH" you
may need to do something similar to whats is done
by the FindZLIB.cmake module:

# A user may set ``ZLIB_ROOT`` to a zlib installation root to tell this
# module where to look.

set(_ZLIB_SEARCHES)

# Search ZLIB_ROOT first if it is set.
if(ZLIB_ROOT)
  set(_ZLIB_SEARCH_ROOT PATHS ${ZLIB_ROOT} NO_DEFAULT_PATH)
  list(APPEND _ZLIB_SEARCHES _ZLIB_SEARCH_ROOT)
endif()



-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161012/7f2e82cf/attachment.html>

From rleigh at codelibre.net  Wed Oct 12 12:04:07 2016
From: rleigh at codelibre.net (rleigh at codelibre.net)
Date: Wed, 12 Oct 2016 16:04:07 +0000
Subject: [CMake] Proper way to find system copy of libxml2 on macOS
In-Reply-To: <5469081476286089@web7g.yandex.ru>
References: <5469081476286089@web7g.yandex.ru>
Message-ID: <5db80a04f0dc689e5c434b4ef8a6ee02@codelibre.net>

On 2016-10-12 15:28, Konstantin Tokarev wrote:
> Hello,
> 
> In my cmake project I need to use system version of libxml2 on macOS
> (/usr/lib/libxml2.dylib), however in case it is installed in MacPorts
> the latter version is picked by find_package. On the other hand I'd
> like to avoid hardcoding absolute path, just in case Apple changes
> some path or file name in future OS version.
> 
> I've tried
> 
> find_package(LibXml2 2.8.0 REQUIRED PATHS "/usr" NO_DEFAULT_PATH)
> 
> however it fails to find anything at all. Any ideas?

Use

   find_package(LibXml2 2.8.0 REQUIRED)

and then use CMAKE_PREFIX_PATH to define the search locations (in your
environment or on the command-line; not in the script).  If you
hardcode paths in the script, you make it break on other systems.
That might not be a consideration in this case, but the less
assumptions you make, the more flexible it will be.


Regards,
Roger

From yugiohjcj-mailinglist at laposte.net  Thu Oct 13 07:32:45 2016
From: yugiohjcj-mailinglist at laposte.net (YuGiOhJCJ Mailing-List)
Date: Thu, 13 Oct 2016 13:32:45 +0200
Subject: [CMake] How to handle options with more than two possible values?
Message-ID: <20161013133245.7a174011c3e112ac814c3a78@laposte.net>

Hello,

Regarding the cmake-commands manual [1], the "option" command seems to take as argument a boolean constant that can have the two possible values: ON or OFF.

I would like to use three possible values for an option: AUTO (as default value), ON or OFF.

Example:
option(ENABLE_SOMETHING "Enable SOMETHING support" AUTO)

But of course this example is wrong because "AUTO" is not ON or OFF.

Regarding the cmake-commands manual [2], the "if" command seems to return TRUE when the boolean constant is 1, ON, YES, TRUE, Y, or a non-zero number.
It returns FALSE when the boolean constant is 0, OFF, NO, FALSE, N, IGNORE, NOTFOUND, the empty string, or ends in the suffix -NOTFOUND.

I would like to check the value myself.

Example:
if(ENABLE_SOMETHING=AUTO)
	message(STATUS "ENABLE_SOMETHING=AUTO")
endif()
if(ENABLE_SOMETHING=ON)
	message(STATUS "ENABLE_SOMETHING=ON")
endif()
if(ENABLE_SOMETHING=OFF)
	message(STATUS "ENABLE_SOMETHING=OFF")
endif()

But of course this example is wrong because "=" is not accepted for an expression in a "if" command.

So my question is: How to handle options with more than two possible values?

Thank you.
Best regards.

[1] https://cmake.org/cmake/help/v3.7/command/option.html
[2] https://cmake.org/cmake/help/v3.7/command/if.html

From petr.kmoch at gmail.com  Thu Oct 13 07:41:00 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 13 Oct 2016 13:41:00 +0200
Subject: [CMake] How to handle options with more than two possible
	values?
In-Reply-To: <20161013133245.7a174011c3e112ac814c3a78@laposte.net>
References: <20161013133245.7a174011c3e112ac814c3a78@laposte.net>
Message-ID: <CAKohaZdai-UASeNXaAMtt1WBkh_GHFy42u-0dtHZ2PCp=XfxdQ@mail.gmail.com>

Hi.

option() is a handy shortcut for boolean options, but it's little more than
syntactic sugar for a cache variable of type BOOL. To create a tristate
variable, you can do this:

  set(ENABLE_SOMETHING AUTO CACHE STRING "Enable SOMETHING support")  #
create the variable
  set_property(CACHE ENABLE_SOMETHING PROPERTY STRINGS AUTO ON OFF)  #
define list of values GUI will offer for the variable

Then, you can test the variable like this:

  if(ENABLE_SOMETHING STREQUAL "AUTO")
    # AUTO was used
  elseif(ENABLE_SOMETHING)
    # a true value (such as ON) was used
  else()
    # a false value (such as OFF) was used
  endif()

Hope this helps.

Petr

On 13 October 2016 at 13:32, YuGiOhJCJ Mailing-List via CMake <
cmake at cmake.org> wrote:

> Hello,
>
> Regarding the cmake-commands manual [1], the "option" command seems to
> take as argument a boolean constant that can have the two possible values:
> ON or OFF.
>
> I would like to use three possible values for an option: AUTO (as default
> value), ON or OFF.
>
> Example:
> option(ENABLE_SOMETHING "Enable SOMETHING support" AUTO)
>
> But of course this example is wrong because "AUTO" is not ON or OFF.
>
> Regarding the cmake-commands manual [2], the "if" command seems to return
> TRUE when the boolean constant is 1, ON, YES, TRUE, Y, or a non-zero number.
> It returns FALSE when the boolean constant is 0, OFF, NO, FALSE, N,
> IGNORE, NOTFOUND, the empty string, or ends in the suffix -NOTFOUND.
>
> I would like to check the value myself.
>
> Example:
> if(ENABLE_SOMETHING=AUTO)
>         message(STATUS "ENABLE_SOMETHING=AUTO")
> endif()
> if(ENABLE_SOMETHING=ON)
>         message(STATUS "ENABLE_SOMETHING=ON")
> endif()
> if(ENABLE_SOMETHING=OFF)
>         message(STATUS "ENABLE_SOMETHING=OFF")
> endif()
>
> But of course this example is wrong because "=" is not accepted for an
> expression in a "if" command.
>
> So my question is: How to handle options with more than two possible
> values?
>
> Thank you.
> Best regards.
>
> [1] https://cmake.org/cmake/help/v3.7/command/option.html
> [2] https://cmake.org/cmake/help/v3.7/command/if.html
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161013/55637305/attachment-0001.html>

From dflogeras2 at gmail.com  Thu Oct 13 11:05:19 2016
From: dflogeras2 at gmail.com (Dave Flogeras)
Date: Thu, 13 Oct 2016 12:05:19 -0300
Subject: [CMake] PROPERTIES VERSION bug in windows DLL major.minor version
Message-ID: <CANB0TnSRO=R36ZiadcS+Q7F77khGCdLzFJbzqf3Dg1g3ChJizA@mail.gmail.com>

Hi, I noticed that on an older (3.2.2) release I was using with Win7, the
behaviour described about automatically parsing VERSION major.minor and
putting it into the DLL image version wasn't behaving correctly.  It seemed
it was applying the VERSION from the first shared library in my project, to
all shared libraries.

Before mailing, I tried the latest (3.6.2 I think) and it works correctly.

Does anyone know when this was fixed so that I can update my minimum
required version as needed?  Is there a master Changelog somewhere?  I can
resort to pulling each version's changelog, but I'd rather not :)

d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161013/9c0d2cc5/attachment.html>

From boxerab at gmail.com  Thu Oct 13 15:18:30 2016
From: boxerab at gmail.com (Aaron Boxer)
Date: Thu, 13 Oct 2016 15:18:30 -0400
Subject: [CMake] Need help generating a config file
Message-ID: <CAK8GPyD64VaHMiViCLN5c=TB+V37XrERQThq0n=DM8m7dG5NCw@mail.gmail.com>

Hello,

I have a     foo.h.cmake.in     file that I am using to generate a
foo_config.h    file.

Here is the line in my cmake file that generates the header:

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/foo.h.cmake.in
  ${CMAKE_CURRENT_BINARY_DIR}/foo_config.h @ONLY)


I would like to define or undefine DEFINE in the config file
based on some cmake variables.


Here is my line in the foo.h.cmake.in file:

#cmakedefine FOO_DEFINE ${SOME_CMAKE_VARIABLE}


However, I only get

#define FOO_DEFINE ${SOME_CMAKE_VARIABLE}

in the foo_config.h file.


Thanks,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161013/79d96d11/attachment.html>

From eric.noulard at gmail.com  Thu Oct 13 15:27:33 2016
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 13 Oct 2016 21:27:33 +0200
Subject: [CMake] Need help generating a config file
In-Reply-To: <CAK8GPyD64VaHMiViCLN5c=TB+V37XrERQThq0n=DM8m7dG5NCw@mail.gmail.com>
References: <CAK8GPyD64VaHMiViCLN5c=TB+V37XrERQThq0n=DM8m7dG5NCw@mail.gmail.com>
Message-ID: <CAPASGLoNrYXuKC2J6=e6UdE0QQRyBBYG0zz+wW1Xd25LO78fuQ@mail.gmail.com>

2016-10-13 21:18 GMT+02:00 Aaron Boxer <boxerab at gmail.com>:

> Hello,
>
> I have a     foo.h.cmake.in     file that I am using to generate a
> foo_config.h    file.
>
> Here is the line in my cmake file that generates the header:
>
> configure_file(${CMAKE_CURRENT_SOURCE_DIR}/foo.h.cmake.in
>   ${CMAKE_CURRENT_BINARY_DIR}/foo_config.h @ONLY)
>


You specified @ONLY option which means that only @VARNAME@ will be processed
and not ${VARNAME}


>
>
> I would like to define or undefine DEFINE in the config file
> based on some cmake variables.
>
>
> Here is my line in the foo.h.cmake.in file:
>
> #cmakedefine FOO_DEFINE ${SOME_CMAKE_VARIABLE}
>

Either you drop the @ONLY option of configure_file or you write

#cmakedefine FOO_DEFINE @SOME_CMAKE_VARIABLE@

and you should get what you want.
@ONLY is very useful when you configure some kind of shell script template
where $ shoudn't be interpreted by CMake condigure_file because it's meant
to kept
as is in the resulting configured file.



>
> However, I only get
>
> #define FOO_DEFINE ${SOME_CMAKE_VARIABLE}
>
> in the foo_config.h file.
>
>
> Thanks,
> Aaron
>
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161013/37ed096c/attachment.html>

From boxerab at gmail.com  Thu Oct 13 15:43:24 2016
From: boxerab at gmail.com (Aaron Boxer)
Date: Thu, 13 Oct 2016 15:43:24 -0400
Subject: [CMake] Need help generating a config file
In-Reply-To: <CAPASGLoNrYXuKC2J6=e6UdE0QQRyBBYG0zz+wW1Xd25LO78fuQ@mail.gmail.com>
References: <CAK8GPyD64VaHMiViCLN5c=TB+V37XrERQThq0n=DM8m7dG5NCw@mail.gmail.com>
 <CAPASGLoNrYXuKC2J6=e6UdE0QQRyBBYG0zz+wW1Xd25LO78fuQ@mail.gmail.com>
Message-ID: <CAK8GPyBKOOxUyAywvUX2dKoCYmuqu=yJEs6BUKBGSg=WRB1-5g@mail.gmail.com>

Thanks a lot, Eric.

So, I have two cmake variables, and I want to #define FOO_DEFINE if
one or the other is set, otherwise I don't want FOO_DEFINE defines at all.

Is this possible ?



On Thu, Oct 13, 2016 at 3:27 PM, Eric Noulard <eric.noulard at gmail.com>
wrote:

>
>
> 2016-10-13 21:18 GMT+02:00 Aaron Boxer <boxerab at gmail.com>:
>
>> Hello,
>>
>> I have a     foo.h.cmake.in     file that I am using to generate a
>> foo_config.h    file.
>>
>> Here is the line in my cmake file that generates the header:
>>
>> configure_file(${CMAKE_CURRENT_SOURCE_DIR}/foo.h.cmake.in
>>   ${CMAKE_CURRENT_BINARY_DIR}/foo_config.h @ONLY)
>>
>
>
> You specified @ONLY option which means that only @VARNAME@ will be
> processed
> and not ${VARNAME}
>
>
>>
>>
>> I would like to define or undefine DEFINE in the config file
>> based on some cmake variables.
>>
>>
>> Here is my line in the foo.h.cmake.in file:
>>
>> #cmakedefine FOO_DEFINE ${SOME_CMAKE_VARIABLE}
>>
>
> Either you drop the @ONLY option of configure_file or you write
>
> #cmakedefine FOO_DEFINE @SOME_CMAKE_VARIABLE@
>
> and you should get what you want.
> @ONLY is very useful when you configure some kind of shell script template
> where $ shoudn't be interpreted by CMake condigure_file because it's meant
> to kept
> as is in the resulting configured file.
>
>
>
>>
>> However, I only get
>>
>> #define FOO_DEFINE ${SOME_CMAKE_VARIABLE}
>>
>> in the foo_config.h file.
>>
>>
>> Thanks,
>> Aaron
>>
>>
>>
>>
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
>
> --
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161013/f4d43c10/attachment.html>

From boxerab at gmail.com  Thu Oct 13 16:09:01 2016
From: boxerab at gmail.com (Aaron Boxer)
Date: Thu, 13 Oct 2016 16:09:01 -0400
Subject: [CMake] Need help generating a config file
In-Reply-To: <CAPASGLoNrYXuKC2J6=e6UdE0QQRyBBYG0zz+wW1Xd25LO78fuQ@mail.gmail.com>
References: <CAK8GPyD64VaHMiViCLN5c=TB+V37XrERQThq0n=DM8m7dG5NCw@mail.gmail.com>
 <CAPASGLoNrYXuKC2J6=e6UdE0QQRyBBYG0zz+wW1Xd25LO78fuQ@mail.gmail.com>
Message-ID: <CAK8GPyCxqmWZKev9cbQ2jpV+s3NxpzR35Ss2RLjxZE6WG1V71Q@mail.gmail.com>

Eric, thanks, I figured it out.

On Thu, Oct 13, 2016 at 3:27 PM, Eric Noulard <eric.noulard at gmail.com>
wrote:

>
>
> 2016-10-13 21:18 GMT+02:00 Aaron Boxer <boxerab at gmail.com>:
>
>> Hello,
>>
>> I have a     foo.h.cmake.in     file that I am using to generate a
>> foo_config.h    file.
>>
>> Here is the line in my cmake file that generates the header:
>>
>> configure_file(${CMAKE_CURRENT_SOURCE_DIR}/foo.h.cmake.in
>>   ${CMAKE_CURRENT_BINARY_DIR}/foo_config.h @ONLY)
>>
>
>
> You specified @ONLY option which means that only @VARNAME@ will be
> processed
> and not ${VARNAME}
>
>
>>
>>
>> I would like to define or undefine DEFINE in the config file
>> based on some cmake variables.
>>
>>
>> Here is my line in the foo.h.cmake.in file:
>>
>> #cmakedefine FOO_DEFINE ${SOME_CMAKE_VARIABLE}
>>
>
> Either you drop the @ONLY option of configure_file or you write
>
> #cmakedefine FOO_DEFINE @SOME_CMAKE_VARIABLE@
>
> and you should get what you want.
> @ONLY is very useful when you configure some kind of shell script template
> where $ shoudn't be interpreted by CMake condigure_file because it's meant
> to kept
> as is in the resulting configured file.
>
>
>
>>
>> However, I only get
>>
>> #define FOO_DEFINE ${SOME_CMAKE_VARIABLE}
>>
>> in the foo_config.h file.
>>
>>
>> Thanks,
>> Aaron
>>
>>
>>
>>
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
>
> --
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161013/8788567d/attachment-0001.html>

From yugiohjcj-mailinglist at laposte.net  Fri Oct 14 04:19:03 2016
From: yugiohjcj-mailinglist at laposte.net (YuGiOhJCJ Mailing-List)
Date: Fri, 14 Oct 2016 10:19:03 +0200
Subject: [CMake] How to handle options with more than two possible
 values?
In-Reply-To: <CAKohaZdai-UASeNXaAMtt1WBkh_GHFy42u-0dtHZ2PCp=XfxdQ@mail.gmail.com>
References: <20161013133245.7a174011c3e112ac814c3a78@laposte.net>
 <CAKohaZdai-UASeNXaAMtt1WBkh_GHFy42u-0dtHZ2PCp=XfxdQ@mail.gmail.com>
Message-ID: <20161014101903.c763ea313c2d9a7260ac81d8@laposte.net>

Thanks it works perfectly!

On Thu, 13 Oct 2016 13:41:00 +0200
Petr Kmoch <petr.kmoch at gmail.com> wrote:

> Hi.
> 
> option() is a handy shortcut for boolean options, but it's little more than
> syntactic sugar for a cache variable of type BOOL. To create a tristate
> variable, you can do this:
> 
>   set(ENABLE_SOMETHING AUTO CACHE STRING "Enable SOMETHING support")  #
> create the variable
>   set_property(CACHE ENABLE_SOMETHING PROPERTY STRINGS AUTO ON OFF)  #
> define list of values GUI will offer for the variable
> 
> Then, you can test the variable like this:
> 
>   if(ENABLE_SOMETHING STREQUAL "AUTO")
>     # AUTO was used
>   elseif(ENABLE_SOMETHING)
>     # a true value (such as ON) was used
>   else()
>     # a false value (such as OFF) was used
>   endif()
> 
> Hope this helps.
> 
> Petr
> 
> On 13 October 2016 at 13:32, YuGiOhJCJ Mailing-List via CMake <
> cmake at cmake.org> wrote:
> 
> > Hello,
> >
> > Regarding the cmake-commands manual [1], the "option" command seems to
> > take as argument a boolean constant that can have the two possible values:
> > ON or OFF.
> >
> > I would like to use three possible values for an option: AUTO (as default
> > value), ON or OFF.
> >
> > Example:
> > option(ENABLE_SOMETHING "Enable SOMETHING support" AUTO)
> >
> > But of course this example is wrong because "AUTO" is not ON or OFF.
> >
> > Regarding the cmake-commands manual [2], the "if" command seems to return
> > TRUE when the boolean constant is 1, ON, YES, TRUE, Y, or a non-zero number.
> > It returns FALSE when the boolean constant is 0, OFF, NO, FALSE, N,
> > IGNORE, NOTFOUND, the empty string, or ends in the suffix -NOTFOUND.
> >
> > I would like to check the value myself.
> >
> > Example:
> > if(ENABLE_SOMETHING=AUTO)
> >         message(STATUS "ENABLE_SOMETHING=AUTO")
> > endif()
> > if(ENABLE_SOMETHING=ON)
> >         message(STATUS "ENABLE_SOMETHING=ON")
> > endif()
> > if(ENABLE_SOMETHING=OFF)
> >         message(STATUS "ENABLE_SOMETHING=OFF")
> > endif()
> >
> > But of course this example is wrong because "=" is not accepted for an
> > expression in a "if" command.
> >
> > So my question is: How to handle options with more than two possible
> > values?
> >
> > Thank you.
> > Best regards.
> >
> > [1] https://cmake.org/cmake/help/v3.7/command/option.html
> > [2] https://cmake.org/cmake/help/v3.7/command/if.html
> > --
> >
> > 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
> >

From paulo.waelkens at gmail.com  Fri Oct 14 05:08:16 2016
From: paulo.waelkens at gmail.com (Paulo Waelkens)
Date: Fri, 14 Oct 2016 11:08:16 +0200
Subject: [CMake] make_directory deprecated. What's the correct solution
 to generate directories at build time now?
In-Reply-To: <CAGyo1owDYymA1EP6eBxkmCfDVcFuyLHBj-pPKy5GZduPWxUgMw@mail.gmail.com>
References: <CAO3jT8JDNzyj8S+37gxLWX3fcwe5VJq0+7W-oY70+ZiS+XF0DA@mail.gmail.com>
 <CAGyo1owDYymA1EP6eBxkmCfDVcFuyLHBj-pPKy5GZduPWxUgMw@mail.gmail.com>
Message-ID: <CAO3jT8K6QepfWGuZ7TyXz4aABzQSrWi4-0et3KXJFxW9ccVvSw@mail.gmail.com>

You are right!

The documentation quick search for the "make_directory" keyword does not
find the cmake executable documentation (i.e. the make_directory
command-line tool), only the script command. That tripped me up.
If you manually go to the cmake executable documentation (
https://cmake.org/cmake/help/v3.6/manual/cmake.1.html), you'll find that
"cmake.exe -E make_directory..." is indeed still up to date

Thanks Iosif! Cheers,
Paulo

On 12 October 2016 at 00:57, iosif neitzke <iosif.neitzke+cmake at gmail.com>
wrote:

> I think only the cmake script command make_directory is deprecated, not
> the cmake command-line tool -E mode make_directory?
>
> On Tue, Oct 11, 2016 at 5:21 PM, Paulo Waelkens
> <paulo.waelkens at gmail.com> wrote:
> > Hello,
> >
> > to create a cmake directory at build time
> > (http://stackoverflow.com/questions/3702115/creating-a-
> directory-in-cmake)
> > you could use
> >
> > add_custom_target(build-time-make-directory ALL
> >     COMMAND ${CMAKE_COMMAND} -E make_directory ${directory})
> >
> > "make_directory" is now listed as deprecated in the new cmake
> documentation
> > (https://cmake.org/cmake/help/v3.6/command/make_directory.html).
> >
> > How exactly could I repeat the original behaviour without using
> deprecated
> > functionality?
> > I understand that I'm supposed to use file(MAKE_DIRECTORY ${directory})
> > somehow, but don't understand how exactly to connect this with COMMAND.
> >
> > I've tried to use
> > COMMAND ${CMAKE_COMMAND} -E file ...       (definitely wrong, because
> > cmake.exe -E <command> [args...] does not list "file" as an available
> > command)
> > COMMAND file(MAKE_DIRECTORY ${directory})   (wrong, again, 'file' is not
> > recognized as an internal or external command)
> >
> > Does anyone know how to do this right? I'll keep using the deprecated
> stuff
> > for now, but that's kind of sad.
> >
> > Thanks for the help! Cheers,
> > Paulo
> >
> >
> > --
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161014/de7b3d6b/attachment.html>

From randallsturner13 at gmail.com  Fri Oct 14 10:04:42 2016
From: randallsturner13 at gmail.com (Randy Turner)
Date: Fri, 14 Oct 2016 10:04:42 -0400
Subject: [CMake] Single Letter Omissions From File Path In Linker
Message-ID: <CAB8TE6HHpyZcEF2kCtYstRaOETpYV-Y43G96eK+nYPOq4NgyKQ@mail.gmail.com>

Hello! I've been running into a frustrating issue on and off for the past
year. The project will build the source files correctly but when it comes
to linking the executables, I always get the same error. The specific file
varies, but the failure mode is always the same. For example:

<Linking>
"C:\\Users\\User\\AppData\\Local\\Temp\\<six digit temp file>", line xxx:
error #10008-D: cannot find file
"C:/Repos/operatingsystem/CMakeFiles/nvm_validate_ierator.dir/os/nvm/nvm_
validate_iterator.c.obj"

As you can see, the file path is missing a "t" in the first occurrence of
the word "iterator" and so that file definitely does not exist. A file
exists in the location with correct spelling, but somehow that hardcoded
path in that temporary file has dropped a letter. The specific letter that
gets dropped varies along with which file is allegedly missing. We noticed
that requiring people to store the repository in their root directory
greatly cut down on the occurrence of this issue but it is returning with
more frequency as of late. Once it occurs once, CMake builds are never
successful again and the only way that I have been able to completely clear
the problem has been to reinstall Windows and set up the build environment
again.

Has anyone else seen this issue? Is there a way to change the directory for
those linker files so that they're not in the Temp folder?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161014/e8a74fac/attachment.html>

From andrew.bell.ia at gmail.com  Fri Oct 14 10:16:13 2016
From: andrew.bell.ia at gmail.com (Andrew Bell)
Date: Fri, 14 Oct 2016 09:16:13 -0500
Subject: [CMake] Single Letter Omissions From File Path In Linker
In-Reply-To: <CAB8TE6HHpyZcEF2kCtYstRaOETpYV-Y43G96eK+nYPOq4NgyKQ@mail.gmail.com>
References: <CAB8TE6HHpyZcEF2kCtYstRaOETpYV-Y43G96eK+nYPOq4NgyKQ@mail.gmail.com>
Message-ID: <CACJ51z2XanJbr9geG6qTSa9sXsYpqxx7x0myazMeVBb9JR+jWQ@mail.gmail.com>

On Fri, Oct 14, 2016 at 9:04 AM, Randy Turner <randallsturner13 at gmail.com>
wrote:

> Hello! I've been running into a frustrating issue on and off for the past
> year. The project will build the source files correctly but when it comes
> to linking the executables, I always get the same error. The specific file
> varies, but the failure mode is always the same. For example:
>
> <Linking>
> "C:\\Users\\User\\AppData\\Local\\Temp\\<six digit temp file>", line xxx:
> error #10008-D: cannot find file
> "C:/Repos/operatingsystem/CMakeFiles/nvm_validate_ierator.
> dir/os/nvm/nvm_validate_iterator.c.obj"
>
> As you can see, the file path is missing a "t" in the first occurrence of
> the word "iterator" and so that file definitely does not exist. A file
> exists in the location with correct spelling, but somehow that hardcoded
> path in that temporary file has dropped a letter. The specific letter that
> gets dropped varies along with which file is allegedly missing. We noticed
> that requiring people to store the repository in their root directory
> greatly cut down on the occurrence of this issue but it is returning with
> more frequency as of late. Once it occurs once, CMake builds are never
> successful again and the only way that I have been able to completely clear
> the problem has been to reinstall Windows and set up the build environment
> again.
>

This seems really, really strange.  Have to reinstall Windows?  What about
just using another build directory?  It sure *seems* like there's some
problem in your CMakeFiles.txt where the way the filepath is being
constructed is incorrect.  But I don't think you've really provided enough
information to determine the problem.  Where does the name of the object
file come from?

-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161014/ab014dff/attachment-0001.html>

From bill.hoffman at kitware.com  Fri Oct 14 13:05:15 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Fri, 14 Oct 2016 13:05:15 -0400
Subject: [CMake] Single Letter Omissions From File Path In Linker
In-Reply-To: <CAB8TE6HHpyZcEF2kCtYstRaOETpYV-Y43G96eK+nYPOq4NgyKQ@mail.gmail.com>
References: <CAB8TE6HHpyZcEF2kCtYstRaOETpYV-Y43G96eK+nYPOq4NgyKQ@mail.gmail.com>
Message-ID: <9e174bb1-723d-3df1-767a-29a64f9df8d8@kitware.com>

On 10/14/2016 10:04 AM, Randy Turner wrote:
> Hello! I've been running into a frustrating issue on and off for the
> past year. The project will build the source files correctly but when it
> comes to linking the executables, I always get the same error. The
> specific file varies, but the failure mode is always the same. For example:
>
> <Linking>
> "C:\\Users\\User\\AppData\\Local\\Temp\\<six digit temp file>", line
> xxx: error #10008-D: cannot find file
> "C:/Repos/operatingsystem/CMakeFiles/nvm_validate_ierator.dir/os/nvm/nvm_validate_iterator.c.obj"
>
> As you can see, the file path is missing a "t" in the first occurrence
> of the word "iterator" and so that file definitely does not exist. A
> file exists in the location with correct spelling, but somehow that
> hardcoded path in that temporary file has dropped a letter. The specific
> letter that gets dropped varies along with which file is allegedly
> missing. We noticed that requiring people to store the repository in
> their root directory greatly cut down on the occurrence of this issue
> but it is returning with more frequency as of late. Once it occurs once,
> CMake builds are never successful again and the only way that I have
> been able to completely clear the problem has been to reinstall Windows
> and set up the build environment again.
>
> Has anyone else seen this issue? Is there a way to change the directory
> for those linker files so that they're not in the Temp folder?
What generator are you using?  What version of CMake?

-Bill


From boxerab at gmail.com  Fri Oct 14 13:34:57 2016
From: boxerab at gmail.com (Aaron Boxer)
Date: Fri, 14 Oct 2016 13:34:57 -0400
Subject: [CMake] Force copy of files
Message-ID: <CAK8GPyCw2R232XGAWWERxsibpbSjJkC-xY8QJb7tFSdNdHBaug@mail.gmail.com>

I have the following lines in my cmake file


foreach(f ${MyFiles})
  add_custom_command(TARGET ${OPENJPEG_PLUGIN_NAME} PRE_BUILD
                     COMMAND ${CMAKE_COMMAND} -E
                         copy ${f} $<TARGET_FILE_DIR:${MY_FOLDER}>)
endforeach()

in order to copy MyFiles to MyFolder.


If these files already exist, I would like copy to overwrite the old file.
Is there a flag to pass to copy to force this to overwrite?

Thanks!
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161014/e99fa8ee/attachment.html>

From boxerab at gmail.com  Fri Oct 14 13:47:51 2016
From: boxerab at gmail.com (Aaron Boxer)
Date: Fri, 14 Oct 2016 13:47:51 -0400
Subject: [CMake] Force copy of files
In-Reply-To: <CAK8GPyCw2R232XGAWWERxsibpbSjJkC-xY8QJb7tFSdNdHBaug@mail.gmail.com>
References: <CAK8GPyCw2R232XGAWWERxsibpbSjJkC-xY8QJb7tFSdNdHBaug@mail.gmail.com>
Message-ID: <CAK8GPyAp+_me_Z5ZYftqw2nPQrMu2PQDTiPz27xHatRakw7jCw@mail.gmail.com>

Never mind, figured this one out:

use copy_if_different

On Fri, Oct 14, 2016 at 1:34 PM, Aaron Boxer <boxerab at gmail.com> wrote:

> I have the following lines in my cmake file
>
>
> foreach(f ${MyFiles})
>   add_custom_command(TARGET ${OPENJPEG_PLUGIN_NAME} PRE_BUILD
>                      COMMAND ${CMAKE_COMMAND} -E
>                          copy ${f} $<TARGET_FILE_DIR:${MY_FOLDER}>)
> endforeach()
>
> in order to copy MyFiles to MyFolder.
>
>
> If these files already exist, I would like copy to overwrite the old file.
> Is there a flag to pass to copy to force this to overwrite?
>
> Thanks!
> Aaron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161014/9a94e9de/attachment.html>

From DLRdave at aol.com  Fri Oct 14 14:00:33 2016
From: DLRdave at aol.com (David Cole)
Date: Fri, 14 Oct 2016 14:00:33 -0400
Subject: [CMake] Force copy of files
In-Reply-To: <CAK8GPyAp+_me_Z5ZYftqw2nPQrMu2PQDTiPz27xHatRakw7jCw@mail.gmail.com>
References: <CAK8GPyCw2R232XGAWWERxsibpbSjJkC-xY8QJb7tFSdNdHBaug@mail.gmail.com>
 <CAK8GPyAp+_me_Z5ZYftqw2nPQrMu2PQDTiPz27xHatRakw7jCw@mail.gmail.com>
Message-ID: <CAKME8fGAAcvqtUp074gZ_PBuN7GMhS4NwebP7QyrJxRobfX=Lg@mail.gmail.com>

"copy" should always overwrite.

"copy_if_different" will conditionally overwrite, only if the contents
of the two files are different.

If "copy" was not overwriting something when it should have been,
please send steps to reproduce the issue, because that would be a bug.


HTH,
David C.



On Fri, Oct 14, 2016 at 1:47 PM, Aaron Boxer <boxerab at gmail.com> wrote:
> Never mind, figured this one out:
>
> use copy_if_different
>
> On Fri, Oct 14, 2016 at 1:34 PM, Aaron Boxer <boxerab at gmail.com> wrote:
>>
>> I have the following lines in my cmake file
>>
>>
>> foreach(f ${MyFiles})
>>   add_custom_command(TARGET ${OPENJPEG_PLUGIN_NAME} PRE_BUILD
>>                      COMMAND ${CMAKE_COMMAND} -E
>>                          copy ${f} $<TARGET_FILE_DIR:${MY_FOLDER}>)
>> endforeach()
>>
>> in order to copy MyFiles to MyFolder.
>>
>>
>> If these files already exist, I would like copy to overwrite the old file.
>> Is there a flag to pass to copy to force this to overwrite?
>>
>> Thanks!
>> Aaron
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

From zlynx at acm.org  Fri Oct 14 16:34:19 2016
From: zlynx at acm.org (Zan Lynx)
Date: Fri, 14 Oct 2016 14:34:19 -0600
Subject: [CMake] Single Letter Omissions From File Path In Linker
In-Reply-To: <CAB8TE6HHpyZcEF2kCtYstRaOETpYV-Y43G96eK+nYPOq4NgyKQ@mail.gmail.com>
References: <CAB8TE6HHpyZcEF2kCtYstRaOETpYV-Y43G96eK+nYPOq4NgyKQ@mail.gmail.com>
Message-ID: <b306f4fe-4262-23de-0bb1-e9a3a1f46681@acm.org>

On 10/14/2016 08:04 AM, Randy Turner wrote:
> As you can see, the file path is missing a "t" in the first occurrence
> of the word "iterator" and so that file definitely does not exist. A
> file exists in the location with correct spelling, but somehow that
> hardcoded path in that temporary file has dropped a letter. The specific
> letter that gets dropped varies along with which file is allegedly missing.

If this was all happening on the same computer I would suspect a
hardware error in the RAM and I'd recommend running a night-long memory
test.

If this is happening on several different machines, then I don't know.
It could be something that is manipulating the path name with a regular
expression, or otherwise editing it.

If the missing letters were immediately after a back-slash (\) then I'd
suspect improper escape handling. But that doesn't seem to be it either.

From eric.noulard at gmail.com  Sat Oct 15 09:13:40 2016
From: eric.noulard at gmail.com (Eric Noulard)
Date: Sat, 15 Oct 2016 15:13:40 +0200
Subject: [CMake] Force copy of files
In-Reply-To: <CAK8GPyCw2R232XGAWWERxsibpbSjJkC-xY8QJb7tFSdNdHBaug@mail.gmail.com>
References: <CAK8GPyCw2R232XGAWWERxsibpbSjJkC-xY8QJb7tFSdNdHBaug@mail.gmail.com>
Message-ID: <CAPASGLp0Ctzwub12aSRVkVfzr=k32ro8ZxctVeDjURCvcfC0rA@mail.gmail.com>

2016-10-14 19:34 GMT+02:00 Aaron Boxer <boxerab at gmail.com>:

> I have the following lines in my cmake file
>
>
> foreach(f ${MyFiles})
>   add_custom_command(TARGET ${OPENJPEG_PLUGIN_NAME} PRE_BUILD
>                      COMMAND ${CMAKE_COMMAND} -E
>                          copy ${f} $<TARGET_FILE_DIR:${MY_FOLDER}>)
> endforeach()
>
> in order to copy MyFiles to MyFolder.
>
>
> If these files already exist, I would like copy to overwrite the old file.
> Is there a flag to pass to copy to force this to overwrite?
>

I don't think so since the "-E copy" already has the behaviour you describe.
i.e. it will overwrite the file in any case.

Th only variant you have is the copy_if_different which may avoid changing
the timestamp of a file which didn't change.

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161015/0d89d769/attachment.html>

From intelfx at intelfx.name  Sun Oct 16 08:37:56 2016
From: intelfx at intelfx.name (Ivan Shapovalov)
Date: Sun, 16 Oct 2016 15:37:56 +0300
Subject: [CMake] Editing IMPORTED targets
In-Reply-To: <nstjov$vnt$1@blaine.gmane.org>
References: <1474862988.10826.5.camel@intelfx.name>
 <nstjov$vnt$1@blaine.gmane.org>
Message-ID: <1476621476.14012.1.camel@intelfx.name>

On 2016-10-03 at 14:43 +0200, Stephen Kelly wrote:
> Ivan Shapovalov wrote:
> 
> > Hello!
> > 
> > Using find modules to detect dependencies has a nice feature: it is
> > then possible to edit the resulting cache entries to link to
> > different
> > libraries (or add other libraries along the found ones, for
> > whatever
> > purposes), or change directories, or flags, or whatever.
> > 
> > Using find configs and IMPORTED targets, however, prevents doing
> > this,
> > because IMPORTED targets are not stored in CMake cache. This can be
> > a
> > significant disadvantage at times.
> 
> Can you be more specific?
> 
> Why can the user provide better information than the supplier of the?
> IMPORTED target?
> 
> Thanks,
> 
> Steve.
> 
> 

Well, sometimes you need to do certain "maintainer-specific" overrides:
include custom headers before everything, link to custom libraries
before everything and so on. Think LD_PRELOAD, but at link time.

-- 
Ivan Shapovalov / intelfx /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161016/bce17d99/attachment.sig>

From steveire at gmail.com  Sun Oct 16 09:43:50 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 16 Oct 2016 15:43:50 +0200
Subject: [CMake] Editing IMPORTED targets
References: <1474862988.10826.5.camel@intelfx.name>
 <nstjov$vnt$1@blaine.gmane.org> <1476621476.14012.1.camel@intelfx.name>
Message-ID: <nu006k$jjh$1@blaine.gmane.org>

Ivan Shapovalov wrote:

> On 2016-10-03 at 14:43 +0200, Stephen Kelly wrote:
>> Ivan Shapovalov wrote:
>> 
>> > Hello!
>> > 
>> > Using find modules to detect dependencies has a nice feature: it is
>> > then possible to edit the resulting cache entries to link to
>> > different
>> > libraries (or add other libraries along the found ones, for
>> > whatever
>> > purposes), or change directories, or flags, or whatever.
>> > 
>> > Using find configs and IMPORTED targets, however, prevents doing
>> > this,
>> > because IMPORTED targets are not stored in CMake cache. This can be
>> > a
>> > significant disadvantage at times.
>> 
>> Can you be more specific?
>> 
>> Why can the user provide better information than the supplier of the
>> IMPORTED target?
>> 
>> Thanks,
>> 
>> Steve.
>> 
>> 
> 
> Well, sometimes you need to do certain "maintainer-specific" overrides:
> include custom headers before everything, link to custom libraries
> before everything and so on. Think LD_PRELOAD, but at link time.

What is a 'maintainer' in that sentence? A 'maintainer' can change the 
buildsystem CMake files. I suspect that's not an actor you mean. If you can 
be more specific maybe I will understand.

Would 'wrapping' be a good solution?

 add_library(foo_wrapper INTERFACE)
 target_include_directories(foo_wrapper INTERFACE
   ${custom_includes}
   $<TARGET_PROPERTY:Foo::foo,INTERFACE_INCLUDE_DIRECTORIES>
 )
 target_link_libraries(foo_wrapper INTERFACE
   ${custom_libraries}
   Foo::foo
 )


Thanks,

Steve.



From irwin at beluga.phys.uvic.ca  Sun Oct 16 16:43:55 2016
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sun, 16 Oct 2016 13:43:55 -0700 (PDT)
Subject: [CMake] Cannot get automoc to work properly with recommended Qt5
 support method
Message-ID: <alpine.DEB.2.11.1610161252300.1243@enira.zlyna.ubzr>

Hi Stephen:

I am addressing you directly (as well as the list) because you have
been so helpful with Qt5 issues in the past.

The PLplot build system (some of whose components depend on Qt5)
currently uses one of the older Qt5 support methods documented at
<http://doc.qt.io/qt-5/cmake-manual.html>.  But that method is complex
and we are currently running into troubles with it where it uses the
plain target_link_libraries command which conflicts with the keyworded
version that we prefer for our build system.  So I have attempted to
update our Qt5 support to the latest target_link_libraries method
documented at the above URL, but automoc appears not to be working
correctly.

I follow the advice in the above URL and set

set(CMAKE_AUTOMOC ON)

and also set AUTOMOC_MOC_OPTIONS to the following list:

-DPLD_bmpqt;-DPLD_jpgqt;-DPLD_pngqt;-DPLD_ppmqt;-DPLD_tiffqt;-DPLD_svgqt;-DPLD_pdfqt;-DPLD_qtwidget;-DPLD_extqt;-DPLD_memqt

This list is the same as I use for MOC_OPTIONS in the old working method, and
these various macro definitions _must_ be defined to avoid dropping large
swaths of our code from the compilation.  Instead of using

set(CMAKE_INCLUDE_CURRENT_DIR ON)

I use instead (in the directory where the plplotqt library is built)

include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ...)

Furthermore, in that same directory I use

target_link_libraries(plplotqt PRIVATE plplot ${MATH_LIB} Qt5::Svg Qt5::Gui Qt5::PrintSupport)

for the build.  Although that build apparently works with no obvious
issues, there is no sign of any of the above macros in the
VERBOSE=1 output.  Furthermore, I get the following near-empty result
for the generated bindings/qt_gui/plplotqt_automoc.cpp file which
consists just of the following two lines:

/* This file is autogenerated, do not edit*/
enum some_compilers { need_more_than_nothing };

Finally,

"ldd -r bindings/qt_gui/libplplotqt.st"

shows missing symbols that should be defined if the above macros are
defined.

What am I missing?

To move to a related topic, the above URL has a tutorial example for
the recommended support method which builds the helloworld target from
main.cpp.  It would be nice for Qt5 users to learn from that tutorial
example by building it themselves, but that example is incomplete
since no main.cpp (presumably Qt5-related) is provided (as far as I
can discover).  Any chance you could provide that simple example for
developers like me who don't have a lot of Qt5 or C++ expertise but
who just want to build other's Qt5-related work using the best
CMake-related methods?

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
__________________________

From irwin at beluga.phys.uvic.ca  Sun Oct 16 17:22:58 2016
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sun, 16 Oct 2016 14:22:58 -0700 (PDT)
Subject: [CMake] Cannot get automoc to work properly with recommended
 Qt5 support method
In-Reply-To: <alpine.DEB.2.11.1610161252300.1243@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1610161252300.1243@enira.zlyna.ubzr>
Message-ID: <alpine.DEB.2.11.1610161414290.1243@enira.zlyna.ubzr>

On 2016-10-16 13:43-0700 Alan W. Irwin wrote:

> To move to a related topic, the above URL has a tutorial example for
> the recommended support method which builds the helloworld target from
> main.cpp.  It would be nice for Qt5 users to learn from that tutorial
> example by building it themselves, but that example is incomplete
> since no main.cpp (presumably Qt5-related) is provided (as far as I
> can discover).  Any chance you could provide that simple example for
> developers like me who don't have a lot of Qt5 or C++ expertise but
> who just want to build other's Qt5-related work using the best
> CMake-related methods?

Hi Stephen:

Further to this particular subtopic, a google search found me several
qt hello world examples.  The most prominent one does not work (it
uses an ancient method which is no longer supported by Qt!), but
I found that the one in <https://wiki.qt.io/Qt_for_Beginners> does work
perfectly with the tutorial Qt5 cmake example.  So I request you
make that hello world routine (or something closely related) available
at <http://doc.qt.io/qt-5/cmake-manual.html> to make that tutorial
more self-contained.

That said, there are no issues with setting macros in this simple
hello world case so it doesn't help with the principal issue covered
in my e-mail where I cannot seem to set the macros needed for automoc
to work properly.

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
__________________________

From steve.lorimer at gmail.com  Sun Oct 16 18:46:26 2016
From: steve.lorimer at gmail.com (Steve Lorimer)
Date: Sun, 16 Oct 2016 17:46:26 -0500
Subject: [CMake] How to configure CMake to add current path to include
	directive.
Message-ID: <CAE-NPOj8EwxX_OidoiYn_x5zjEH_b9Tp_owMuobW9ZScXeWNbQ@mail.gmail.com>

In makefile parlance, I'm trying to add -I. (ie: the current directory) to
my include paths

I tried the following:

include_directories(".")


This doesn't work unfortunately, as relative paths are interpreted as
relative to the current source directory
<https://cmake.org/cmake/help/v3.0/command/include_directories.html>

That is, if this statement is in my top level CMakeLists.txt, located in
~/src/project, the include directive added will be "-I ~/src/project/.",
whereas I'm trying to add "-I ."

The reason for my wanting this is that we have sources for a single library
in several subdirs.

include_directories(${CMAKE_CURRENT_SOURCE_DIR})

add_library(
foo
STATIC
foo.cpp
bar/bar.cpp
)

In bar/bar.cpp, I have a relative include

#include "../foo.h"

With the above setup, this will fail to compile as only ~/src/project/foo
will be added to the include paths.

I'm aware that if I explicitly added the path it would work

include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)

However, if there is a way to get -I. added to my include path, that's what
I'm after.

TIA
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161016/4f0c1f4e/attachment.html>

From craig.scott at crascit.com  Sun Oct 16 18:51:10 2016
From: craig.scott at crascit.com (Craig Scott)
Date: Mon, 17 Oct 2016 09:51:10 +1100
Subject: [CMake] How to configure CMake to add current path to include
	directive.
In-Reply-To: <CAE-NPOj8EwxX_OidoiYn_x5zjEH_b9Tp_owMuobW9ZScXeWNbQ@mail.gmail.com>
References: <CAE-NPOj8EwxX_OidoiYn_x5zjEH_b9Tp_owMuobW9ZScXeWNbQ@mail.gmail.com>
Message-ID: <CA+dygYkfTh-LRcXk0v4dLM_hC_qW8So9iAR6Nt7a4_U0Bmt_VA@mail.gmail.com>

I think if you manipulate the target property INCLUDE_DIRECTORIES
<https://cmake.org/cmake/help/latest/prop_tgt/INCLUDE_DIRECTORIES.html>
directly, you should be able to force a "." in there without having it
substituted for an absolute path. By this I mean use set_property() or
set_target_properties() rather than target_include_directories() or
include_directories(). Note, however, that the documentation for the
INCLUDE_DIRECTORIES property explicitly recommends against adding relative
paths to the property like this (but in your case it sounds like you really
want a relative path, so maybe this is a valid exception to that advice).



On Mon, Oct 17, 2016 at 9:46 AM, Steve Lorimer <steve.lorimer at gmail.com>
wrote:

> In makefile parlance, I'm trying to add -I. (ie: the current directory) to
> my include paths
>
> I tried the following:
>
> include_directories(".")
>
>
> This doesn't work unfortunately, as relative paths are interpreted as
> relative to the current source directory
> <https://cmake.org/cmake/help/v3.0/command/include_directories.html>
>
> That is, if this statement is in my top level CMakeLists.txt, located in
> ~/src/project, the include directive added will be "-I ~/src/project/.",
> whereas I'm trying to add "-I ."
>
> The reason for my wanting this is that we have sources for a single
> library in several subdirs.
>
> include_directories(${CMAKE_CURRENT_SOURCE_DIR})
>
> add_library(
> foo
> STATIC
> foo.cpp
> bar/bar.cpp
> )
>
> In bar/bar.cpp, I have a relative include
>
> #include "../foo.h"
>
> With the above setup, this will fail to compile as only ~/src/project/foo
> will be added to the include paths.
>
> I'm aware that if I explicitly added the path it would work
>
> include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)
>
> However, if there is a way to get -I. added to my include path, that's
> what I'm after.
>
> TIA
> Steve
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161017/16aafb66/attachment.html>

From steve.lorimer at gmail.com  Sun Oct 16 19:31:13 2016
From: steve.lorimer at gmail.com (Steve Lorimer)
Date: Sun, 16 Oct 2016 18:31:13 -0500
Subject: [CMake] How to configure CMake to add current path to include
	directive.
In-Reply-To: <CA+dygYkfTh-LRcXk0v4dLM_hC_qW8So9iAR6Nt7a4_U0Bmt_VA@mail.gmail.com>
References: <CAE-NPOj8EwxX_OidoiYn_x5zjEH_b9Tp_owMuobW9ZScXeWNbQ@mail.gmail.com>
 <CA+dygYkfTh-LRcXk0v4dLM_hC_qW8So9iAR6Nt7a4_U0Bmt_VA@mail.gmail.com>
Message-ID: <CAE-NPOgtza0t-2df4F3coQsS9rtcBEk-1HEX334XnX4CO8Er5w@mail.gmail.com>

Thanks Craig

Not sure if I'm doing it right, but I couldn't get that to work.

Would you be able to give me an example please?

Thanks
Steve



On 16 October 2016 at 17:51, Craig Scott <craig.scott at crascit.com> wrote:

> I think if you manipulate the target property INCLUDE_DIRECTORIES
> <https://cmake.org/cmake/help/latest/prop_tgt/INCLUDE_DIRECTORIES.html>
> directly, you should be able to force a "." in there without having it
> substituted for an absolute path. By this I mean use set_property() or
> set_target_properties() rather than target_include_directories() or
> include_directories(). Note, however, that the documentation for the
> INCLUDE_DIRECTORIES property explicitly recommends against adding relative
> paths to the property like this (but in your case it sounds like you really
> want a relative path, so maybe this is a valid exception to that advice).
>
>
>
> On Mon, Oct 17, 2016 at 9:46 AM, Steve Lorimer <steve.lorimer at gmail.com>
> wrote:
>
>> In makefile parlance, I'm trying to add -I. (ie: the current directory)
>> to my include paths
>>
>> I tried the following:
>>
>> include_directories(".")
>>
>>
>> This doesn't work unfortunately, as relative paths are interpreted as
>> relative to the current source directory
>> <https://cmake.org/cmake/help/v3.0/command/include_directories.html>
>>
>> That is, if this statement is in my top level CMakeLists.txt, located in
>> ~/src/project, the include directive added will be "-I ~/src/project/.",
>> whereas I'm trying to add "-I ."
>>
>> The reason for my wanting this is that we have sources for a single
>> library in several subdirs.
>>
>> include_directories(${CMAKE_CURRENT_SOURCE_DIR})
>>
>> add_library(
>> foo
>> STATIC
>> foo.cpp
>> bar/bar.cpp
>> )
>>
>> In bar/bar.cpp, I have a relative include
>>
>> #include "../foo.h"
>>
>> With the above setup, this will fail to compile as only ~/src/project/foo
>> will be added to the include paths.
>>
>> I'm aware that if I explicitly added the path it would work
>>
>> include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)
>>
>> However, if there is a way to get -I. added to my include path, that's
>> what I'm after.
>>
>> TIA
>> Steve
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161016/1a01c410/attachment-0001.html>

From craig.scott at crascit.com  Sun Oct 16 19:35:07 2016
From: craig.scott at crascit.com (Craig Scott)
Date: Mon, 17 Oct 2016 10:35:07 +1100
Subject: [CMake] How to configure CMake to add current path to include
	directive.
In-Reply-To: <CAE-NPOgtza0t-2df4F3coQsS9rtcBEk-1HEX334XnX4CO8Er5w@mail.gmail.com>
References: <CAE-NPOj8EwxX_OidoiYn_x5zjEH_b9Tp_owMuobW9ZScXeWNbQ@mail.gmail.com>
 <CA+dygYkfTh-LRcXk0v4dLM_hC_qW8So9iAR6Nt7a4_U0Bmt_VA@mail.gmail.com>
 <CAE-NPOgtza0t-2df4F3coQsS9rtcBEk-1HEX334XnX4CO8Er5w@mail.gmail.com>
Message-ID: <CA+dygYmtzCWVq=DAKvmOusdVNYr31A4SDsE7bYrLLcXcjV1EKA@mail.gmail.com>

Something like the following was what I had in mind (untested):

get_target_property(incDirs someTarget INCLUDE_DIRECTORIES)
list(APPEND incDirs .)
set_target_properties(someTarget PROPERTIES INCLUDE_DIRECTORIES
"${incDirs}")


On Mon, Oct 17, 2016 at 10:31 AM, Steve Lorimer <steve.lorimer at gmail.com>
wrote:

> Thanks Craig
>
> Not sure if I'm doing it right, but I couldn't get that to work.
>
> Would you be able to give me an example please?
>
> Thanks
> Steve
>
>
>
> On 16 October 2016 at 17:51, Craig Scott <craig.scott at crascit.com> wrote:
>
>> I think if you manipulate the target property INCLUDE_DIRECTORIES
>> <https://cmake.org/cmake/help/latest/prop_tgt/INCLUDE_DIRECTORIES.html>
>> directly, you should be able to force a "." in there without having it
>> substituted for an absolute path. By this I mean use set_property() or
>> set_target_properties() rather than target_include_directories() or
>> include_directories(). Note, however, that the documentation for the
>> INCLUDE_DIRECTORIES property explicitly recommends against adding relative
>> paths to the property like this (but in your case it sounds like you really
>> want a relative path, so maybe this is a valid exception to that advice).
>>
>>
>>
>> On Mon, Oct 17, 2016 at 9:46 AM, Steve Lorimer <steve.lorimer at gmail.com>
>> wrote:
>>
>>> In makefile parlance, I'm trying to add -I. (ie: the current directory)
>>> to my include paths
>>>
>>> I tried the following:
>>>
>>> include_directories(".")
>>>
>>>
>>> This doesn't work unfortunately, as relative paths are interpreted as
>>> relative to the current source directory
>>> <https://cmake.org/cmake/help/v3.0/command/include_directories.html>
>>>
>>> That is, if this statement is in my top level CMakeLists.txt, located in
>>> ~/src/project, the include directive added will be "-I ~/src/project/.",
>>> whereas I'm trying to add "-I ."
>>>
>>> The reason for my wanting this is that we have sources for a single
>>> library in several subdirs.
>>>
>>> include_directories(${CMAKE_CURRENT_SOURCE_DIR})
>>>
>>> add_library(
>>> foo
>>> STATIC
>>> foo.cpp
>>> bar/bar.cpp
>>> )
>>>
>>> In bar/bar.cpp, I have a relative include
>>>
>>> #include "../foo.h"
>>>
>>> With the above setup, this will fail to compile as only
>>> ~/src/project/foo will be added to the include paths.
>>>
>>> I'm aware that if I explicitly added the path it would work
>>>
>>> include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)
>>>
>>> However, if there is a way to get -I. added to my include path, that's
>>> what I'm after.
>>>
>>> TIA
>>> Steve
>>>
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>>
>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161017/fa98f773/attachment.html>

From irwin at beluga.phys.uvic.ca  Sun Oct 16 21:40:36 2016
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sun, 16 Oct 2016 18:40:36 -0700 (PDT)
Subject: [CMake] Cannot get automoc to work properly with recommended
 Qt5 support method
In-Reply-To: <alpine.DEB.2.11.1610161252300.1243@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1610161252300.1243@enira.zlyna.ubzr>
Message-ID: <alpine.DEB.2.11.1610161738430.1243@enira.zlyna.ubzr>

On 2016-10-16 13:43-0700 Alan W. Irwin wrote:

> Hi Stephen:
>
> I am addressing you directly (as well as the list) because you have
> been so helpful with Qt5 issues in the past.
>
> The PLplot build system (some of whose components depend on Qt5)
> currently uses one of the older Qt5 support methods documented at
> <http://doc.qt.io/qt-5/cmake-manual.html>.  But that method is complex
> and we are currently running into troubles with it where it uses the
> plain target_link_libraries command which conflicts with the keyworded
> version that we prefer for our build system.  So I have attempted to
> update our Qt5 support to the latest target_link_libraries method
> documented at the above URL, but automoc appears not to be working
> correctly.
>
> I follow the advice in the above URL and set
>
> set(CMAKE_AUTOMOC ON)
>
> and also set AUTOMOC_MOC_OPTIONS to the following list:
>
> -DPLD_bmpqt;-DPLD_jpgqt;-DPLD_pngqt;-DPLD_ppmqt;-DPLD_tiffqt;-DPLD_svgqt;-DPLD_pdfqt;-DPLD_qtwidget;-DPLD_extqt;-DPLD_memqt
>
> This list is the same as I use for MOC_OPTIONS in the old working method, and
> these various macro definitions _must_ be defined to avoid dropping large
> swaths of our code from the compilation.  Instead of using
>
> set(CMAKE_INCLUDE_CURRENT_DIR ON)
>
> I use instead (in the directory where the plplotqt library is built)
>
> include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ...)
>
> Furthermore, in that same directory I use
>
> target_link_libraries(plplotqt PRIVATE plplot ${MATH_LIB} Qt5::Svg Qt5::Gui 
> Qt5::PrintSupport)
>
> for the build.  Although that build apparently works with no obvious
> issues, there is no sign of any of the above macros in the
> VERBOSE=1 output.  Furthermore, I get the following near-empty result
> for the generated bindings/qt_gui/plplotqt_automoc.cpp file which
> consists just of the following two lines:
>
> /* This file is autogenerated, do not edit*/
> enum some_compilers { need_more_than_nothing };
>
> Finally,
>
> "ldd -r bindings/qt_gui/libplplotqt.st"
>
> shows missing symbols that should be defined if the above macros are
> defined.
>
> What am I missing?

I have now looked further, and the missing symbols in the library
correspond exactly to classes in an included header (in a different
PLplot source-tree directory, see below) that have a reference to Q_OBJECT.
Furthermore, when I exclude some of those classes by manipulating
AUTOMOC_MOC_OPTIONS, the corresponding missing symbols disappear from
the library so it appears AUTOMOC_MOC_OPTIONS is actually working
despite no visible sign of that in the "make VERBOSE=1 ..." results.

So I am now looking at something else which is referred to in the
following (from CMake 3.6) automoc documentation (where I have
interpolated questions concerning the ambiguities in that
documentation):

When this property is set ON, CMake will scan the source files at build time and invoke moc accordingly.

<QUESTION: do "source files" include all software project headers that are mentioned
in #include statements?/>

If an #include statement like #include "moc_foo.cpp" is found,

<QUESTIONS: found where?  in the source file or header file #included
from that source file?  With regard to the name pattern, is it
assumed the source file is called foo.cpp?/>

the
Q_OBJECT class declaration is expected in the header, and moc is run
on the header file. A moc_foo.cpp file will be generated from the
source?s header into the CMAKE_CURRENT_BINARY_DIR directory. This
allows the compiler to find the included moc_foo.cpp file regardless
of the location the original source. [....]

If an #include statement like #include "foo.moc" is found,

<QUESTION: found where?  in source file or header file?/>

then a
Q_OBJECT is expected in the current source file and moc is run on the
file itself. Additionally, header files with the same base name (like
foo.h) or _p appended to the base name (like foo_p.h) are parsed for
Q_OBJECT macros, and if found, moc is also executed on those files.
AUTOMOC checks multiple header alternative extensions, such as hpp,
hxx etc when searching for headers.

<QUESTION: does moc follow just ordinary #includes in a source file?  I have a specific
example below./>

The resulting moc files, which are
not included as shown above in any of the source files are included in
a generated <targetname>_automoc.cpp file, which is compiled as part
of the target.

I have no such #includes which is probably the entire source of the
issue, but I cannot figure out exactly what to do because of ambiguities
in the above documentation concerning what should be in the header
and what should be in the source file.

To be explicit suppose you have some source code named fooqt.cpp
which contains

#include "barqt.h"

which declares some classes for the software package that refer to Q_OBJECT
and some classes that do not refer to Q_OBJECT.

What is the #include recipe to get automoc to work for this specific case?

In the next few hours I plan to try some #include variations allowed
by the ambiguities of the above documentation so I may eventually
answer my own question by these experiments.  But it would be nice to
get a definitive answer.

@CMake developers: It would be nice to also have an automoc
documentation fix for those ambiguities since the #include pattern in
the source code must be different than what works for older Qt5
support methods that do not use automoc.

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
__________________________

From steve.lorimer at gmail.com  Sun Oct 16 22:03:35 2016
From: steve.lorimer at gmail.com (Steve Lorimer)
Date: Sun, 16 Oct 2016 21:03:35 -0500
Subject: [CMake] How to configure CMake to add current path to include
	directive.
In-Reply-To: <CA+dygYmtzCWVq=DAKvmOusdVNYr31A4SDsE7bYrLLcXcjV1EKA@mail.gmail.com>
References: <CAE-NPOj8EwxX_OidoiYn_x5zjEH_b9Tp_owMuobW9ZScXeWNbQ@mail.gmail.com>
 <CA+dygYkfTh-LRcXk0v4dLM_hC_qW8So9iAR6Nt7a4_U0Bmt_VA@mail.gmail.com>
 <CAE-NPOgtza0t-2df4F3coQsS9rtcBEk-1HEX334XnX4CO8Er5w@mail.gmail.com>
 <CA+dygYmtzCWVq=DAKvmOusdVNYr31A4SDsE7bYrLLcXcjV1EKA@mail.gmail.com>
Message-ID: <CAE-NPOhAHM+DVbRpKBY1XaGsBtVH-Ywmm3+Lk-C-ZWDdoXRXFQ@mail.gmail.com>

Thanks Craig

Looks like it did what you intended, but cmake won't allow it

CMake Error in foo/CMakeLists.txt:
  Found relative path while evaluating include directories of "foo":

    "."


Bummer! :(



On 16 October 2016 at 18:35, Craig Scott <craig.scott at crascit.com> wrote:

> Something like the following was what I had in mind (untested):
>
> get_target_property(incDirs someTarget INCLUDE_DIRECTORIES)
> list(APPEND incDirs .)
> set_target_properties(someTarget PROPERTIES INCLUDE_DIRECTORIES
> "${incDirs}")
>
>
> On Mon, Oct 17, 2016 at 10:31 AM, Steve Lorimer <steve.lorimer at gmail.com>
> wrote:
>
>> Thanks Craig
>>
>> Not sure if I'm doing it right, but I couldn't get that to work.
>>
>> Would you be able to give me an example please?
>>
>> Thanks
>> Steve
>>
>>
>>
>> On 16 October 2016 at 17:51, Craig Scott <craig.scott at crascit.com> wrote:
>>
>>> I think if you manipulate the target property INCLUDE_DIRECTORIES
>>> <https://cmake.org/cmake/help/latest/prop_tgt/INCLUDE_DIRECTORIES.html>
>>> directly, you should be able to force a "." in there without having it
>>> substituted for an absolute path. By this I mean use set_property() or
>>> set_target_properties() rather than target_include_directories() or
>>> include_directories(). Note, however, that the documentation for the
>>> INCLUDE_DIRECTORIES property explicitly recommends against adding relative
>>> paths to the property like this (but in your case it sounds like you really
>>> want a relative path, so maybe this is a valid exception to that advice).
>>>
>>>
>>>
>>> On Mon, Oct 17, 2016 at 9:46 AM, Steve Lorimer <steve.lorimer at gmail.com>
>>> wrote:
>>>
>>>> In makefile parlance, I'm trying to add -I. (ie: the current directory)
>>>> to my include paths
>>>>
>>>> I tried the following:
>>>>
>>>> include_directories(".")
>>>>
>>>>
>>>> This doesn't work unfortunately, as relative paths are interpreted as
>>>> relative to the current source directory
>>>> <https://cmake.org/cmake/help/v3.0/command/include_directories.html>
>>>>
>>>> That is, if this statement is in my top level CMakeLists.txt, located
>>>> in ~/src/project, the include directive added will be "-I ~/src/project/.",
>>>> whereas I'm trying to add "-I ."
>>>>
>>>> The reason for my wanting this is that we have sources for a single
>>>> library in several subdirs.
>>>>
>>>> include_directories(${CMAKE_CURRENT_SOURCE_DIR})
>>>>
>>>> add_library(
>>>> foo
>>>> STATIC
>>>> foo.cpp
>>>> bar/bar.cpp
>>>> )
>>>>
>>>> In bar/bar.cpp, I have a relative include
>>>>
>>>> #include "../foo.h"
>>>>
>>>> With the above setup, this will fail to compile as only
>>>> ~/src/project/foo will be added to the include paths.
>>>>
>>>> I'm aware that if I explicitly added the path it would work
>>>>
>>>> include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)
>>>>
>>>> However, if there is a way to get -I. added to my include path, that's
>>>> what I'm after.
>>>>
>>>> TIA
>>>> Steve
>>>>
>>>>
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For
>>>> more information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/cmake
>>>>
>>>
>>>
>>>
>>> --
>>> Craig Scott
>>> Melbourne, Australia
>>> https://crascit.com
>>>
>>
>>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161016/4f9e0e17/attachment-0001.html>

From irwin at beluga.phys.uvic.ca  Mon Oct 17 02:00:38 2016
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sun, 16 Oct 2016 23:00:38 -0700 (PDT)
Subject: [CMake] Cannot get automoc to work properly with recommended
 Qt5 support method
In-Reply-To: <alpine.DEB.2.11.1610161738430.1243@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1610161252300.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610161738430.1243@enira.zlyna.ubzr>
Message-ID: <alpine.DEB.2.11.1610162136040.1243@enira.zlyna.ubzr>

On 2016-10-16 18:40-0700 Alan W. Irwin wrote:

> To be explicit suppose you have some source code named fooqt.cpp
> which contains
>
> #include "barqt.h"
>
> which declares some classes for the software package that refer to Q_OBJECT
> and some classes that do not refer to Q_OBJECT.
>
> What is the #include recipe to get automoc to work for this specific case?
>
> In the next few hours I plan to try some #include variations allowed
> by the ambiguities of the above documentation so I may eventually
> answer my own question by these experiments.  But it would be nice to
> get a definitive answer.

It turned out I could get it to work by specifying (at the end of
fooqt.cpp)

#include "moc_barqt.cpp"

However, it only looked in the directory where fooqt.cpp was located
for barqt.h, and a special twist for the PLplot case was barqt.h was
located in a separate directory so it could not find it.  I then tried
adding the appropriate -I directive to CMAKE_AUTOMOC_MOC_OPTIONS.
Note, this time I used the correct name of that variable (and not
AUTOMOC_MOC_OPTIONS like I used before.) So VERBOSE=1 output showed
moc being run properly with all the macros defined as well as that -I
directive.  However, it was run on the barqt.h in the same directory
where fooqt.cpp was located and failed because barqt.h only existed in
a separate directory.  I worked around this by temporarily deploying a
symlink, but that method won't work on Windows, and it may generate
name conflicts for the case of our other Qt5-related components
built in separate directories which also use this same header.

So is there a proper method to work with headers that that are used by
multiple software components in different directories?  If not, I
would consider that to be a big deficiency of the latest Qt5 support
method since this is not a problem for the old Qt5 support method.

By the way, even with the symlink workaround that allows automoc to
generate a moc command that actually works, the moc_barqt.cpp results
that are #included in fooqt.cpp generate two compiler errors when
fooqt.cpp is built.  So I will try to use my rudimentary C++ skills to
debug that issue going forward, and I may ask more questions
concerning those build issues if I cannot figure these build issues
out.

A general comment is this whole project to update to the latest Qt5
support method has been painful, and it is not done yet even for just
the one component I am testing it on so far.  And this pain is despite
the fact that the PLplot build worked smoothly (aside from the
plain/keyword target_link_libraries conflict that motivated this
update) before using the old Qt5 support method.  Less ambiguous
documentation of automoc that included how to deal with include files
that are #included by separate software components in different
directories would ease the pain of using the latest Qt5 support method
considerably.

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
__________________________

From floooh at gmail.com  Mon Oct 17 06:44:14 2016
From: floooh at gmail.com (Floh)
Date: Mon, 17 Oct 2016 12:44:14 +0200
Subject: [CMake] Support for Visual Studio Linux cross-compiling extension
Message-ID: <CAF00CNRWYM=VE_t8=3wQ5aKgNTVkdbOvd5XESWZAOLkhpNsPvg@mail.gmail.com>

Hi,

Microsoft has added support for remote-compiling and -debugging on
Linux from within Visual Studio through an official VS extension:
https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/

My question: is it already possible to generate a Visual Studio
solution for this scenario? If not, is support for this planned,
similar to the Android cross-compile scenario?

It would be nice if I could generate such a solution with (for instance):

cmake -G "Visual Studio 14" -DCMAKE_SYSTEM_NAME=VSLinux

I've been looking at the generated solution files, and the only
'interesting' part in the vxproj file seems to be this section:

---
  <PropertyGroup Label="Globals">
    <ProjectGuid>{2e73db3c-a17c-4694-996c-2cca151ed9f2}</ProjectGuid>
    <Keyword>Linux</Keyword>
    <RootNamespace>ConsoleApplication1</RootNamespace>
    <MinimumVisualStudioVersion>14.0</MinimumVisualStudioVersion>
    <ApplicationType>Linux</ApplicationType>
    <ApplicationTypeRevision>1.0</ApplicationTypeRevision>
    <TargetLinuxPlatform>Generic</TargetLinuxPlatform>
    <LinuxProjectType>{D51BCBC9-82E9-4017-911E-C93873C4EA2B}</LinuxProjectType>
  </PropertyGroup>
---

There seems to be a hardwired mapping between Visual Studio compiler
options and gcc/clang options, for instance setting optimization to
-O3 in the VS property dialog adds these lines to the vxproj file:

---
  <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    <ClCompile>
      <Optimization>Full</Optimization>
    </ClCompile>
  </ItemDefinitionGroup>
---

Cheers & thanks,
-Floh.

From randallsturner13 at gmail.com  Mon Oct 17 10:59:56 2016
From: randallsturner13 at gmail.com (Randy Turner)
Date: Mon, 17 Oct 2016 10:59:56 -0400
Subject: [CMake] Single Letter Omissions From File Path In Linker
In-Reply-To: <CACJ51z2XanJbr9geG6qTSa9sXsYpqxx7x0myazMeVBb9JR+jWQ@mail.gmail.com>
References: <CAB8TE6HHpyZcEF2kCtYstRaOETpYV-Y43G96eK+nYPOq4NgyKQ@mail.gmail.com>
 <CACJ51z2XanJbr9geG6qTSa9sXsYpqxx7x0myazMeVBb9JR+jWQ@mail.gmail.com>
Message-ID: <CAB8TE6FsPqjB6__LcxTNHcXvXWWXPMML91hPLt287NdTdQgwig@mail.gmail.com>

Thanks, Andrew, Bill, and Zan! I'm not completely certain that reinstalling
Windows is the only or even the best solution, but once we all moved our
repositories into our root directories I have not found another solution,
even temporary. Of our six dev machines, it is a recurring problem on two
and has occurred once on a third. The other three have never seen this
problem.

I did some digging on Friday and found that the problem seems to be
connected to this call below to add all of our code files to a library to
be used an item in the add_executable() command for each of our targets.

foreach (code ${code_files})
    get_filename_component (codeName ${code} NAME_WE)
    add_library (${codeName} OBJECT
     ${code}
  )
  list(APPEND codelib $<TARGET_OBJECTS:${codeName}>)
endforeach()

If I remove that loop and add code_files instead of codelib to the
executables then the problem disappears, but this breaks most of the
functionality of my implementation of CMake, so this isn't a long-term
solution. Using the library call above I followed the file paths around the
script and printed them out at every step through the makefile generation
and never saw any incorrect paths, but then I called the compiler and saw
it error out.

The project uses "Unix Makefiles" to run on TI's gmake compiler 7.4.14. I'm
have been using CMake 3.5.2. I upgraded to 3.6.2 and continue to see the
same problem. I will move forward with looking into this library issue but
I'm sure what I expect to find.

On Fri, Oct 14, 2016 at 10:16 AM, Andrew Bell <andrew.bell.ia at gmail.com>
wrote:

> On Fri, Oct 14, 2016 at 9:04 AM, Randy Turner <randallsturner13 at gmail.com>
> wrote:
>
>> Hello! I've been running into a frustrating issue on and off for the past
>> year. The project will build the source files correctly but when it comes
>> to linking the executables, I always get the same error. The specific file
>> varies, but the failure mode is always the same. For example:
>>
>> <Linking>
>> "C:\\Users\\User\\AppData\\Local\\Temp\\<six digit temp file>", line
>> xxx: error #10008-D: cannot find file
>> "C:/Repos/operatingsystem/CMakeFiles/nvm_validate_ierator.di
>> r/os/nvm/nvm_validate_iterator.c.obj"
>>
>> As you can see, the file path is missing a "t" in the first occurrence of
>> the word "iterator" and so that file definitely does not exist. A file
>> exists in the location with correct spelling, but somehow that hardcoded
>> path in that temporary file has dropped a letter. The specific letter that
>> gets dropped varies along with which file is allegedly missing. We noticed
>> that requiring people to store the repository in their root directory
>> greatly cut down on the occurrence of this issue but it is returning with
>> more frequency as of late. Once it occurs once, CMake builds are never
>> successful again and the only way that I have been able to completely clear
>> the problem has been to reinstall Windows and set up the build environment
>> again.
>>
>
> This seems really, really strange.  Have to reinstall Windows?  What about
> just using another build directory?  It sure *seems* like there's some
> problem in your CMakeFiles.txt where the way the filepath is being
> constructed is incorrect.  But I don't think you've really provided enough
> information to determine the problem.  Where does the name of the object
> file come from?
>
> --
> Andrew Bell
> andrew.bell.ia at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161017/e8d3adeb/attachment.html>

From bill.hoffman at kitware.com  Mon Oct 17 11:54:02 2016
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Mon, 17 Oct 2016 11:54:02 -0400
Subject: [CMake] Single Letter Omissions From File Path In Linker
In-Reply-To: <CAB8TE6FsPqjB6__LcxTNHcXvXWWXPMML91hPLt287NdTdQgwig@mail.gmail.com>
References: <CAB8TE6HHpyZcEF2kCtYstRaOETpYV-Y43G96eK+nYPOq4NgyKQ@mail.gmail.com>
 <CACJ51z2XanJbr9geG6qTSa9sXsYpqxx7x0myazMeVBb9JR+jWQ@mail.gmail.com>
 <CAB8TE6FsPqjB6__LcxTNHcXvXWWXPMML91hPLt287NdTdQgwig@mail.gmail.com>
Message-ID: <afbe09a8-dada-56de-8a8c-798c48c629a5@kitware.com>

Can you create a small example that shows the problem?  Even a small 
full example with the code you have below so I can better understand it.

-Bill


On 10/17/2016 10:59 AM, Randy Turner wrote:
> Thanks, Andrew, Bill, and Zan! I'm not completely certain that
> reinstalling Windows is the only or even the best solution, but once we
> all moved our repositories into our root directories I have not found
> another solution, even temporary. Of our six dev machines, it is a
> recurring problem on two and has occurred once on a third. The other
> three have never seen this problem.
>
> I did some digging on Friday and found that the problem seems to be
> connected to this call below to add all of our code files to a library
> to be used an item in the add_executable() command for each of our targets.
>
> foreach (code ${code_files})
>     get_filename_component (codeName ${code} NAME_WE)
>     add_library (${codeName} OBJECT
>      ${code}
>   )
>   list(APPEND codelib $<TARGET_OBJECTS:${codeName}>)
> endforeach()
>
> If I remove that loop and add code_files instead of codelib to the
> executables then the problem disappears, but this breaks most of the
> functionality of my implementation of CMake, so this isn't a long-term
> solution. Using the library call above I followed the file paths around
> the script and printed them out at every step through the makefile
> generation and never saw any incorrect paths, but then I called the
> compiler and saw it error out.
>
> The project uses "Unix Makefiles" to run on TI's gmake compiler 7.4.14.
> I'm have been using CMake 3.5.2. I upgraded to 3.6.2 and continue to see
> the same problem. I will move forward with looking into this library
> issue but I'm sure what I expect to find.
>
> On Fri, Oct 14, 2016 at 10:16 AM, Andrew Bell <andrew.bell.ia at gmail.com
> <mailto:andrew.bell.ia at gmail.com>> wrote:
>
>     On Fri, Oct 14, 2016 at 9:04 AM, Randy Turner
>     <randallsturner13 at gmail.com <mailto:randallsturner13 at gmail.com>> wrote:
>
>         Hello! I've been running into a frustrating issue on and off for
>         the past year. The project will build the source files correctly
>         but when it comes to linking the executables, I always get the
>         same error. The specific file varies, but the failure mode is
>         always the same. For example:
>
>         <Linking>
>         "C:\\Users\\User\\AppData\\Local\\Temp\\<six digit temp file>",
>         line xxx: error #10008-D: cannot find file
>         "C:/Repos/operatingsystem/CMakeFiles/nvm_validate_ierator.dir/os/nvm/nvm_validate_iterator.c.obj"
>
>         As you can see, the file path is missing a "t" in the first
>         occurrence of the word "iterator" and so that file definitely
>         does not exist. A file exists in the location with correct
>         spelling, but somehow that hardcoded path in that temporary file
>         has dropped a letter. The specific letter that gets dropped
>         varies along with which file is allegedly missing. We noticed
>         that requiring people to store the repository in their root
>         directory greatly cut down on the occurrence of this issue but
>         it is returning with more frequency as of late. Once it occurs
>         once, CMake builds are never successful again and the only way
>         that I have been able to completely clear the problem has been
>         to reinstall Windows and set up the build environment again.
>
>
>     This seems really, really strange.  Have to reinstall Windows?  What
>     about just using another build directory?  It sure *seems* like
>     there's some problem in your CMakeFiles.txt where the way the
>     filepath is being constructed is incorrect.  But I don't think
>     you've really provided enough information to determine the problem.
>     Where does the name of the object file come from?
>
>     --
>     Andrew Bell
>     andrew.bell.ia at gmail.com <mailto:andrew.bell.ia at gmail.com>
>
>
>
>


-- 
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoffman at kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573

From max.smolens at kitware.com  Mon Oct 17 13:50:23 2016
From: max.smolens at kitware.com (Max Smolens)
Date: Mon, 17 Oct 2016 13:50:23 -0400
Subject: [CMake] Single Letter Omissions From File Path In Linker
In-Reply-To: <CAB8TE6FsPqjB6__LcxTNHcXvXWWXPMML91hPLt287NdTdQgwig@mail.gmail.com>
References: <CAB8TE6HHpyZcEF2kCtYstRaOETpYV-Y43G96eK+nYPOq4NgyKQ@mail.gmail.com>
 <CACJ51z2XanJbr9geG6qTSa9sXsYpqxx7x0myazMeVBb9JR+jWQ@mail.gmail.com>
 <CAB8TE6FsPqjB6__LcxTNHcXvXWWXPMML91hPLt287NdTdQgwig@mail.gmail.com>
Message-ID: <CAH47YeowW5mRNi9ykozSdpgK3xNrLqgRYnQMPAHMmeVof-_6rg@mail.gmail.com>

Hi Randy,

The missing character issue is likely due to some stage of your build
process hitting a command line length limit on Windows. Similar problems
have been described in 3D Slicer builds [1] [2], although in that case the
problems were related to (a) many include directories and (b) explicitly
passing a long command line to add_custom_command().

Your project may be different, because the error occurs while linking, but
hopefully these references help.

Thanks,
Max

[1] http://slicer-devel.65872.n3.nabble.com/VS2008-build-
td4032311.html#a4032337
[2] https://www.na-mic.org/Bug/view.php?id=3157


On Mon, Oct 17, 2016 at 10:59 AM, Randy Turner <randallsturner13 at gmail.com>
wrote:

> Thanks, Andrew, Bill, and Zan! I'm not completely certain that
> reinstalling Windows is the only or even the best solution, but once we all
> moved our repositories into our root directories I have not found another
> solution, even temporary. Of our six dev machines, it is a recurring
> problem on two and has occurred once on a third. The other three have never
> seen this problem.
>
> I did some digging on Friday and found that the problem seems to be
> connected to this call below to add all of our code files to a library to
> be used an item in the add_executable() command for each of our targets.
>
> foreach (code ${code_files})
>     get_filename_component (codeName ${code} NAME_WE)
>     add_library (${codeName} OBJECT
>      ${code}
>   )
>   list(APPEND codelib $<TARGET_OBJECTS:${codeName}>)
> endforeach()
>
> If I remove that loop and add code_files instead of codelib to the
> executables then the problem disappears, but this breaks most of the
> functionality of my implementation of CMake, so this isn't a long-term
> solution. Using the library call above I followed the file paths around the
> script and printed them out at every step through the makefile generation
> and never saw any incorrect paths, but then I called the compiler and saw
> it error out.
>
> The project uses "Unix Makefiles" to run on TI's gmake compiler 7.4.14.
> I'm have been using CMake 3.5.2. I upgraded to 3.6.2 and continue to see
> the same problem. I will move forward with looking into this library issue
> but I'm sure what I expect to find.
>
> On Fri, Oct 14, 2016 at 10:16 AM, Andrew Bell <andrew.bell.ia at gmail.com>
> wrote:
>
>> On Fri, Oct 14, 2016 at 9:04 AM, Randy Turner <randallsturner13 at gmail.com
>> > wrote:
>>
>>> Hello! I've been running into a frustrating issue on and off for the
>>> past year. The project will build the source files correctly but when it
>>> comes to linking the executables, I always get the same error. The specific
>>> file varies, but the failure mode is always the same. For example:
>>>
>>> <Linking>
>>> "C:\\Users\\User\\AppData\\Local\\Temp\\<six digit temp file>", line
>>> xxx: error #10008-D: cannot find file
>>> "C:/Repos/operatingsystem/CMakeFiles/nvm_validate_ierator.di
>>> r/os/nvm/nvm_validate_iterator.c.obj"
>>>
>>> As you can see, the file path is missing a "t" in the first occurrence
>>> of the word "iterator" and so that file definitely does not exist. A file
>>> exists in the location with correct spelling, but somehow that hardcoded
>>> path in that temporary file has dropped a letter. The specific letter that
>>> gets dropped varies along with which file is allegedly missing. We noticed
>>> that requiring people to store the repository in their root directory
>>> greatly cut down on the occurrence of this issue but it is returning with
>>> more frequency as of late. Once it occurs once, CMake builds are never
>>> successful again and the only way that I have been able to completely clear
>>> the problem has been to reinstall Windows and set up the build environment
>>> again.
>>>
>>
>> This seems really, really strange.  Have to reinstall Windows?  What
>> about just using another build directory?  It sure *seems* like there's
>> some problem in your CMakeFiles.txt where the way the filepath is being
>> constructed is incorrect.  But I don't think you've really provided enough
>> information to determine the problem.  Where does the name of the object
>> file come from?
>>
>> --
>> Andrew Bell
>> andrew.bell.ia at gmail.com
>>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161017/d4455f0d/attachment.html>

From spencertparkin at gmail.com  Mon Oct 17 20:07:35 2016
From: spencertparkin at gmail.com (Spencer Parkin)
Date: Mon, 17 Oct 2016 18:07:35 -0600
Subject: [CMake] cmake doesn't find QtCore
Message-ID: <CAJb6k=GsKh82ZFG9LYnMM=rFxyY0ceS2L-_4A1g-Z+f1vzT4rA@mail.gmail.com>

Hi,

I'm trying to install PySide.  With "pip install PySide", I get the
warning...

CMake Warning at c:/Program Files
(x86)/Cmake/share/cmake-3.7/Modules/FindQt4.cmake:618 (message):
C:/Qt/4.8.5/bin/qmake.exe reported QT_INSTALL_LIBS as "C:/Qt/4.8.5/lib" but
QtCore could not be found there.  Qt is NOT installed correctly for the
target build environment.

...I, however, believe that Qt IS installed correctly.  I find QtCore4.lib
in the said directory.  I tried to decipher the code found in
FindQt4.cmake, but I don't know the cmake language.  "qmake -query
QT_INSTALL_LIBS" does indeed report the directory named above, and it's
full of Qt-licious libraries.

Later on I see...

Qt QTGUI library not found.
Qt QTXML library not found.
Qt QTCORE library not found.

...and the ultimate wammy...

CMake Error at ApiExtractor/CmakeLists.txt:82 (qt4_add_resources): Unknown
CMake command "qt4_add_resources".

So "shiboken" fails to configure.  But I'm hoping that the latter errors
are just a symptom of the initial warning above indicating that, oddly,
cmake can't locate my Qt libraries.

I'm at a complete loss.  I've wasted an entire day here at work on this one
issue.  Any help would be greatly appreciated.

--Sp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161017/2b48e74d/attachment.html>

From post at hendrik-sattler.de  Tue Oct 18 05:34:52 2016
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Tue, 18 Oct 2016 11:34:52 +0200
Subject: [CMake] cmake doesn't find QtCore
In-Reply-To: <CAJb6k=GsKh82ZFG9LYnMM=rFxyY0ceS2L-_4A1g-Z+f1vzT4rA@mail.gmail.com>
References: <CAJb6k=GsKh82ZFG9LYnMM=rFxyY0ceS2L-_4A1g-Z+f1vzT4rA@mail.gmail.com>
Message-ID: <53BFC66B-933C-4296-82AA-DD99331DC32D@hendrik-sattler.de>

Hi,

what is your compiler?

HS


Am 18. Oktober 2016 02:07:35 MESZ, schrieb Spencer Parkin <spencertparkin at gmail.com>:
>Hi,
>
>I'm trying to install PySide.  With "pip install PySide", I get the
>warning...
>
>CMake Warning at c:/Program Files
>(x86)/Cmake/share/cmake-3.7/Modules/FindQt4.cmake:618 (message):
>C:/Qt/4.8.5/bin/qmake.exe reported QT_INSTALL_LIBS as "C:/Qt/4.8.5/lib"
>but
>QtCore could not be found there.  Qt is NOT installed correctly for the
>target build environment.
>
>...I, however, believe that Qt IS installed correctly.  I find
>QtCore4.lib
>in the said directory.  I tried to decipher the code found in
>FindQt4.cmake, but I don't know the cmake language.  "qmake -query
>QT_INSTALL_LIBS" does indeed report the directory named above, and it's
>full of Qt-licious libraries.
>
>Later on I see...
>
>Qt QTGUI library not found.
>Qt QTXML library not found.
>Qt QTCORE library not found.
>
>...and the ultimate wammy...
>
>CMake Error at ApiExtractor/CmakeLists.txt:82 (qt4_add_resources):
>Unknown
>CMake command "qt4_add_resources".
>
>So "shiboken" fails to configure.  But I'm hoping that the latter
>errors
>are just a symptom of the initial warning above indicating that, oddly,
>cmake can't locate my Qt libraries.
>
>I'm at a complete loss.  I've wasted an entire day here at work on this
>one
>issue.  Any help would be greatly appreciated.
>
>--Sp
>
>
>------------------------------------------------------------------------

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

From christophe.trophime at lncmi.cnrs.fr  Tue Oct 18 07:47:45 2016
From: christophe.trophime at lncmi.cnrs.fr (Christophe Trophime)
Date: Tue, 18 Oct 2016 13:47:45 +0200 (CEST)
Subject: [CMake] cmake 3.6.2 FindHDF5.cmake trouble finding parallel version
In-Reply-To: <1916391665.3138500.1476789983391.JavaMail.zimbra@lncmi.cnrs.fr>
Message-ID: <1330689654.3143905.1476791265211.JavaMail.zimbra@lncmi.cnrs.fr>

Hi, 
I'm experiencing troubles with cmake 3.6.2 and FindHDF5.cmake module in Debian/Testing. 
I'm trying to build med-fichier and gmsh for instance. 



The main CMakeList.txt contains: 

find_package(HDF5 COMPONENTS C) 
MESSAGE("HDF5_C_INCLUDE_DIR=${HDF5_C_INCLUDE_DIR}") 
MESSAGE("HDF5_CXX_INCLUDE_DIR=${HDF5_CXX_INCLUDE_DIR}") 
MESSAGE("HDF5_INCLUDE_DIR=${HDF5_INCLUDE_DIR}") 
MESSAGE("HDF5_INCLUDE_DIRS=${HDF5_INCLUDE_DIRS}") 
MESSAGE("HDF5_LIBRARIES=${HDF5_LIBRARIES}") 
MESSAGE("HDF5_C_LIBRARIES=${HDF5_C_LIBRARIES}") 


For those two using something like cmake .. -DHDF5_PREFER_PARALLEL:BOOL=ON to force the use of the mpi version 
I end up with error like that: 



-- HDF5: Using hdf5 compiler wrapper to determine C configuration 
-- Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_INCLUDE_DIRS HDF5_HL_LIBRARIES) 
HDF5_C_INCLUDE_DIR=HDF5_C_INCLUDE_DIR-NOTFOUND 
HDF5_CXX_INCLUDE_DIR=HDF5_CXX_INCLUDE_DIR-NOTFOUND 
HDF5_INCLUDE_DIR= 
HDF5_INCLUDE_DIRS=HDF5_C_INCLUDE_DIR-NOTFOUND;HDF5_CXX_INCLUDE_DIR-NOTFOUND 
HDF5_LIBRARIES=/usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.so;/usr/lib/x86_64-linux-gnu/libsz.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so;HDF5_hdf5_LIBRARY-NOTFOUND;HDF5_hdf5_cpp_LIBRARY-NOTFOUND;HDF5_hdf5_LIBRARY-NOTFOUND 
HDF5_C_LIBRARIES=/usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.so;/usr/lib/x86_64-linux-gnu/libsz.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so;HDF5_hdf5_LIBRARY-NOTFOUND 
-- HDF5 not found 




whereas hdf5 is installed!! 


I also tried to see what happens in FindHDF5.cmake by printing some additionnal messages: 



-- HDF5: Using hdf5 compiler wrapper to determine C configuration 
HDF5_C_INCLUDE_DIRS = /usr/include/hdf5/openmpi;/usr/include/hdf5/openmpi 
HDF5_C_DEFINITIONS =-D_LARGEFILE64_SOURCE;-D_LARGEFILE_SOURCE;-D_FORTIFY_SOURCE=2;-D_LARGEFILE64_SOURCE;-D_LARGEFILE_SOURCE;-D_FORTIFY_SOURCE=2 
HDF5_C_LIBRARY_DIRS = /usr/lib/x86_64-linux-gnu/hdf5/openmpi 
HDF5_C_LIBRARY_NAMES = hdf5;sz;z;dl;m 
HDF5_C_HL_LIBRARY_NAMES = hdf5_hl 
HDF5_C_HL_LIBRARIES = /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5_hl.so 
HDF5_C_IS_PARALLEL=TRUE 
HDF5_IS_PARALLEL=FALSE 
CMake Warning at /usr/share/cmake-3.6/Modules/FindHDF5.cmake:613 (message): 
HDF5 found for language C is parallel but previously found language is not 
parallel. 
Call Stack (most recent call first): 
CMakeLists.txt:853 (find_package) 




It seems to me that HDF5_IS_PARALLEL is never set before... 

Is there a proper new way to find hdf5 with cmake? 
What is the problem with my actual way of doing it? 

Thanks for any help 
Best 

Christophe TROPHIME 
Research Engineer 

CNRS - LNCMI 
25, rue des Martyrs 
BP 166 
38042 GRENOBLE Cedex 9 
FRANCE 

Tel : +33 (0)4 76 88 90 02 
Fax : +33 (0) 4 76 88 10 01 
Office U 19 
M at il : christophe.trophime at lncmi.cnrs.fr 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161018/45077814/attachment-0001.html>

From Chris.Cralle at rsa.com  Tue Oct 18 10:32:01 2016
From: Chris.Cralle at rsa.com (Cralle, Chris)
Date: Tue, 18 Oct 2016 14:32:01 +0000
Subject: [CMake] DragNDrag hdiutil debug help
Message-ID: <028093C78A1D3C48892E556EAB0D51C1BE51AD38@MX307CL03.corp.emc.com>

cmake 3.6.2, osx 10.12
We've started to get this problem with DragNDrop, only in our Jenkins build job. Running manually or calling hdiutil directly works 100%.
It's only when cmake runs through the job does the problem happen. I've been through all the verbose/debug (even 'diskarbitrationd -d') I can but still don't have a clue what's causing the fault.

I need output from the hdiutil command at CPackDragNDropGenerator.cxx:258

I wish it was more like CPackOSXX11Generator/CPackPackageMakerGenerator which saves to hdiutilOutput.log
And as an added bonus if there was a CMake option to enable -debug on hdiutil, that would be awesome.

cmCPackDragNDropGenerator.cxx:258 Error executing:
/usr/bin/hdiutil create -ov -srcfolder "/Volumes/DRIVE1/xxx" -volname "xxxxx" -format UDRW "/Volumes/DRIVE1/xxx/build/_CPack_Packages/DragNDrop/temp.dmg"
cmCPackDragNDropGenerator.cxx:430 Error generating temporary disk image.
cmCPackGenerator.cxx:973 Problem compressing the directory
cpack.cxx:391 Error when generating package: newpackagexxx

Any tips or clues greatly appreciated

Chris Cralle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161018/d3bc1fb5/attachment.html>

From ay at numfum.com  Tue Oct 18 13:56:33 2016
From: ay at numfum.com (Andy Yelland)
Date: Tue, 18 Oct 2016 19:56:33 +0200
Subject: [CMake] Visual Studio generator, cross-compiling
Message-ID: <8ce02ccf-d0c1-5644-f4ff-7cd674905ece@numfum.com>

Hi there

I am trying to coax a Cmake generation of a Visual Studio project of our 
cross-platform product, that includes the PNaCl platform.  The MSBuild 
setup for PNaCl is a little bit fussy, and does not like the relative 
pathnames in <AdditionalDependencies>, that get produced when the 
product has target_link_libraries setup between the static libraries in 
the product.  For the sake of this mail I'll call the library project 
'LibProject', which as it's based on unix toolchain, will get the static 
lib created as libLibProject.a.  To be used as a command-line on the 
PNaCl cross-compiler, then it needs to get translated to -lLibProject  
(without the lib prefix, or the .a suffix).

So going into the Visual Studio generator for the EXE project, at 
present are the relative paths (will use Debug for this example): 
../LibProject/Debug/libLibProject.a  which gets added to the 
<AdditionalDependencies> tag in the .vcxproj

To make the PNaCl MSBuild extension work, then instead it needs to be:

  * <AdditionalDependencies>LibProject</AdditionalDependencies>
  * <AdditionalLibraryDirectories>../LibProject/Debug</AdditionalLibraryDirectories>

I am well aware that these get set by the cmake functions: 
target_link_libraries() and link_directories(), so feel this ought to be 
possible by Cmake script.

What I'm struggling with, is finding *a place* where I can:

  * Query all the libraries that have become dependent on a target (the
    input to the Generator).  As target_link_libraries cascade, so my
    EXE project does not know about all of its leaf libraries, so I'm
    not really sure if there is a target property with ALL the dependent
    static library projects)
  * Adjust this list, stripping: path, 'lib' and '.a'
  * Inserting link_directories (or the equivalent, presuming it's some
    target property now), corresponding to the relative paths that were
    stripped in the step above

All of this would need to happen, after we've finished setting up the 
target, but before the generator.  Ideally this would be something I 
defined in the ToolChain folder - but I can't think of any kind of 
callback in the CMake system.

I'm open to other suggestions, about how to setup this visual studio 
cross-compile.  While PNaCl + MSDev may be rare, I feel that 
cross-compiling for other unix systems with -l and -L library and path 
command-lines ought to have been done before with Visual Studio generators.

Thanks in advance


Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161018/2f9e77c8/attachment.html>

From parag at ionicsecurity.com  Tue Oct 18 14:59:46 2016
From: parag at ionicsecurity.com (Parag Chandra)
Date: Tue, 18 Oct 2016 18:59:46 +0000
Subject: [CMake] [EXTERNAL]:  Visual Studio generator, cross-compiling
In-Reply-To: <8ce02ccf-d0c1-5644-f4ff-7cd674905ece@numfum.com>
References: <8ce02ccf-d0c1-5644-f4ff-7cd674905ece@numfum.com>
Message-ID: <FBF0FE52-D233-4907-9962-377AEF88DC3F@ionic.com>

Hi Andy,

My build supports several operating systems, including NaCl. The way I solved this problem, essentially, is every place you would normally call target_link_libraries, you replace it with a call to LinkPossiblyPrebuiltLibraries, which is a macro I have defined like this:

macro (LinkPossiblyPrebuiltLibraries artifactName)
    foreach (nextLibrary ${ARGN})
        if (NACL AND (CMAKE_GENERATOR MATCHES "Visual Studio.*"))
            # CMake spits out -l<fully-qualified-path>, which throws off clang++ and results in
            # libraries that can't be found. So instead we explicitly add -l<libname> and
            # -L${LIBS_DIR}
            set_property (TARGET ${artifactName} APPEND_STRING PROPERTY LINK_FLAGS " -l${nextLibrary}")
            get_target_property (IsImported ${artifactName} "IMPORTED")
        else ()
            target_link_libraries (${artifactName} ${nextLibrary})
        endif ()
    endforeach ()
endmacro ()

Then separately I add in the link directory:

if (CMAKE_GENERATOR MATCHES "Visual Studio.*")
    link_directories ("${LIBS_DIR}/$(Configuration)/${CpuArchSubdir}")
else ()
    link_directories ("${NACL_SDK_ROOT}/lib/pnacl/${CMAKE_BUILD_TYPE}")
endif ()

There may very well be some mistakes in there, because I?ve simplified some things that aren?t pertinent to this discussion. I should also point out that I gave up on the Visual Studio NaCl toolchain somewhere around the pepper_35 days, because it became apparent that Google wasn?t putting much effort into keeping it a going concern when the equivalent Linux/MacOSX toolchains worked just fine. I guess things have improved since then?



Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309




From: CMake <cmake-bounces at cmake.org> on behalf of Andy Yelland <ay at numfum.com>
Date: Tuesday, October 18, 2016 at 1:56 PM
To: "cmake at cmake.org" <cmake at cmake.org>
Subject: [EXTERNAL]: [CMake] Visual Studio generator, cross-compiling

Hi there

I am trying to coax a Cmake generation of a Visual Studio project of our cross-platform product, that includes the PNaCl platform.  The MSBuild setup for PNaCl is a little bit fussy, and does not like the relative pathnames in <AdditionalDependencies>, that get produced when the product has target_link_libraries setup between the static libraries in the product.  For the sake of this mail I'll call the library project 'LibProject', which as it's based on unix toolchain, will get the static lib created as libLibProject.a.  To be used as a command-line on the PNaCl cross-compiler, then it needs to get translated to -lLibProject  (without the lib prefix, or the .a suffix).

So going into the Visual Studio generator for the EXE project, at present are the relative paths (will use Debug for this example):  ../LibProject/Debug/libLibProject.a  which gets added to the <AdditionalDependencies> tag in the .vcxproj

To make the PNaCl MSBuild extension work, then instead it needs to be:

  *   <AdditionalDependencies>LibProject</AdditionalDependencies>
  *   <AdditionalLibraryDirectories>../LibProject/Debug</AdditionalLibraryDirectories>

I am well aware that these get set by the cmake functions: target_link_libraries() and link_directories(), so feel this ought to be possible by Cmake script.

What I'm struggling with, is finding *a place* where I can:

  *   Query all the libraries that have become dependent on a target (the input to the Generator).  As target_link_libraries cascade, so my EXE project does not know about all of its leaf libraries, so I'm not really sure if there is a target property with ALL the dependent static library projects)
  *   Adjust this list, stripping: path, 'lib' and '.a'
  *   Inserting link_directories (or the equivalent, presuming it's some target property now), corresponding to the relative paths that were stripped in the step above

All of this would need to happen, after we've finished setting up the target, but before the generator.  Ideally this would be something I defined in the ToolChain folder - but I can't think of any kind of callback in the CMake system.

I'm open to other suggestions, about how to setup this visual studio cross-compile.  While PNaCl + MSDev may be rare, I feel that cross-compiling for other unix systems with -l and -L library and path command-lines ought to have been done before with Visual Studio generators.

Thanks in advance



Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161018/fa7bdd5f/attachment-0001.html>

From wangwei at comp.nus.edu.sg  Wed Oct 19 03:25:33 2016
From: wangwei at comp.nus.edu.sg (Wang Wei)
Date: Wed, 19 Oct 2016 15:25:33 +0800
Subject: [CMake] Cmake not using user configured lib for linking
Message-ID: <CAJz0iLuc17p-YJ6Aeb4eey7gWpkdYQ9KCr6vCHoykhfdAfC1vA@mail.gmail.com>

I am using cmake (3.5.0) to compile a C++ probject on Ubuntu 14.04, which
depends on Nvidia Cudnn. It seems that the cmake does not provide the
correct paths of cudnn to the linker although I have configured the paths.

File FindCUDNN.cmake:

FIND_PATH(CUDNN_INCLUDE_DIR NAME "cudnn.h" PATHS "$ENV{CMAKE_INCLUDE_PATH}")
FIND_LIBRARY(CUDNN_LIBRARIES NAME "libcudnn.so" PATHS
"$ENV{CMAKE_LIBRARY_PATH}")
INCLUDE(FindPackageHandleStandardArgs)
find_package_handle_standard_args(CUDNN DEFAULT_MSG CUDNN_INCLUDE_DIR
CUDNN_LIBRARIES)
MARK_AS_ADVANCED(CUDNN_INCLUDE_DIR CUDNN_LIBRARIES)

CMakeLists.txt:

FIND_PACKAGE(CUDNN REQUIRED)
LIST(APPEND LINKER_LIBS ${CUDNN_LIBRARIES})
...
ADD_LIBRARY(myobjects OBJECT ${mysources})
ADD_LIBRARY(mylib SHARED $<TARGET_OBJECTS:myobjects> ${cuda_objs})
TARGET_LINK_LIBRARIES(mylib ${LINKER_LIBS})

CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH are exported to the paths of cudnn5
in my home folder. After cmake .., the paths in CmakeCache.txt are set to
cudnn5. However, the linker (and link.txt) uses -lcudnn without paths to
cudnn5. Consequently, it links the cudnn4 in the system folder, i.e.
/usr/local/cuda/lib64.

Note: If there is no cudnn4 in my system folder, everything is fine. The
link.txt file and the output of make VERBOSE=1 use the absolute paths of
cudnn 5 during linking.


Thanks.

Wei.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161019/3501ecc4/attachment.html>

From james.turner at kdab.com  Wed Oct 19 05:44:58 2016
From: james.turner at kdab.com (James Turner)
Date: Wed, 19 Oct 2016 10:44:58 +0100
Subject: [CMake] Custom clang compiler unrecognised on OS-X
Message-ID: <84A72C7B-140D-4366-93F9-CCC076231CBA@kdab.com>

Some recent configuration change (either upgrading to Sierra or CMake 3.5.0) has prompted the following warning when running Cmake on a particular project:

================
CMake Error in xxxxxxxxxxxx/CMakeLists.txt:
  No known features for CXX compiler

  "Clang"

  version 3.5.0.
==============

This project uses a mixture of Fortran and C++ - the Fortran compiler is GFortran, and the C++ compiler is a custom clang with OpenMP support, supplied by Homebrew (as is CMake). I assume the error is somehow related to using a non-Apple Clang, but prior to upgrading either Xcode/the OS to Sierra/to Cmake 3.5, the message did not appear. (When I say ?custom?, it?s simply that Apple choose to disable OpenMP in their official builds shipped with Xcode, the compiler I?m using is the stock mainline clang with OpenMP support re-enabled)

The message is repeated for each CMakeList.txt in the project, and of course I?ve googled it, but can only find references to unsupported compilers, when this system was introduced. Is there an issue with my CmakeLists.txt files, or some missing configuration file in Cmake, or something else again happening?

Running ?-v? on the OpenMP clang from Homebrew reports:

=================
clang-omp -v
clang version 3.5.0 
Target: x86_64-apple-darwin16.0.0
Thread model: posix
===============

I run Cmake with a command like: (in my build dir)

CC=/usr/local/bin/clang-omp CXX=/usr/local/bin/clang-omp++  cmake ../my-project/

Any hints appreciated!

Kind regards,
James

--
James Turner - Senior Software Developer
KDAB - The Qt, C++ and OpenGL Experts




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3868 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161019/c20d92a8/attachment.bin>

From swetha.bsharma at gmail.com  Wed Oct 19 06:08:45 2016
From: swetha.bsharma at gmail.com (Swetha Sharma)
Date: Wed, 19 Oct 2016 15:38:45 +0530
Subject: [CMake] setting clrsupport VS2010
Message-ID: <CACDHZERbvFb+ANVzJ36tO7J7Puf9URFP2urmMcLx_s3w=XN8Yg@mail.gmail.com>

I am trying to create a managed c++ code , i want to thes clrsupport to be
true from cmake. Below is the script which  i have used

SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS "/clr")
 STRING(REPLACE "/EHsc" "/EHa" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
 STRING(REPLACE "/RTC1" "" CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG})
 SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /clr")

The problem I've found, is that while CMake sets the "Common Language
RunTime Support" option in the C/C++ section of the configuration properties
if "/clr" is in the CXX_FLAGS, it does not set the "Common Language RunTime
Support" in the general configuration properties, and that causes problems
with linking/.NET references.


How do I fix this issue?
-swetha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161019/ab57b5cb/attachment.html>

From brad.king at kitware.com  Wed Oct 19 08:58:11 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 19 Oct 2016 08:58:11 -0400
Subject: [CMake] DragNDrag hdiutil debug help
In-Reply-To: <028093C78A1D3C48892E556EAB0D51C1BE51AD38@MX307CL03.corp.emc.com>
References: <028093C78A1D3C48892E556EAB0D51C1BE51AD38@MX307CL03.corp.emc.com>
Message-ID: <7db5351b-d879-0c1b-f03c-6e38b15f7f66@kitware.com>

On 10/18/2016 10:32 AM, Cralle, Chris wrote:
> I need output from the hdiutil command at CPackDragNDropGenerator.cxx:258
> 
> I wish it was more like CPackOSXX11Generator/CPackPackageMakerGenerator
> which saves to hdiutilOutput.log

That sounds useful.  If you'd like to try adding it please see
CONTRIBUTING.rst at the top of our source tree in Git `master`.

> And as an added bonus if there was a CMake option to enable -debug on
> hdiutil, that would be awesome.

If all the output is captured to a log file is there any reason not to
just always add the -debug flag?

Thanks,
-Brad


From bballet at ivsweb.com  Wed Oct 19 09:04:25 2016
From: bballet at ivsweb.com (Benjamin Ballet)
Date: Wed, 19 Oct 2016 15:04:25 +0200
Subject: [CMake] setting clrsupport VS2010
In-Reply-To: <CACDHZERbvFb+ANVzJ36tO7J7Puf9URFP2urmMcLx_s3w=XN8Yg@mail.gmail.com>
References: <CACDHZERbvFb+ANVzJ36tO7J7Puf9URFP2urmMcLx_s3w=XN8Yg@mail.gmail.com>
Message-ID: <CAJoWGD0ruFgwjhr+Spi5=dDd8KGupBrXxiVo7XCZk3Zx4FBecw@mail.gmail.com>

Hi
here is all the property I had to set to produce C++/CLI (clr) targets with
cmake


    target_compile_options(${project_name} PRIVATE /clr)
    target_compile_options(${project_name} PRIVATE /fp:precise) #
/fp:strict is incompatible with /clr

    set_property(TARGET ${project_name} PROPERTY VS_GLOBAL_ROOTNAMESPACE
${project_name})

    set_property(TARGET ${project_name} PROPERTY VS_GLOBAL_KEYWORD
"ManagedCProj")

    set_property(TARGET ${project_name} PROPERTY VS_GLOBAL_CLRSupport
"true")

    set_property(TARGET ${project_name} PROPERTY
VS_DOTNET_TARGET_FRAMEWORK_VERSION "v4.0")

    set_property(TARGET ${project_name} PROPERTY VS_DOTNET_REFERENCES
"System" "System.Data" "System.Drawing" "System.Windows.Forms" "System.Xml")

    # Note: Modification of compiler flags is required for CLR
compatibility now that we are using .resx files.
    string(REPLACE "/EHsc" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
    string(REPLACE "/RTC1" "" CMAKE_CXX_FLAGS_DEBUG
"${CMAKE_CXX_FLAGS_DEBUG}")

2016-10-19 12:08 GMT+02:00 Swetha Sharma <swetha.bsharma at gmail.com>:

> I am trying to create a managed c++ code , i want to thes clrsupport to be
> true from cmake. Below is the script which  i have used
>
> SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS "/clr")
>  STRING(REPLACE "/EHsc" "/EHa" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
>  STRING(REPLACE "/RTC1" "" CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG})
>  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /clr")
>
> The problem I've found, is that while CMake sets the "Common Language
> RunTime Support" option in the C/C++ section of the configuration
> properties
> if "/clr" is in the CXX_FLAGS, it does not set the "Common Language RunTime
> Support" in the general configuration properties, and that causes problems
> with linking/.NET references.
>
>
> How do I fix this issue?
> -swetha
>
> --
>
> 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
>



-- 
*Benjamin BALLET*
Ing?nieur R&D

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard T?l* :  01 44 69 37 37
*>* www.activisu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161019/42308e12/attachment-0001.html>

From mellery451 at gmail.com  Wed Oct 19 11:03:53 2016
From: mellery451 at gmail.com (Michael Ellery)
Date: Wed, 19 Oct 2016 08:03:53 -0700
Subject: [CMake] Custom clang compiler unrecognised on OS-X
In-Reply-To: <84A72C7B-140D-4366-93F9-CCC076231CBA@kdab.com>
References: <84A72C7B-140D-4366-93F9-CCC076231CBA@kdab.com>
Message-ID: <FF46E220-4865-41A6-8BD7-FA9925B46390@gmail.com>

This is a complete stab in the dark, but I wonder if your clang (Xcode tools?) needs reactivation. I know some people have reported that they?ve needed to re-accept the license and/or reinstall the Xcode tools following the upgrade. Again, this is just a wild guess.


> On Oct 19, 2016, at 2:44 AM, James Turner <james.turner at kdab.com> wrote:
> 
> Some recent configuration change (either upgrading to Sierra or CMake 3.5.0) has prompted the following warning when running Cmake on a particular project:
> 
> ================
> CMake Error in xxxxxxxxxxxx/CMakeLists.txt:
>  No known features for CXX compiler
> 
>  "Clang"
> 
>  version 3.5.0.
> ==============
> 
> This project uses a mixture of Fortran and C++ - the Fortran compiler is GFortran, and the C++ compiler is a custom clang with OpenMP support, supplied by Homebrew (as is CMake). I assume the error is somehow related to using a non-Apple Clang, but prior to upgrading either Xcode/the OS to Sierra/to Cmake 3.5, the message did not appear. (When I say ?custom?, it?s simply that Apple choose to disable OpenMP in their official builds shipped with Xcode, the compiler I?m using is the stock mainline clang with OpenMP support re-enabled)
> 
> The message is repeated for each CMakeList.txt in the project, and of course I?ve googled it, but can only find references to unsupported compilers, when this system was introduced. Is there an issue with my CmakeLists.txt files, or some missing configuration file in Cmake, or something else again happening?
> 
> Running ?-v? on the OpenMP clang from Homebrew reports:
> 
> =================
> clang-omp -v
> clang version 3.5.0 
> Target: x86_64-apple-darwin16.0.0
> Thread model: posix
> ===============
> 
> I run Cmake with a command like: (in my build dir)
> 
> CC=/usr/local/bin/clang-omp CXX=/usr/local/bin/clang-omp++  cmake ../my-project/
> 
> Any hints appreciated!
> 
> Kind regards,
> James
> 
> --
> James Turner - Senior Software Developer
> KDAB - The Qt, C++ and OpenGL Experts
> 
> 
> 
> 
> -- 
> 
> 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


From Walter.Gunter at dematic.com  Wed Oct 19 12:57:49 2016
From: Walter.Gunter at dematic.com (Gunter, Walter E)
Date: Wed, 19 Oct 2016 16:57:49 +0000
Subject: [CMake] is it worth using cmake to cross-compile for embedded
 arm device?
In-Reply-To: <CANB0TnTJem5eRFaQm-SHg9zkwnB8UwvSexMz0f=0hg=W1sY6hQ@mail.gmail.com>
References: <DM5PR12MB181855901F44B35BCCEFE844EEF30@DM5PR12MB1818.namprd12.prod.outlook.com>
 <CANB0TnTJem5eRFaQm-SHg9zkwnB8UwvSexMz0f=0hg=W1sY6hQ@mail.gmail.com>
Message-ID: <CY4PR12MB181690642076BD400E468F3EEED20@CY4PR12MB1816.namprd12.prod.outlook.com>

The toolchain was a great suggestion.

I am still having problems, but at least I know I am using the right toolchain:
Currently, this is what I have for my toolchain:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(TOOLCHAIN_PATH /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi)

# where is the target environment
set(CMAKE_FIND_ROOT_PATH /opt/toolchains/arm-2008q3/arm-none-linux-gnueabi)

# specify the cross compiler
set(CMAKE_CXX_COMPILER /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-g++)
set(CMAKE_C_COMPILER /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-gcc)

#set(CMAKE_AR /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-ar)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

set(COMPILE_FLAGS "-lrt -Wall -lpthread")


I run cmake with the reference to that toolchain file, cmake ?DCMAKE_TOOLCHAIN_FILE=cmake/toolchain.cmake

I can see it finds the right toolchain and compilers.
Now I am having some issues where it is getting conflicted between using sys or linux headers?.
Is this just a header issue?

CMAKE question:  What is the difference between the two variables?
TOOLCHAIN_PATH
CMAKE_FIND_ROOT_PATH
Should they be the same reference location?

This is the folder structure at the /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi
/bin
/include
/lib
/libc

Thoughts?

Thanks!

From: dflogeras at gmail.com [mailto:dflogeras at gmail.com] On Behalf Of Dave Flogeras
Sent: Friday, September 16, 2016 5:43 PM
To: Gunter, Walter E
Subject: Re: [CMake] is it worth using cmake to cross-compile for embedded arm device?

I personally use cmake with multiple cross toolchains successfully.  I guess it depends on what you are trying to achieve.  I prefer it because I can use the same CMakeLists.txt to build natively on linux/mac/windows, as well as cross-compile against an embedded arm linux.  I'd also agree with the previous discussion about using a toolchain file for your platform, it does simplify things.

On Fri, Sep 16, 2016 at 5:26 PM, Gunter, Walter E <Walter.Gunter at dematic.com<mailto:Walter.Gunter at dematic.com>> wrote:
I am having some troubles getting cmake setup and wonder if cmake is the right tool.
Thoughts? Suggestions?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161019/ba626b1c/attachment.html>

From d3ck0r at gmail.com  Wed Oct 19 14:09:45 2016
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 19 Oct 2016 11:09:45 -0700
Subject: [CMake] is it worth using cmake to cross-compile for embedded
	arm device?
In-Reply-To: <CY4PR12MB181690642076BD400E468F3EEED20@CY4PR12MB1816.namprd12.prod.outlook.com>
References: <DM5PR12MB181855901F44B35BCCEFE844EEF30@DM5PR12MB1818.namprd12.prod.outlook.com>
 <CANB0TnTJem5eRFaQm-SHg9zkwnB8UwvSexMz0f=0hg=W1sY6hQ@mail.gmail.com>
 <CY4PR12MB181690642076BD400E468F3EEED20@CY4PR12MB1816.namprd12.prod.outlook.com>
Message-ID: <CAA2GJqVUWvn111h7YywLya3o3Yhp=i7mhLtYAg3nh0da6sm6KQ@mail.gmail.com>

to gcc you can pass --sysroot which will bias it's internal referenced
includes and libraries....

On Wed, Oct 19, 2016 at 9:57 AM, Gunter, Walter E <Walter.Gunter at dematic.com
> wrote:

> The toolchain was a great suggestion.
>
>
>
> I am still having problems, but at least I know I am using the right
> toolchain:
>
> Currently, this is what I have for my toolchain:
>
>
>
> set(CMAKE_SYSTEM_NAME Linux)
>
> set(CMAKE_SYSTEM_PROCESSOR arm)
>
> set(TOOLCHAIN_PATH /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi)
>
>
>
> # where is the target environment
>
> set(CMAKE_FIND_ROOT_PATH /opt/toolchains/arm-2008q3/
> arm-none-linux-gnueabi)
>
>
>
> # specify the cross compiler
>
> set(CMAKE_CXX_COMPILER /opt/toolchains/arm-2008q3/
> bin/arm-none-linux-gnueabi-g++)
>
> set(CMAKE_C_COMPILER /opt/toolchains/arm-2008q3/
> bin/arm-none-linux-gnueabi-gcc)
>
>
>
> #set(CMAKE_AR /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-ar)
>
>
>
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>
> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>
> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>
> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>
>
>
> set(COMPILE_FLAGS "-lrt -Wall -lpthread")
>
>
>
>
>
> I run cmake with the reference to that toolchain file, cmake
> ?DCMAKE_TOOLCHAIN_FILE=cmake/toolchain.cmake
>
>
>
> I can see it finds the right toolchain and compilers.
>
> Now I am having some issues where it is getting conflicted between using
> sys or linux headers?.
>
> Is this just a header issue?
>
>
>
> CMAKE question:  What is the difference between the two variables?
>
> TOOLCHAIN_PATH
>
> CMAKE_FIND_ROOT_PATH
>
> Should they be the same reference location?
>
>
> This is the folder structure at the /opt/toolchains/arm-2008q3/
> bin/arm-none-linux-gnueabi
>
> /bin
>
> /include
>
> /lib
>
> /libc
>
>
>
> Thoughts?
>
>
>
> Thanks!
>
>
>
> *From:* dflogeras at gmail.com [mailto:dflogeras at gmail.com] *On Behalf Of *Dave
> Flogeras
> *Sent:* Friday, September 16, 2016 5:43 PM
> *To:* Gunter, Walter E
> *Subject:* Re: [CMake] is it worth using cmake to cross-compile for
> embedded arm device?
>
>
>
> I personally use cmake with multiple cross toolchains successfully.  I
> guess it depends on what you are trying to achieve.  I prefer it because I
> can use the same CMakeLists.txt to build natively on linux/mac/windows, as
> well as cross-compile against an embedded arm linux.  I'd also agree with
> the previous discussion about using a toolchain file for your platform, it
> does simplify things.
>
>
>
> On Fri, Sep 16, 2016 at 5:26 PM, Gunter, Walter E <
> Walter.Gunter at dematic.com> wrote:
>
> I am having some troubles getting cmake setup and wonder if cmake is the
> right tool.
>
> Thoughts? Suggestions?
>
>
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161019/d2647d61/attachment-0001.html>

From Walter.Gunter at dematic.com  Wed Oct 19 15:32:15 2016
From: Walter.Gunter at dematic.com (Gunter, Walter E)
Date: Wed, 19 Oct 2016 19:32:15 +0000
Subject: [CMake] is it worth using cmake to cross-compile for embedded
 arm device?
In-Reply-To: <CAA2GJqVUWvn111h7YywLya3o3Yhp=i7mhLtYAg3nh0da6sm6KQ@mail.gmail.com>
References: <DM5PR12MB181855901F44B35BCCEFE844EEF30@DM5PR12MB1818.namprd12.prod.outlook.com>
 <CANB0TnTJem5eRFaQm-SHg9zkwnB8UwvSexMz0f=0hg=W1sY6hQ@mail.gmail.com>
 <CY4PR12MB181690642076BD400E468F3EEED20@CY4PR12MB1816.namprd12.prod.outlook.com>
 <CAA2GJqVUWvn111h7YywLya3o3Yhp=i7mhLtYAg3nh0da6sm6KQ@mail.gmail.com>
Message-ID: <CY4PR12MB18167714F55EF344A7EE8801EED20@CY4PR12MB1816.namprd12.prod.outlook.com>

Can I put that in my CMakeLists.txt?
Or would it be used on the command line when running cmake:

>Cmake ?DCMAKE_TOOLCHAIN_FILE=cmake/toolchain.cmake ?sysroot



From: J Decker [mailto:d3ck0r at gmail.com]
Sent: Wednesday, October 19, 2016 2:10 PM
To: Gunter, Walter E
Cc: Dave Flogeras; cmake at cmake.org
Subject: Re: [CMake] is it worth using cmake to cross-compile for embedded arm device?

to gcc you can pass --sysroot which will bias it's internal referenced includes and libraries....

On Wed, Oct 19, 2016 at 9:57 AM, Gunter, Walter E <Walter.Gunter at dematic.com<mailto:Walter.Gunter at dematic.com>> wrote:
The toolchain was a great suggestion.

I am still having problems, but at least I know I am using the right toolchain:
Currently, this is what I have for my toolchain:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(TOOLCHAIN_PATH /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi)

# where is the target environment
set(CMAKE_FIND_ROOT_PATH /opt/toolchains/arm-2008q3/arm-none-linux-gnueabi)

# specify the cross compiler
set(CMAKE_CXX_COMPILER /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-g++)
set(CMAKE_C_COMPILER /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-gcc)

#set(CMAKE_AR /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-ar)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

set(COMPILE_FLAGS "-lrt -Wall -lpthread")


I run cmake with the reference to that toolchain file, cmake ?DCMAKE_TOOLCHAIN_FILE=cmake/toolchain.cmake

I can see it finds the right toolchain and compilers.
Now I am having some issues where it is getting conflicted between using sys or linux headers?.
Is this just a header issue?

CMAKE question:  What is the difference between the two variables?
TOOLCHAIN_PATH
CMAKE_FIND_ROOT_PATH
Should they be the same reference location?

This is the folder structure at the /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi
/bin
/include
/lib
/libc

Thoughts?

Thanks!

From: dflogeras at gmail.com<mailto:dflogeras at gmail.com> [mailto:dflogeras at gmail.com<mailto:dflogeras at gmail.com>] On Behalf Of Dave Flogeras
Sent: Friday, September 16, 2016 5:43 PM
To: Gunter, Walter E
Subject: Re: [CMake] is it worth using cmake to cross-compile for embedded arm device?

I personally use cmake with multiple cross toolchains successfully.  I guess it depends on what you are trying to achieve.  I prefer it because I can use the same CMakeLists.txt to build natively on linux/mac/windows, as well as cross-compile against an embedded arm linux.  I'd also agree with the previous discussion about using a toolchain file for your platform, it does simplify things.

On Fri, Sep 16, 2016 at 5:26 PM, Gunter, Walter E <Walter.Gunter at dematic.com<mailto:Walter.Gunter at dematic.com>> wrote:
I am having some troubles getting cmake setup and wonder if cmake is the right tool.
Thoughts? Suggestions?


--

Powered by www.kitware.com<http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161019/53155c4e/attachment-0001.html>

From robert.maynard at kitware.com  Wed Oct 19 15:52:17 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 19 Oct 2016 15:52:17 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.7.0-rc2 now ready for testing!
Message-ID: <CAFzjYVppwCeLsfJBVdi4OJD2N4NFM-KR__veXVyQ4AP_0jESJw@mail.gmail.com>

I am proud to announce the second CMake 3.7 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.7

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.7/release/3.7.html

Some of the more significant changes in CMake 3.7 are:

* CMake now supports Cross Compiling for Android with simple
  toolchain files.

* The "Ninja" generator learned to conditionally support Fortran
  when using a "ninja" tool that has the necessary features. See
  generator documentation for details.

* The "if()" command gained new boolean comparison operations
  "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL",
  "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL".

* The "try_compile()" command source file signature now honors
  configuration-specific flags (e.g. "CMAKE_<LANG>_FLAGS_DEBUG") in
  the generated test project.  Previously only the default such flags
  for the current toolchain were used.  See policy "CMP0066".

* "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT",
  "CMAKE_SHARED_LINKER_FLAGS_INIT", and
  "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the
  "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and
  "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language
  is enabled in a build tree.

* CTest now supports test fixtures through the new "FIXTURES_SETUP",
  "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When
  using regular expressions or "--rerun-failed" to limit the tests to
  be run, a fixture's setup and cleanup tests will automatically be
  added to the execution set if any test requires that fixture.

* We no longer provide Linux i386 binaries for download from
  "cmake.org" for new versions of CMake.

* Vim support files "cmake-indent.vim", "cmake-syntax.vim", and
  "cmake-help.vim" have been removed in favor of the files now
  provided from the vim-cmake-syntax project.

* Support for building CMake itself with some compilers was dropped:

  * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above

  * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64

  CMake still supports generating build systems for other projects
  using these compilers.





CMake 3.7 Release Notes
***********************

Changes made since CMake 3.6 include the following.


New Features
============


Platforms
---------

* CMake now supports Cross Compiling for Android with simple
  toolchain files.

* The Clang compiler is now supported on AIX.


Generators
----------

* The "Ninja" generator learned to conditionally support Fortran
  when using a "ninja" tool that has the necessary features. See
  generator documentation for details.

* The "Ninja" generator learned to produce phony targets of the form
  "sub/dir/{test,install,package}" to drive the build of a
  subdirectory installation, test or packaging target. This is
  equivalent to "cd sub/dir; make {test,install,package}" with
  Makefile Generators.

* The "Visual Studio 15" generator was added.  This is experimental
  and based on Preview 4 because this version of VS has not been
  released.

* Visual Studio Generators for VS 2010 and above learned to place
  ".natvis" source files into VS project files properly.

* The "Xcode" generator's rudimentary Swift language support learned
  to honor a new "CMAKE_Swift_LANGUAGE_VERSION" variable to tell Xcode
  what version of Swift is used by the source.

* The "CodeLite" generator gained a new "CMAKE_CODELITE_USE_TARGETS"
  option to change project creation from projects to targets.


Commands
--------

* The "add_custom_command()" command gained a new "DEPFILE" option
  that works with the "Ninja" generator to provide implicit dependency
  information to the build tool.

* The "cmake_parse_arguments()" command gained a new "PARSE_ARGV"
  mode to read arguments directly from "ARGC" and "ARGV#" variables
  inside a "function()" body.

* The "export()" command gained an "ANDROID_MK" option to generate
  "Android.mk" files referencing CMake-built libraries as prebuilts
  for the Android NDK build system.

* The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained
  "HTTPHEADER <HTTP-header>" and "USERPWD <username>:<password>"
  options.

* The "find_library()" and "find_package()" commands learned to
  search in "lib32/" directories when the build targets a 32-bit
  architecture.  See the "FIND_LIBRARY_USE_LIB32_PATHS" global
  property.

* The "find_package()" command gained the possibility of sorting
  compatible libraries by "NAME" or by "NATURAL" sorting by setting
  the two new variables "CMAKE_FIND_PACKAGE_SORT_ORDER" and
  "CMAKE_FIND_PACKAGE_SORT_DIRECTION".

* The "if()" command gained new boolean comparison operations
  "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL",
  "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL".

* The "install()" command gained an "EXPORT_ANDROID_MK" subcommand
  to install "Android.mk" files referencing installed libraries as
  prebuilts for the Android NDK build system.

* The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained
  support for the "%a" and "%b" placeholders. These are the
  abbreviated weekday and month names.

* The "try_compile()" command source file signature now honors
  configuration-specific flags (e.g. "CMAKE_<LANG>_FLAGS_DEBUG") in
  the generated test project.  Previously only the default such flags
  for the current toolchain were used.  See policy "CMP0066".


Variables
---------

* Variable "CMAKE_FIND_PACKAGE_SORT_ORDER" was added to control the
  sorting mode of the "find_package()" command.

* Variable "CMAKE_FIND_PACKAGE_SORT_DIRECTION" was added to control
  the sorting direction the "find_package()" command.

* "Toolchain files" may now set a "CMAKE_<LANG>_FLAGS_INIT" variable
  to initialize the "CMAKE_<LANG>_FLAGS" cache entry the first time a
  language is enabled in a build tree.

* "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT",
  "CMAKE_SHARED_LINKER_FLAGS_INIT", and
  "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the
  "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and
  "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language
  is enabled in a build tree.


Properties
----------

* On Apple platforms the "BUNDLE_EXTENSION" target property now also
  applies to Frameworks and App Bundles.

* A "BINARY_DIR" directory property was added to get the absolute
  path to the binary directory corresponding to the source directory
  on which the property is read.

* A "BUILDSYSTEM_TARGETS" directory property was added to get the
  list of logical buildsystem target names added by the project in a
  directory.

* A "LINK_WHAT_YOU_USE" target property and supporting
  "CMAKE_LINK_WHAT_YOU_USE" variable were introduced to detect (on
  UNIX) shared libraries that are linked but not needed by running
  "ldd -r -u".

* A "SOURCE_DIR" directory property was added to get the absolute
  path to the source directory associated with a directory.

* A "SUBDIRECTORIES" directory property was added to get the list of
  subdirectories added by a project in a directory.

* A "VS_SDK_REFERENCES" target property was added to tell Visual
  Studio Generators to reference the named SDKs.

* A "VS_TOOL_OVERRIDE" source file property was created to tell
  Visual Studio Generators what tool to use for a source file.

* The "WINDOWS_EXPORT_ALL_SYMBOLS" target property now applies to
  executable targets with the "ENABLE_EXPORTS" property set.

* A "XCODE_FILE_ATTRIBUTES" source file property was added to tell
  the "Xcode" generator to generate custom content in the Xcode
  project attributes for the file.


Modules
-------

* An "AndroidTestUtilities" module was added to manage transfer of
  test data to an Android device.

* The "CheckFortranSourceCompiles" module macro
  "CHECK_Fortran_SOURCE_COMPILES" gained a "SRC_EXT" option to specify
  a custom test Fortran source file extension.

* The "ExternalProject" module gained "HTTP_USERNAME" and
  "HTTP_PASSWORD" options to set http download credentials.

* The "ExternalProject" module gained a "HTTP_HEADER" option to add
  http download headers.

* The "FindBISON" module "BISON_TARGET" macro learned a new
  "REPORT_FILE" option to specify the bison "--report-file=" option.

* The "FindBZip2" module now provides imported targets.

* A "FindICU" module was introduced to find the International
  Components for Unicode (ICU) libraries and programs.

* The "FindMatlab" module learned to find the SIMULINK and MAT components.

* The "FindMatlab" module "matlab_add_mex()" command learned to add
  executables and modules.

* The "FindMatlab" module "matlab_add_unit_test()" command learned
  to support inline Matlab test code.

* The "FindOpenCL" module now provides imported targets.

* The "FindOpenMP" module learned to detect the OpenMP version
  (specification date) from the compiler.

* A "FindVulkan" module was added.

* The "GenerateExportHeader" module learned a new
  "CUSTOM_CONTENT_FROM_VARIABLE" option to specify a variable
  containing custom content for inclusion in the generated header.

* The "GNUInstallDirs" module gained a new
  "GNUInstallDirs_get_absolute_install_dir()" command.

* The "UseJava" module gained APIs to "export" jar targets for use
  by external CMake projects.  See the "install_jar_exports" and
  "export_jars" functions.


CTest
-----

* CTest now supports test fixtures through the new "FIXTURES_SETUP",
  "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When
  using regular expressions or "--rerun-failed" to limit the tests to
  be run, a fixture's setup and cleanup tests will automatically be
  added to the execution set if any test requires that fixture.

* The "ctest_configure()", "ctest_build()", "ctest_test()",
  "ctest_coverage()", and "ctest_upload()" commands gained a new
  "CAPTURE_CMAKE_ERROR" option to capture any errors that occur as the
  commands run into a variable and avoid affecting the return code of
  the "ctest(1)" process.


CPack
-----

* CPack gained a "productbuild" generator on OS X, configured by the
  "CPackProductBuild" module.

* CPack gained a new "CPACK_PACKAGE_CHECKSUM" variable to enable
  generation of a checksum file for each package file.

* The "CPackDeb" module learned to support long file names when
  archive format is set to GNU tar. See "CPACK_DEBIAN_ARCHIVE_TYPE"

* The "CPackIFW" module gained a new
  "cpack_ifw_add_package_resources()" command to include additional
  resources in the installer binary.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands gained a new
  "USER_INTERFACES" option to add a list of additonal pages to the IFW
  installer.

* The "CPackRPM" module learned to generate debuginfo packages on
  demand. See "CPACK_RPM_DEBUGINFO_PACKAGE" and its per component
  version.

* The "CPackRPM" module learned to generate source rpm (SRPM)
  packages on demand. See "CPACK_RPM_PACKAGE_SOURCES",
  "CPACK_RPM_SOURCE_PKG_BUILD_PARAMS" and
  "CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX".

* The CPack NSIS generator now supports
  "CPACK_NSIS_<compName>_INSTALL_DIRECTORY". This can be used to set
  component specific installation directories.

* The CPack WIX generator now supports
  "CPACK_WIX_SKIP_PROGRAM_FOLDER" to allow specification of a custom
  absolute installation prefix outside of the ProgramFiles folders.

* The CPack WIX generator now supports
  "CPACK_COMPONENT_<compName>_DISABLED". This can be used to deselect
  a component from being installed by default.

* The CPack WIX generator now supports "CPACK_WIX_PATCH_FILE"
  fragments for Feature elements.

* The CPack WIX generator now supports
  "CPACK_WIX_ROOT_FEATURE_TITLE" and
  "CPACK_WIX_ROOT_FEATURE_DESCRIPTION" to allow the specification of a
  custom title and description for the root feature element.


Other
-----

* "cmake(1)" gained a "-E capabilities" option to provide a machine-
  readable (JSON) description of the capabilities of the cmake tool
  (available generators, etc.).

* A new "cmake-server(7)" mode was added to provide semantic
  information about a CMake-generated buildsystem to clients through a
  JSON protocol.  Currently all protocols are experimental and subject
  to change.

* The "cmake(1)" command learned a "--trace-source=<file>" option.

* "ccmake(1)" learned to support vim-like navigation bindings.

* "cmake-gui(1)" gained a button to open the generated project file
  for Visual Studio Generators and the "Xcode" generator.


Deprecated and Removed Features
===============================

* We no longer provide Linux i386 binaries for download from
  "cmake.org" for new versions of CMake.

* Vim support files "cmake-indent.vim", "cmake-syntax.vim", and
  "cmake-help.vim" have been removed in favor of the files now
  provided from the vim-cmake-syntax project.

* Support for building CMake itself with some compilers was dropped:

  * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above

  * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64

  CMake still supports generating build systems for other projects
  using these compilers.


Other Changes
=============

* The Fortran dependency scanner learned to support the syntax of
  Fortran Submodules.

* Vim support files "indent/cmake.vim" and "syntax/cmake.vim" from
  the vim-cmake-syntax project are now distributed with CMake.

----------------------------------------------------------------------------
Changes made since CMake 3.7.0-rc1:

Ben Boeckel (3):
      Ninja: Fix RC language depfile generation with cmcldeps
      ExternalProject: error out only if the property is unset
      ExternalProject: make SOURCE_SUBDIR directly appendable

Brad King (15):
      QtIFW: Reference cmake.org via https in cmake.org.html
      Android: Suppress -Wattributes warnings in test case builds
      Android: Update libc++ include directories for NDK r13
      Android: Fix support for cxxabi.h with libc++
      Android: Record use of C++ by static libs in exported Android.mk files
      VS: Split flag table between v140 and v141 toolsets
      cmake-gui: Fix "extra" generator entries in drop-down list
      Ninja: Fix POST_BUILD commands on macOS Frameworks
      Help: Clarify `ctest_*` APPEND option behavior
      Help: Fix math(EXPR) documentation formatting
      FindwxWidgets: Fix finding unversioned VS-built directory prefixes
      VS: Fix NVIDIA Nsight Tegra Visual Studio Edition support
      Tests: Fix VSNsightTegra test on Android NDK r12b
      Tests: Add VSNsightTegra test for VS 2015
      CMake 3.7.0-rc2

Chuck Atkins (2):
      Use find_package for JsonCpp and LibUV instead of include
      Set minimum version for LibUV to 1.0.0

Domen Vrankar (2):
      CPack/RPM debuginfo package objdump error suppression
      CPack/RPM debuginfo package without binaries

Gregor Jasny (1):
      OS X: Do not try to set deployment target when cross-compiling

Jamie Snape (1):
      Honor LINK_WHAT_YOU_USE when set to OFF

KWSys Upstream (1):
      KWSys 2016-10-07 (dfe9b386)

Martin Joly (1):
      FindProtobuf: Fix protobuf_generate_*() to handle subdirs

Max Smolens (1):
      ExternalProject: Fix regression in passing list to CMAKE_CACHE_ARGS

Raffi Enficiaud (3):
      FindMatlab: remove SIMULINK path from cache when FindMatlab is
      reconfigured
      FindMatlab: small documentation fixes
      Help: Extend 3.7 release notes for FindMatlab

Roger Leigh (1):
      FindIce: Add support for version 3.6.3

Roman W?ger (1):
      VS: Use absolute target-specific directory for `resources.pri`

Stephen Kelly (2):
      cmGlobalGenerator: Add API to get settings from top-level cmMakefile
      Codelite: Consume the CMAKE_CODELITE_USE_TARGETS setting globally

Tobias Hunger (2):
      server-mode: Improve shutdown behavior
      server-mode: Fix named pipe mode

From Walter.Gunter at dematic.com  Wed Oct 19 16:58:54 2016
From: Walter.Gunter at dematic.com (Gunter, Walter E)
Date: Wed, 19 Oct 2016 20:58:54 +0000
Subject: [CMake] is it worth using cmake finds toolchain,
 but cannot find PF_CAN - os it confused?
Message-ID: <CY4PR12MB1816481A685329134C835007EED20@CY4PR12MB1816.namprd12.prod.outlook.com>

Changing the subject line, since it is a great idea to use cmake.

Can I put that in my CMakeLists.txt?
Or would it be used on the command line when running cmake:

>Cmake ?DCMAKE_TOOLCHAIN_FILE=cmake/toolchain.cmake ?sysroot


I just tried it, and am still getting the error from make output.  If I put the linux/socket.h or sys/socket.h at the top of the #includes, I get the issues with variables already being defined, but don?t have get them when I put the #include for socket.h lower in the #include list:
For instance:

#include <cstdlib>
#include <stdio.h>
#include <cstring>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/stat.h>

#include <arpa/inet.h>
#include <netdb.h>
#include <netinet/in.h>
#include <unistd.h>
#include <pthread.h>
#include <assert.h>
#include <errno.h>
#include <iostream>

#include <sys/socket.h>  // i tried linux/socket.h and get some other errors, so I am confused.
#include <pthread.h>
#include <net/if.h>
#include <string.h>
#include <net/if.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <assert.h>
#include <linux/can.h>
#include <linux/can/raw.h>

This is the output?

error: 'PF_CAN' was not declared in this scope
error: 'AF_CAN' was not declared in this scope

That?s it..nothing else.

Walter

From: J Decker [mailto:d3ck0r at gmail.com]
Sent: Wednesday, October 19, 2016 2:10 PM
To: Gunter, Walter E
Cc: Dave Flogeras; cmake at cmake.org
Subject: Re: [CMake] is it worth using cmake to cross-compile for embedded arm device?

to gcc you can pass --sysroot which will bias it's internal referenced includes and libraries....

On Wed, Oct 19, 2016 at 9:57 AM, Gunter, Walter E <Walter.Gunter at dematic.com<mailto:Walter.Gunter at dematic.com>> wrote:
The toolchain was a great suggestion.

I am still having problems, but at least I know I am using the right toolchain:
Currently, this is what I have for my toolchain:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(TOOLCHAIN_PATH /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi)

# where is the target environment
set(CMAKE_FIND_ROOT_PATH /opt/toolchains/arm-2008q3/arm-none-linux-gnueabi)

# specify the cross compiler
set(CMAKE_CXX_COMPILER /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-g++)
set(CMAKE_C_COMPILER /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-gcc)

#set(CMAKE_AR /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-ar)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

set(COMPILE_FLAGS "-lrt -Wall -lpthread")


I run cmake with the reference to that toolchain file, cmake ?DCMAKE_TOOLCHAIN_FILE=cmake/toolchain.cmake

I can see it finds the right toolchain and compilers.
Now I am having some issues where it is getting conflicted between using sys or linux headers?.
Is this just a header issue?

CMAKE question:  What is the difference between the two variables?
TOOLCHAIN_PATH
CMAKE_FIND_ROOT_PATH
Should they be the same reference location?

This is the folder structure at the /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi
/bin
/include
/lib
/libc

Thoughts?

Thanks!

From: dflogeras at gmail.com<mailto:dflogeras at gmail.com> [mailto:dflogeras at gmail.com<mailto:dflogeras at gmail.com>] On Behalf Of Dave Flogeras
Sent: Friday, September 16, 2016 5:43 PM
To: Gunter, Walter E
Subject: Re: [CMake] is it worth using cmake to cross-compile for embedded arm device?

I personally use cmake with multiple cross toolchains successfully.  I guess it depends on what you are trying to achieve.  I prefer it because I can use the same CMakeLists.txt to build natively on linux/mac/windows, as well as cross-compile against an embedded arm linux.  I'd also agree with the previous discussion about using a toolchain file for your platform, it does simplify things.

On Fri, Sep 16, 2016 at 5:26 PM, Gunter, Walter E <Walter.Gunter at dematic.com<mailto:Walter.Gunter at dematic.com>> wrote:
I am having some troubles getting cmake setup and wonder if cmake is the right tool.
Thoughts? Suggestions?


--

Powered by www.kitware.com<http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161019/4889ff69/attachment-0001.html>

From lloydkl.tech at gmail.com  Thu Oct 20 02:38:14 2016
From: lloydkl.tech at gmail.com (Lloyd)
Date: Thu, 20 Oct 2016 12:08:14 +0530
Subject: [CMake] CTest verbose output of failed tests
Message-ID: <CAA10ZToVJfsHz-MqPF0atm=EyneyRpXVO1WVstkEfpjx5vdMQw@mail.gmail.com>

Hi,

We have integrated CMake and CTest and generates project in Visual Studio.
We run the tests from visual studio. When a test fails, it shows only the
message "test failed". CTest has a verbose option for knowing the details
about failed test. is it possible to integrate this verbose option in
visual studio so that I can know the details about the failed tests?

That is, how can I know the details about the failed tests from Visual
Studio?

Thanks,
  Lloyd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161020/f800a562/attachment.html>

From Dvir.Yitzchaki at ceva-dsp.com  Thu Oct 20 04:20:56 2016
From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki)
Date: Thu, 20 Oct 2016 08:20:56 +0000
Subject: [CMake] How to configure CMake to add current path to
	include	directive.
In-Reply-To: <CAE-NPOhAHM+DVbRpKBY1XaGsBtVH-Ywmm3+Lk-C-ZWDdoXRXFQ@mail.gmail.com>
References: <CAE-NPOj8EwxX_OidoiYn_x5zjEH_b9Tp_owMuobW9ZScXeWNbQ@mail.gmail.com>
 <CA+dygYkfTh-LRcXk0v4dLM_hC_qW8So9iAR6Nt7a4_U0Bmt_VA@mail.gmail.com>
 <CAE-NPOgtza0t-2df4F3coQsS9rtcBEk-1HEX334XnX4CO8Er5w@mail.gmail.com>
 <CA+dygYmtzCWVq=DAKvmOusdVNYr31A4SDsE7bYrLLcXcjV1EKA@mail.gmail.com>
 <CAE-NPOhAHM+DVbRpKBY1XaGsBtVH-Ywmm3+Lk-C-ZWDdoXRXFQ@mail.gmail.com>
Message-ID: <6ffb2eede5364384b4be7dd6a0d59ac6@ceva-dsp.com>

What about CMAKE_INCLUDE_CURRENT_DIR<https://cmake.org/cmake/help/latest/variable/CMAKE_INCLUDE_CURRENT_DIR.html>?

Regards,

Dvir
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Steve Lorimer
Sent: Monday, October 17, 2016 5:04 AM
To: Craig Scott <craig.scott at crascit.com>
Cc: CMake Mailing List <cmake at cmake.org>
Subject: Re: [CMake] How to configure CMake to add current path to include directive.

Thanks Craig

Looks like it did what you intended, but cmake won't allow it

CMake Error in foo/CMakeLists.txt:
  Found relative path while evaluating include directories of "foo":

    "."

Bummer! :(



On 16 October 2016 at 18:35, Craig Scott <craig.scott at crascit.com<mailto:craig.scott at crascit.com>> wrote:
Something like the following was what I had in mind (untested):

get_target_property(incDirs someTarget INCLUDE_DIRECTORIES)
list(APPEND incDirs .)
set_target_properties(someTarget PROPERTIES INCLUDE_DIRECTORIES "${incDirs}")


On Mon, Oct 17, 2016 at 10:31 AM, Steve Lorimer <steve.lorimer at gmail.com<mailto:steve.lorimer at gmail.com>> wrote:
Thanks Craig

Not sure if I'm doing it right, but I couldn't get that to work.

Would you be able to give me an example please?

Thanks
Steve



On 16 October 2016 at 17:51, Craig Scott <craig.scott at crascit.com<mailto:craig.scott at crascit.com>> wrote:
I think if you manipulate the target property INCLUDE_DIRECTORIES<https://cmake.org/cmake/help/latest/prop_tgt/INCLUDE_DIRECTORIES.html> directly, you should be able to force a "." in there without having it substituted for an absolute path. By this I mean use set_property() or set_target_properties() rather than target_include_directories() or include_directories(). Note, however, that the documentation for the INCLUDE_DIRECTORIES property explicitly recommends against adding relative paths to the property like this (but in your case it sounds like you really want a relative path, so maybe this is a valid exception to that advice).



On Mon, Oct 17, 2016 at 9:46 AM, Steve Lorimer <steve.lorimer at gmail.com<mailto:steve.lorimer at gmail.com>> wrote:
In makefile parlance, I'm trying to add -I. (ie: the current directory) to my include paths

I tried the following:

include_directories(".")

This doesn't work unfortunately, as relative paths are interpreted as relative to the current source directory<https://cmake.org/cmake/help/v3.0/command/include_directories.html>

That is, if this statement is in my top level CMakeLists.txt, located in ~/src/project, the include directive added will be "-I ~/src/project/.", whereas I'm trying to add "-I ."

The reason for my wanting this is that we have sources for a single library in several subdirs.

include_directories(${CMAKE_CURRENT_SOURCE_DIR})

add_library(
foo
STATIC
foo.cpp
bar/bar.cpp
)

In bar/bar.cpp, I have a relative include

#include "../foo.h"

With the above setup, this will fail to compile as only ~/src/project/foo will be added to the include paths.

I'm aware that if I explicitly added the path it would work

include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)

However, if there is a way to get -I. added to my include path, that's what I'm after.

TIA
Steve


--

Powered by www.kitware.com<http://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



--
Craig Scott
Melbourne, Australia
https://crascit.com




--
Craig Scott
Melbourne, Australia
https://crascit.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161020/641fc648/attachment-0001.html>

From swetha.bsharma at gmail.com  Thu Oct 20 05:26:46 2016
From: swetha.bsharma at gmail.com (Swetha Sharma)
Date: Thu, 20 Oct 2016 14:56:46 +0530
Subject: [CMake] strong name keyfile for c#project with cmake
Message-ID: <CACDHZET30matXNiUzx+UDez9jZyTzZ8bZnyJMf3XhX+goa7CWQ@mail.gmail.com>

How to include a strong name keyfile to c++/cli project with cmakelists
-swetha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161020/8055a23a/attachment.html>

From steve.lorimer at gmail.com  Thu Oct 20 10:10:21 2016
From: steve.lorimer at gmail.com (Steve Lorimer)
Date: Thu, 20 Oct 2016 09:10:21 -0500
Subject: [CMake] How to configure CMake to add current path to include
	directive.
In-Reply-To: <6ffb2eede5364384b4be7dd6a0d59ac6@ceva-dsp.com>
References: <CAE-NPOj8EwxX_OidoiYn_x5zjEH_b9Tp_owMuobW9ZScXeWNbQ@mail.gmail.com>
 <CA+dygYkfTh-LRcXk0v4dLM_hC_qW8So9iAR6Nt7a4_U0Bmt_VA@mail.gmail.com>
 <CAE-NPOgtza0t-2df4F3coQsS9rtcBEk-1HEX334XnX4CO8Er5w@mail.gmail.com>
 <CA+dygYmtzCWVq=DAKvmOusdVNYr31A4SDsE7bYrLLcXcjV1EKA@mail.gmail.com>
 <CAE-NPOhAHM+DVbRpKBY1XaGsBtVH-Ywmm3+Lk-C-ZWDdoXRXFQ@mail.gmail.com>
 <6ffb2eede5364384b4be7dd6a0d59ac6@ceva-dsp.com>
Message-ID: <CAE-NPOgwwUUv5tku-W2S=LZXsWuw6LyFq2OCO1dX9hzF0nAmdw@mail.gmail.com>

Hi Dvir

Thanks for the suggestion. I tried CMAKE_INCLUDE_CURRENT_DIR
<https://cmake.org/cmake/help/latest/variable/CMAKE_INCLUDE_CURRENT_DIR.html>,
but I couldn't get it to work using that.

In the end I looped over the sources added to my target, extracted the
directories using get_filename_component, and then added them with
target_include_directories.

set(DIR_LIST)
foreach(FILE ${ARG_SRCS})
get_filename_component(ABS_FILE ${FILE}     ABSOLUTE)
get_filename_component(DIR      ${ABS_FILE} DIRECTORY)
add_unique(${DIR} DIR_LIST)                              # does a
list(FIND...) and if not found, list(APPEND...)
endforeach()

target_include_directories(${ARG_NAME} PRIVATE ${DIR_LIST})

I can't believe it's necessary to do this, and there must be a better way,
but it worked for me, so I moved on.

Thanks
Steve


On 20 October 2016 at 03:20, Dvir Yitzchaki <Dvir.Yitzchaki at ceva-dsp.com>
wrote:

> What about CMAKE_INCLUDE_CURRENT_DIR
> <https://cmake.org/cmake/help/latest/variable/CMAKE_INCLUDE_CURRENT_DIR.html>
> ?
>
>
>
> Regards,
>
>
>
> Dvir
>
> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Steve
> Lorimer
> *Sent:* Monday, October 17, 2016 5:04 AM
> *To:* Craig Scott <craig.scott at crascit.com>
> *Cc:* CMake Mailing List <cmake at cmake.org>
> *Subject:* Re: [CMake] How to configure CMake to add current path to
> include directive.
>
>
>
> Thanks Craig
>
>
>
> Looks like it did what you intended, but cmake won't allow it
>
>
>
> CMake Error in foo/CMakeLists.txt:
>
>   Found relative path while evaluating include directories of "foo":
>
>
>
>     "."
>
>
>
> Bummer! :(
>
>
>
>
>
>
>
> On 16 October 2016 at 18:35, Craig Scott <craig.scott at crascit.com> wrote:
>
> Something like the following was what I had in mind (untested):
>
>
>
> get_target_property(incDirs someTarget INCLUDE_DIRECTORIES)
>
> list(APPEND incDirs .)
>
> set_target_properties(someTarget PROPERTIES INCLUDE_DIRECTORIES
> "${incDirs}")
>
>
>
>
>
> On Mon, Oct 17, 2016 at 10:31 AM, Steve Lorimer <steve.lorimer at gmail.com>
> wrote:
>
> Thanks Craig
>
>
>
> Not sure if I'm doing it right, but I couldn't get that to work.
>
>
>
> Would you be able to give me an example please?
>
>
>
> Thanks
>
> Steve
>
>
>
>
>
>
>
> On 16 October 2016 at 17:51, Craig Scott <craig.scott at crascit.com> wrote:
>
> I think if you manipulate the target property INCLUDE_DIRECTORIES
> <https://cmake.org/cmake/help/latest/prop_tgt/INCLUDE_DIRECTORIES.html>
> directly, you should be able to force a "." in there without having it
> substituted for an absolute path. By this I mean use set_property() or
> set_target_properties() rather than target_include_directories() or
> include_directories(). Note, however, that the documentation for the
> INCLUDE_DIRECTORIES property explicitly recommends against adding relative
> paths to the property like this (but in your case it sounds like you really
> want a relative path, so maybe this is a valid exception to that advice).
>
>
>
>
>
>
>
> On Mon, Oct 17, 2016 at 9:46 AM, Steve Lorimer <steve.lorimer at gmail.com>
> wrote:
>
> In makefile parlance, I'm trying to add -I. (ie: the current directory) to
> my include paths
>
>
>
> I tried the following:
>
>
>
> include_directories(".")
>
>
>
> This doesn't work unfortunately, as relative paths are interpreted as
> relative to the current source directory
> <https://cmake.org/cmake/help/v3.0/command/include_directories.html>
>
>
>
> That is, if this statement is in my top level CMakeLists.txt, located in
> ~/src/project, the include directive added will be "-I ~/src/project/.",
> whereas I'm trying to add "-I ."
>
>
>
> The reason for my wanting this is that we have sources for a single
> library in several subdirs.
>
>
>
> include_directories(${CMAKE_CURRENT_SOURCE_DIR})
>
>
>
> add_library(
>
> foo
>
> STATIC
>
> foo.cpp
>
> bar/bar.cpp
>
> )
>
>
>
> In bar/bar.cpp, I have a relative include
>
>
>
> #include "../foo.h"
>
>
>
> With the above setup, this will fail to compile as only ~/src/project/foo
> will be added to the include paths.
>
>
>
> I'm aware that if I explicitly added the path it would work
>
>
>
> include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)
>
>
>
> However, if there is a way to get -I. added to my include path, that's
> what I'm after.
>
>
>
> TIA
>
> Steve
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>
>
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161020/3684a754/attachment.html>

From irwin at beluga.phys.uvic.ca  Thu Oct 20 13:40:11 2016
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Thu, 20 Oct 2016 10:40:11 -0700 (PDT)
Subject: [CMake] Cannot get automoc to work properly with recommended
 Qt5 support method
In-Reply-To: <alpine.DEB.2.11.1610162136040.1243@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1610161252300.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610161738430.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610162136040.1243@enira.zlyna.ubzr>
Message-ID: <alpine.DEB.2.11.1610201018160.1243@enira.zlyna.ubzr>

Since I have gotten no response to my posts with this subject line, I
assume automoc really is currently unsuitable for the case where the
header that should be processed by moc is located in a different
source-tree directory than the source file that includes that header.
I temporarily worked around that issue with symlinks, but I then
discovered that qt5_wrap_cpp produces exactly the same results as
automoc (except for the identification of the header in its actual
location as opposed to the symlink) and with no need for symlinks.  So
I have abandoned automoc and used a custom target that invokes
qt5_wrap_cpp instead, and that has allowed me to complete my update to
the PLplot build system so that it replaces qt5_use_modules calls with
the modern recommended target_link_libraries method of setting up use
of Qt5.  And this change has also solved the issue of conflicts
between plain and keyworded target_link_libraries calls that occurred
with the qt5_use_modules based method.  So I am now satisfied with the
PLplot build-system update, but I think automoc would be preferable to
custom targets involving qt5_wrap_cpp if the above deficiency with
automoc could be solved, so I will be pursuing that question further
on the cmake-devel list.

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
__________________________

From steve.lorimer at gmail.com  Thu Oct 20 14:48:41 2016
From: steve.lorimer at gmail.com (Steve Lorimer)
Date: Thu, 20 Oct 2016 13:48:41 -0500
Subject: [CMake] Cannot get automoc to work properly with recommended
 Qt5 support method
In-Reply-To: <alpine.DEB.2.11.1610201018160.1243@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1610161252300.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610161738430.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610162136040.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610201018160.1243@enira.zlyna.ubzr>
Message-ID: <CAE-NPOgcDmEw9xQY0yM531C3XtMHfuJK-2U+TUt-miJut0btRw@mail.gmail.com>

Sounds like you have ended up at the same solution I did. I had trouble
getting the automated qt generation working, and in the end I made it
explicit

if(ARG_MOC)
qt5_wrap_cpp(MOC_OUT ${ARG_MOC})
endif()
if(ARG_RES)
qt5_add_resources(RES_OUT ${ARG_RES})
endif()
if(ARG_UI)
qt5_wrap_ui(UI_OUT ${ARG_UI})
endif()

add_library(
${ARG_NAME}
${LINK}
${ARG_SRCS} ${MOC_OUT} ${RES_OUT} ${UI_OUT}
)


On 20 October 2016 at 12:40, Alan W. Irwin <irwin at beluga.phys.uvic.ca>
wrote:

> Since I have gotten no response to my posts with this subject line, I
> assume automoc really is currently unsuitable for the case where the
> header that should be processed by moc is located in a different
> source-tree directory than the source file that includes that header.
> I temporarily worked around that issue with symlinks, but I then
> discovered that qt5_wrap_cpp produces exactly the same results as
> automoc (except for the identification of the header in its actual
> location as opposed to the symlink) and with no need for symlinks.  So
> I have abandoned automoc and used a custom target that invokes
> qt5_wrap_cpp instead, and that has allowed me to complete my update to
> the PLplot build system so that it replaces qt5_use_modules calls with
> the modern recommended target_link_libraries method of setting up use
> of Qt5.  And this change has also solved the issue of conflicts
> between plain and keyworded target_link_libraries calls that occurred
> with the qt5_use_modules based method.  So I am now satisfied with the
> PLplot build-system update, but I think automoc would be preferable to
> custom targets involving qt5_wrap_cpp if the above deficiency with
> automoc could be solved, so I will be pursuing that question further
> on the cmake-devel list.
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161020/2530f780/attachment.html>

From homerocda at gmail.com  Thu Oct 20 14:56:16 2016
From: homerocda at gmail.com (Homero Cardoso de Almeida)
Date: Thu, 20 Oct 2016 18:56:16 +0000
Subject: [CMake] FindProtobuf in specified dirs
Message-ID: <CAPv0ZwpN8B5xysJvD9O2gboOFy4vNSDBtLqWgK9ftyDyPJ+QeA@mail.gmail.com>

Hello,

I'm working on enhancing the build process in my company by using CMake,
and I'm having trouble to have it find the Google Protocol Buffers binary
and libraries in a specific directory in my workspace.

Due to several reasons, we cannot install protobuffers directly in our
environment, so I have it download and unpack a zip file with the
protobuffer library and header files in a directory in my home folder.
However, when I use the find_package directive giving said folder as a hint
it complains that it could not find a protobuf-config.cmake file and fails.
I couldn't find any such file anywhere, the only thing coming close is a "
protobuf-config.cmake.in" in the protobuf source tree and I don't know if I
can use that.

Do I have to provide my own protobuf-config.cmake file, or I'm using it
completely wrong?

We are frozen in protocol buffers 2.4.1. I guess we can upgrade to 2.7.0,
but we can't use 3.0.x.

Thanks,
Homero.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161020/d0356d40/attachment.html>

From parag at ionicsecurity.com  Thu Oct 20 15:05:20 2016
From: parag at ionicsecurity.com (Parag Chandra)
Date: Thu, 20 Oct 2016 19:05:20 +0000
Subject: [CMake] [EXTERNAL]:  FindProtobuf in specified dirs
In-Reply-To: <CAPv0ZwpN8B5xysJvD9O2gboOFy4vNSDBtLqWgK9ftyDyPJ+QeA@mail.gmail.com>
References: <CAPv0ZwpN8B5xysJvD9O2gboOFy4vNSDBtLqWgK9ftyDyPJ+QeA@mail.gmail.com>
Message-ID: <6C609AD4-4546-4943-BEA0-BDBA8015A6B2@ionic.com>

I believe the protobuf-config.cmake.in generates a protobuf-config.cmake file once you actually use CMake to build protobuf itself.



Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309




From: CMake <cmake-bounces at cmake.org> on behalf of Homero Cardoso de Almeida <homerocda at gmail.com>
Date: Thursday, October 20, 2016 at 2:56 PM
To: "cmake at cmake.org" <cmake at cmake.org>
Subject: [EXTERNAL]: [CMake] FindProtobuf in specified dirs

Hello,

I'm working on enhancing the build process in my company by using CMake, and I'm having trouble to have it find the Google Protocol Buffers binary and libraries in a specific directory in my workspace.

Due to several reasons, we cannot install protobuffers directly in our environment, so I have it download and unpack a zip file with the protobuffer library and header files in a directory in my home folder. However, when I use the find_package directive giving said folder as a hint it complains that it could not find a protobuf-config.cmake file and fails. I couldn't find any such file anywhere, the only thing coming close is a "protobuf-config.cmake.in<http://protobuf-config.cmake.in>" in the protobuf source tree and I don't know if I can use that.

Do I have to provide my own protobuf-config.cmake file, or I'm using it completely wrong?

We are frozen in protocol buffers 2.4.1. I guess we can upgrade to 2.7.0, but we can't use 3.0.x.

Thanks,
Homero.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161020/aca3f934/attachment-0001.html>

From irwin at beluga.phys.uvic.ca  Thu Oct 20 15:27:13 2016
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Thu, 20 Oct 2016 12:27:13 -0700 (PDT)
Subject: [CMake] Cannot get automoc to work properly with recommended
 Qt5 support method
In-Reply-To: <CAE-NPOgcDmEw9xQY0yM531C3XtMHfuJK-2U+TUt-miJut0btRw@mail.gmail.com>
References: <alpine.DEB.2.11.1610161252300.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610161738430.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610162136040.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610201018160.1243@enira.zlyna.ubzr>
 <CAE-NPOgcDmEw9xQY0yM531C3XtMHfuJK-2U+TUt-miJut0btRw@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1610201203110.1243@enira.zlyna.ubzr>

On 2016-10-20 13:48-0500 Steve Lorimer wrote:

> Sounds like you have ended up at the same solution I did. I had trouble
> getting the automated qt generation working, and in the end I made it
> explicit
>
> if(ARG_MOC)
> qt5_wrap_cpp(MOC_OUT ${ARG_MOC})
> endif()
> if(ARG_RES)
> qt5_add_resources(RES_OUT ${ARG_RES})
> endif()
> if(ARG_UI)
> qt5_wrap_ui(UI_OUT ${ARG_UI})
> endif()
>
> add_library(
> ${ARG_NAME}
> ${LINK}
> ${ARG_SRCS} ${MOC_OUT} ${RES_OUT} ${UI_OUT}
> )

Hi Steve:

Thanks for your additional comment.

Yes, I agree explicit is always a good fallback when automatic doesn't
work, but I am hoping the indirect result of this discussion is the
CMake developers will remove the limitations and deficiencies of the
automatic methods supporting Qt5 so they are a lot more useful for
complex real-world software projects.

One especially useful thing I realized from your post is my current
use of a custom_target that depends on MOC_OUT (in your above
nomenclature) is essentially a no-op since MOC_OUT is generated at
CMake time rather then set up as a custom command to be run at build
time.  So there is more cleanup I need to do of my explicit method.

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
__________________________

From irwin at beluga.phys.uvic.ca  Thu Oct 20 20:24:46 2016
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Thu, 20 Oct 2016 17:24:46 -0700 (PDT)
Subject: [CMake] Cannot get automoc to work properly with recommended
 Qt5 support method
In-Reply-To: <alpine.DEB.2.11.1610201203110.1243@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1610161252300.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610161738430.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610162136040.1243@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1610201018160.1243@enira.zlyna.ubzr>
 <CAE-NPOgcDmEw9xQY0yM531C3XtMHfuJK-2U+TUt-miJut0btRw@mail.gmail.com>
 <alpine.DEB.2.11.1610201203110.1243@enira.zlyna.ubzr>
Message-ID: <alpine.DEB.2.11.1610201714150.1243@enira.zlyna.ubzr>

On 2016-10-20 12:27-0700 Alan W. Irwin wrote:

> One especially useful thing I realized from your post is my current
> use of a custom_target that depends on MOC_OUT (in your above
> nomenclature) is essentially a no-op since MOC_OUT is generated at
> CMake time rather then set up as a custom command to be run at build
> time.  So there is more cleanup I need to do of my explicit method.

Oops.  That comment is not correct.  If you look at the qt5_wrap_cpp
macro source (in my case in
/usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreMacros.cmake as
packaged by Debian Jessie), it creates a custom command.  So creating
a custom target (like I do in the PLplot build system) that DEPENDS on
MOC_OUT is completely appropriate.  However, that working direct
method is somewhat convoluted so I hope the issue with automoc failing
when the header is in a separate directory is solved in the future.
(See my recent cmake-devel thread where I have given a minimal example
of this sort of automoc failure for the cmake developers to ponder.
That example also has an option to use the direct qt5_wrap_cpp method
with custom target instead of automoc.  That option compiles the
example without problems but the automoc option fails to compile).

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
__________________________

From tiagomacarios at gmail.com  Mon Oct 24 18:42:19 2016
From: tiagomacarios at gmail.com (Tiago Macarios)
Date: Mon, 24 Oct 2016 15:42:19 -0700
Subject: [CMake] CMAKE_INCLUDE_CURRENT_DIR on a function
Message-ID: <CAKLVFYFp9J1QKOPTA=q=XaqA+mBPu2Zveb-LsBQ0FCoMLKCxHg@mail.gmail.com>

Hi,

Does CMAKE_INCLUDE_CURRENT_DIR need to be set outside of a function?

I have a function where I define an executable "add_executable". This
executable uses moc'ed Qt clasees, so I need to set
CMAKE_INCLUDE_CURRENT_DIR. It seems like I have to set it from the top
level script calling the function. If I set it inside the function the
compilation fails with a missing moc file.

Any ideas?

Tiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161024/260be9e9/attachment.html>

From craig.scott at crascit.com  Mon Oct 24 18:48:00 2016
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 25 Oct 2016 09:48:00 +1100
Subject: [CMake] CMAKE_INCLUDE_CURRENT_DIR on a function
In-Reply-To: <CAKLVFYFp9J1QKOPTA=q=XaqA+mBPu2Zveb-LsBQ0FCoMLKCxHg@mail.gmail.com>
References: <CAKLVFYFp9J1QKOPTA=q=XaqA+mBPu2Zveb-LsBQ0FCoMLKCxHg@mail.gmail.com>
Message-ID: <CA+dygY=UXNmGcZLxW56WtFZxp-Mph1+6yaXLE06gXq9FB8ZwVw@mail.gmail.com>

function() introduces a new scope, so if you want changes you make to
variables inside the function to be visible outside the function, you need
to use set(... PARENT_SCOPE). Alternatively, a macro() does not introduce a
new scope, so replacing your function() with a macro() may also yield the
behaviour you want (but changing to a macro has other effects, so make sure
you read the docs before going down that path). Also note that setting it
in one directory does not make it apply to subdirectories as well, in case
that matters in your situation.



On Tue, Oct 25, 2016 at 9:42 AM, Tiago Macarios <tiagomacarios at gmail.com>
wrote:

> Hi,
>
> Does CMAKE_INCLUDE_CURRENT_DIR need to be set outside of a function?
>
> I have a function where I define an executable "add_executable". This
> executable uses moc'ed Qt clasees, so I need to set
> CMAKE_INCLUDE_CURRENT_DIR. It seems like I have to set it from the top
> level script calling the function. If I set it inside the function the
> compilation fails with a missing moc file.
>
> Any ideas?
>
> Tiago
>
> --
>
> 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
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/a28ace5b/attachment.html>

From tiagomacarios at gmail.com  Mon Oct 24 18:55:05 2016
From: tiagomacarios at gmail.com (Tiago Macarios)
Date: Mon, 24 Oct 2016 15:55:05 -0700
Subject: [CMake] CMAKE_INCLUDE_CURRENT_DIR on a function
In-Reply-To: <CA+dygY=UXNmGcZLxW56WtFZxp-Mph1+6yaXLE06gXq9FB8ZwVw@mail.gmail.com>
References: <CAKLVFYFp9J1QKOPTA=q=XaqA+mBPu2Zveb-LsBQ0FCoMLKCxHg@mail.gmail.com>
 <CA+dygY=UXNmGcZLxW56WtFZxp-Mph1+6yaXLE06gXq9FB8ZwVw@mail.gmail.com>
Message-ID: <CAKLVFYGORSvFc2dqCCfYGz7eoOMZyo+0HScFtCY35PZx4QNPjg@mail.gmail.com>

Hi Craig,

Maybe my problem description was lacking. Below is the function I have.
Both CMAKE_INCLUDE_CURRENT_DIR and the target are defined on the same
function scope, but this does not seem to work. I need to define
CMAKE_INCLUDE_CURRENT_DIR on the parent CMakeLists file.

function(AddTest)
    set(options)
    set(oneValueArgs FILE FOLDER)
    set(multiValueArgs LIBRARIES)
    cmake_parse_arguments(TEST
        "${options}"
        "${oneValueArgs}"
        "${multiValueArgs}"
        ${ARGN}
    )

    # THIS DOES NOT WORK HERE I NEED TO SET IT IN THE PARENT FOLDER
    set(CMAKE_INCLUDE_CURRENT_DIR ON)

    get_filename_component(FILE_RAW ${TEST_FILE} NAME_WE)
    add_executable(${FILE_RAW} ${TEST_FILE})

    set_target_properties(${FILE_RAW}
        PROPERTIES
        CXX_STANDARD 14
        CXX_EXTENSIONS OFF
        AUTOMOC ON
        AUTOUIC ON
        FOLDER ${TEST_FOLDER}
    )

    find_package(Qt5Test)
    target_link_libraries(${FILE_RAW} ${TEST_LIBRARIES})

    add_test(NAME ${FILE_RAW} COMMAND ${FILE_RAW})
endfunction()











On Mon, Oct 24, 2016 at 3:48 PM, Craig Scott <craig.scott at crascit.com>
wrote:

> function() introduces a new scope, so if you want changes you make to
> variables inside the function to be visible outside the function, you need
> to use set(... PARENT_SCOPE). Alternatively, a macro() does not introduce a
> new scope, so replacing your function() with a macro() may also yield the
> behaviour you want (but changing to a macro has other effects, so make sure
> you read the docs before going down that path). Also note that setting it
> in one directory does not make it apply to subdirectories as well, in case
> that matters in your situation.
>
>
>
> On Tue, Oct 25, 2016 at 9:42 AM, Tiago Macarios <tiagomacarios at gmail.com>
> wrote:
>
>> Hi,
>>
>> Does CMAKE_INCLUDE_CURRENT_DIR need to be set outside of a function?
>>
>> I have a function where I define an executable "add_executable". This
>> executable uses moc'ed Qt clasees, so I need to set
>> CMAKE_INCLUDE_CURRENT_DIR. It seems like I have to set it from the top
>> level script calling the function. If I set it inside the function the
>> compilation fails with a missing moc file.
>>
>> Any ideas?
>>
>> Tiago
>>
>> --
>>
>> 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
>>
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161024/c7465b1f/attachment.html>

From craig.scott at crascit.com  Mon Oct 24 18:59:25 2016
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 25 Oct 2016 09:59:25 +1100
Subject: [CMake] CMAKE_INCLUDE_CURRENT_DIR on a function
In-Reply-To: <CAKLVFYGORSvFc2dqCCfYGz7eoOMZyo+0HScFtCY35PZx4QNPjg@mail.gmail.com>
References: <CAKLVFYFp9J1QKOPTA=q=XaqA+mBPu2Zveb-LsBQ0FCoMLKCxHg@mail.gmail.com>
 <CA+dygY=UXNmGcZLxW56WtFZxp-Mph1+6yaXLE06gXq9FB8ZwVw@mail.gmail.com>
 <CAKLVFYGORSvFc2dqCCfYGz7eoOMZyo+0HScFtCY35PZx4QNPjg@mail.gmail.com>
Message-ID: <CA+dygYkrwiEoP+W=nnXJstWA6PAN1D9iPM6t+hWCx_BhmxDf4Q@mail.gmail.com>

Are you sure what you want isn't to specify INTERFACE header directories on
whatever is being passed in as the ${TEST_LIBRARIES} libraries? If the
requirement to have the parent directory's source/binary dirs added to the
header search path is coming from those instead of the test's own
executable, then it would seem that's the right place to put the
dependency, not within the function.

On Tue, Oct 25, 2016 at 9:55 AM, Tiago Macarios <tiagomacarios at gmail.com>
wrote:

> Hi Craig,
>
> Maybe my problem description was lacking. Below is the function I have.
> Both CMAKE_INCLUDE_CURRENT_DIR and the target are defined on the same
> function scope, but this does not seem to work. I need to define
> CMAKE_INCLUDE_CURRENT_DIR on the parent CMakeLists file.
>
> function(AddTest)
>     set(options)
>     set(oneValueArgs FILE FOLDER)
>     set(multiValueArgs LIBRARIES)
>     cmake_parse_arguments(TEST
>         "${options}"
>         "${oneValueArgs}"
>         "${multiValueArgs}"
>         ${ARGN}
>     )
>
>     # THIS DOES NOT WORK HERE I NEED TO SET IT IN THE PARENT FOLDER
>     set(CMAKE_INCLUDE_CURRENT_DIR ON)
>
>     get_filename_component(FILE_RAW ${TEST_FILE} NAME_WE)
>     add_executable(${FILE_RAW} ${TEST_FILE})
>
>     set_target_properties(${FILE_RAW}
>         PROPERTIES
>         CXX_STANDARD 14
>         CXX_EXTENSIONS OFF
>         AUTOMOC ON
>         AUTOUIC ON
>         FOLDER ${TEST_FOLDER}
>     )
>
>     find_package(Qt5Test)
>     target_link_libraries(${FILE_RAW} ${TEST_LIBRARIES})
>
>     add_test(NAME ${FILE_RAW} COMMAND ${FILE_RAW})
> endfunction()
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Oct 24, 2016 at 3:48 PM, Craig Scott <craig.scott at crascit.com>
> wrote:
>
>> function() introduces a new scope, so if you want changes you make to
>> variables inside the function to be visible outside the function, you need
>> to use set(... PARENT_SCOPE). Alternatively, a macro() does not introduce a
>> new scope, so replacing your function() with a macro() may also yield the
>> behaviour you want (but changing to a macro has other effects, so make sure
>> you read the docs before going down that path). Also note that setting it
>> in one directory does not make it apply to subdirectories as well, in case
>> that matters in your situation.
>>
>>
>>
>> On Tue, Oct 25, 2016 at 9:42 AM, Tiago Macarios <tiagomacarios at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Does CMAKE_INCLUDE_CURRENT_DIR need to be set outside of a function?
>>>
>>> I have a function where I define an executable "add_executable". This
>>> executable uses moc'ed Qt clasees, so I need to set
>>> CMAKE_INCLUDE_CURRENT_DIR. It seems like I have to set it from the top
>>> level script calling the function. If I set it inside the function the
>>> compilation fails with a missing moc file.
>>>
>>> Any ideas?
>>>
>>> Tiago
>>>
>>> --
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/0542c74a/attachment-0001.html>

From timothy.rae at sbibits.com  Mon Oct 24 21:52:12 2016
From: timothy.rae at sbibits.com (Tim Rae)
Date: Tue, 25 Oct 2016 10:52:12 +0900
Subject: [CMake] Prevent ExternalProject from updating git submodules
In-Reply-To: <9cb3ed5e-f9c1-6d4e-27df-d6849c70a061@sbibits.com>
References: <9cb3ed5e-f9c1-6d4e-27df-d6849c70a061@sbibits.com>
Message-ID: <56263faa-9492-be51-d5b0-eaa238a7ecff@sbibits.com>

Hi all,

I'm using ExternalProject_Add to add the popular C++ library range-v3 to 
one of our projects. However, since the build server only has local 
intranet access, and therefore can't access the main github repository, 
we have put a clone of that repo on our local gitlab:

ExternalProject_Add(range-v3
     PREFIX ${PREFIX_DIR}
     GIT_REPOSITORY ${LOCAL_GITLAB_URI}
)

The problem is that range-v3 has a documentation submodule that points 
to github, so `git clone ${LOCAL_GITLAB_URI} --recursive` would fail 
when github is inaccessible, whereas git clone works fine without the 
recursive flag.

I found a previous message from Tim Gallagher on the mailing list 
reporting the same problem, but it looks like the issue was never 
addressed upstream.

https://cmake.org/pipermail/cmake/2015-March/060100.html

Unfortunately, specifying GIT_SUBMODULES "" will add all submodules, so 
it doesn't appear that variable will help to solve the issue. I would 
suggest either having a special value like "__NONE__", or having a new 
boolean variable like INIT_GIT_SUBMODULES; either of which can be used 
to disable the automatic initialization of submodules entirely.

You could also change the default to NOT pull in submodules. This would 
be much better IMHO, as the current behavior is unintuitive. Most 
developers (e.g. myself until yesterday) don't even know what a 
submodule is, and are only familiar with using git clone, as opposed to 
git clone --recursive. Obviously this would be a breaking change though, 
so I understand that you probably don't want to go with this option.

For now I have "solved" the problem by adding a new commit to our 
range-v3 fork removing all git submodules, however this makes it more 
difficult to get the upstream changes in, so I highly recommend adding 
an option to disable the automatic initialization of git submodules.

Best regards,
Tim

-- 
*This correspondence (including any attachments) is for the intended 
recipient(s) only. It may contain confidential or privileged information or 
both. No confidentiality or privilege is waived or lost by any 
mis-transmission. If you receive this correspondence by mistake, please 
contact the sender immediately, delete this correspondence (and all 
attachments) and destroy any hard copies. You must not use, disclose, copy, 
distribute or rely on any part of this correspondence (including any 
attachments) if you are not the intended recipient(s). ? 
???????????????????? ?? ?????????????????????????????????? ? ?????????????? 
? ??????????????????? ? ??????????????????????????????????? ? ??????????? 
????????????????????? ?? ????????????????????? ??????????????? ? ???????? 
????????????????????? ????? ????????????????????? ??*

From post at hendrik-sattler.de  Mon Oct 24 23:29:58 2016
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Tue, 25 Oct 2016 05:29:58 +0200
Subject: [CMake] Prevent ExternalProject from updating git submodules
In-Reply-To: <56263faa-9492-be51-d5b0-eaa238a7ecff@sbibits.com>
References: <9cb3ed5e-f9c1-6d4e-27df-d6849c70a061@sbibits.com>
 <56263faa-9492-be51-d5b0-eaa238a7ecff@sbibits.com>
Message-ID: <D8A9B810-E81F-4510-B3BB-9F4253E7B103@hendrik-sattler.de>

Hi,

you can tell git where your copy of tree remote url is. This is site-specific and does not change the repository:
git config remote."$origirl".url "$newurl"

HS


Am 25. Oktober 2016 03:52:12 MESZ, schrieb Tim Rae <timothy.rae at sbibits.com>:
>Hi all,
>
>I'm using ExternalProject_Add to add the popular C++ library range-v3
>to 
>one of our projects. However, since the build server only has local 
>intranet access, and therefore can't access the main github repository,
>
>we have put a clone of that repo on our local gitlab:
>
>ExternalProject_Add(range-v3
>     PREFIX ${PREFIX_DIR}
>     GIT_REPOSITORY ${LOCAL_GITLAB_URI}
>)
>
>The problem is that range-v3 has a documentation submodule that points 
>to github, so `git clone ${LOCAL_GITLAB_URI} --recursive` would fail 
>when github is inaccessible, whereas git clone works fine without the 
>recursive flag.
>
>I found a previous message from Tim Gallagher on the mailing list 
>reporting the same problem, but it looks like the issue was never 
>addressed upstream.
>
>https://cmake.org/pipermail/cmake/2015-March/060100.html
>
>Unfortunately, specifying GIT_SUBMODULES "" will add all submodules, so
>
>it doesn't appear that variable will help to solve the issue. I would 
>suggest either having a special value like "__NONE__", or having a new 
>boolean variable like INIT_GIT_SUBMODULES; either of which can be used 
>to disable the automatic initialization of submodules entirely.
>
>You could also change the default to NOT pull in submodules. This would
>
>be much better IMHO, as the current behavior is unintuitive. Most 
>developers (e.g. myself until yesterday) don't even know what a 
>submodule is, and are only familiar with using git clone, as opposed to
>
>git clone --recursive. Obviously this would be a breaking change
>though, 
>so I understand that you probably don't want to go with this option.
>
>For now I have "solved" the problem by adding a new commit to our 
>range-v3 fork removing all git submodules, however this makes it more 
>difficult to get the upstream changes in, so I highly recommend adding 
>an option to disable the automatic initialization of git submodules.
>
>Best regards,
>Tim
>
>-- 
>*This correspondence (including any attachments) is for the intended 
>recipient(s) only. It may contain confidential or privileged
>information or 
>both. No confidentiality or privilege is waived or lost by any 
>mis-transmission. If you receive this correspondence by mistake, please
>
>contact the sender immediately, delete this correspondence (and all 
>attachments) and destroy any hard copies. You must not use, disclose,
>copy, 
>distribute or rely on any part of this correspondence (including any 
>attachments) if you are not the intended recipient(s). ? 
>???????????????????? ?? ?????????????????????????????????? ?
>?????????????? 
>? ??????????????????? ? ??????????????????????????????????? ?
>??????????? 
>????????????????????? ?? ????????????????????? ??????????????? ?
>???????? 
>????????????????????? ????? ????????????????????? ??*
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at:
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For
>more information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

From timothy.rae at sbibits.com  Mon Oct 24 23:35:32 2016
From: timothy.rae at sbibits.com (Timothy Rae)
Date: Tue, 25 Oct 2016 12:35:32 +0900
Subject: [CMake] Prevent ExternalProject from updating git submodules
In-Reply-To: <D8A9B810-E81F-4510-B3BB-9F4253E7B103@hendrik-sattler.de>
References: <9cb3ed5e-f9c1-6d4e-27df-d6849c70a061@sbibits.com>
 <56263faa-9492-be51-d5b0-eaa238a7ecff@sbibits.com>
 <D8A9B810-E81F-4510-B3BB-9F4253E7B103@hendrik-sattler.de>
Message-ID: <CAPu9Sr7Lwgmp8oE_Xw+c2tbCUY8DSjqbpNSjsj_C4Do53XW8uA@mail.gmail.com>

Thanks for the tip, but I'd rather it didn't fetch the documentation
submodule at all, as this unnecessarily slows down the build.

On Tue, Oct 25, 2016 at 12:29 PM, Hendrik Sattler <post at hendrik-sattler.de>
wrote:

> Hi,
>
> you can tell git where your copy of tree remote url is. This is
> site-specific and does not change the repository:
> git config remote."$origirl".url "$newurl"
>
> HS
>
>
> Am 25. Oktober 2016 03:52:12 MESZ, schrieb Tim Rae <
> timothy.rae at sbibits.com>:
> >Hi all,
> >
> >I'm using ExternalProject_Add to add the popular C++ library range-v3
> >to
> >one of our projects. However, since the build server only has local
> >intranet access, and therefore can't access the main github repository,
> >
> >we have put a clone of that repo on our local gitlab:
> >
> >ExternalProject_Add(range-v3
> >     PREFIX ${PREFIX_DIR}
> >     GIT_REPOSITORY ${LOCAL_GITLAB_URI}
> >)
> >
> >The problem is that range-v3 has a documentation submodule that points
> >to github, so `git clone ${LOCAL_GITLAB_URI} --recursive` would fail
> >when github is inaccessible, whereas git clone works fine without the
> >recursive flag.
> >
> >I found a previous message from Tim Gallagher on the mailing list
> >reporting the same problem, but it looks like the issue was never
> >addressed upstream.
> >
> >https://cmake.org/pipermail/cmake/2015-March/060100.html
> >
> >Unfortunately, specifying GIT_SUBMODULES "" will add all submodules, so
> >
> >it doesn't appear that variable will help to solve the issue. I would
> >suggest either having a special value like "__NONE__", or having a new
> >boolean variable like INIT_GIT_SUBMODULES; either of which can be used
> >to disable the automatic initialization of submodules entirely.
> >
> >You could also change the default to NOT pull in submodules. This would
> >
> >be much better IMHO, as the current behavior is unintuitive. Most
> >developers (e.g. myself until yesterday) don't even know what a
> >submodule is, and are only familiar with using git clone, as opposed to
> >
> >git clone --recursive. Obviously this would be a breaking change
> >though,
> >so I understand that you probably don't want to go with this option.
> >
> >For now I have "solved" the problem by adding a new commit to our
> >range-v3 fork removing all git submodules, however this makes it more
> >difficult to get the upstream changes in, so I highly recommend adding
> >an option to disable the automatic initialization of git submodules.
> >
> >Best regards,
> >Tim
> >
> >--
> >*This correspondence (including any attachments) is for the intended
> >recipient(s) only. It may contain confidential or privileged
> >information or
> >both. No confidentiality or privilege is waived or lost by any
> >mis-transmission. If you receive this correspondence by mistake, please
> >
> >contact the sender immediately, delete this correspondence (and all
> >attachments) and destroy any hard copies. You must not use, disclose,
> >copy,
> >distribute or rely on any part of this correspondence (including any
> >attachments) if you are not the intended recipient(s). ?
> >???????????????????? ?? ?????????????????????????????????? ?
> >??????????????
> >? ??????????????????? ? ??????????????????????????????????? ?
> >???????????
> >????????????????????? ?? ????????????????????? ??????????????? ?
> >????????
> >????????????????????? ????? ????????????????????? ??*
> >--
> >
> >Powered by www.kitware.com
> >
> >Please keep messages on-topic and check the CMake FAQ at:
> >http://www.cmake.org/Wiki/CMake_FAQ
> >
> >Kitware offers various services to support the CMake community. For
> >more information on each offering, please visit:
> >
> >CMake Support: http://cmake.org/cmake/help/support.html
> >CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> >Visit other Kitware open-source projects at
> >http://www.kitware.com/opensource/opensource.html
> >
> >Follow this link to subscribe/unsubscribe:
> >http://public.kitware.com/mailman/listinfo/cmake
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
>

-- 
*This correspondence (including any attachments) is for the intended 
recipient(s) only. It may contain confidential or privileged information or 
both. No confidentiality or privilege is waived or lost by any 
mis-transmission. If you receive this correspondence by mistake, please 
contact the sender immediately, delete this correspondence (and all 
attachments) and destroy any hard copies. You must not use, disclose, copy, 
distribute or rely on any part of this correspondence (including any 
attachments) if you are not the intended recipient(s). ? 
???????????????????? ?? ?????????????????????????????????? ? ?????????????? 
? ??????????????????? ? ??????????????????????????????????? ? ??????????? 
????????????????????? ?? ????????????????????? ??????????????? ? ???????? 
????????????????????? ????? ????????????????????? ??*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/b1bfd8c4/attachment-0001.html>

From petr.kmoch at gmail.com  Tue Oct 25 01:20:34 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Tue, 25 Oct 2016 07:20:34 +0200
Subject: [CMake] CMAKE_INCLUDE_CURRENT_DIR on a function
In-Reply-To: <CAKLVFYGORSvFc2dqCCfYGz7eoOMZyo+0HScFtCY35PZx4QNPjg@mail.gmail.com>
References: <CAKLVFYFp9J1QKOPTA=q=XaqA+mBPu2Zveb-LsBQ0FCoMLKCxHg@mail.gmail.com>
 <CA+dygY=UXNmGcZLxW56WtFZxp-Mph1+6yaXLE06gXq9FB8ZwVw@mail.gmail.com>
 <CAKLVFYGORSvFc2dqCCfYGz7eoOMZyo+0HScFtCY35PZx4QNPjg@mail.gmail.com>
Message-ID: <CAKohaZfYLYBwX7HTUmh8mTgfHUjorzvPKkj7mm0CSTwchZW_ag@mail.gmail.com>

Hi Tiago.

Yes, Craig's original comment applies. Targets do not have scope, variables
do. Because you're in a function, you'd need to set the variable using
PARENT_SCOPE to have it apply outside the function:

function(AddTest)
  #...
  set(CMAKE_INCLUDE_CURRENT_DIR ON PARENT_SCOPE)
  #...
endfunction()

Note that this will only help if the funciton is called directly; if called
from another function, it will fail again (since the variable would just be
set in the calling function's scope and not at global level).

However, taking a step back, I believe setting the variable doesn't belong
into the `AddTest` function at all. Looking at it, it seems to be concerned
with creating and setting up one target. IMO, such a function should not
also modify global state. Do not forget that CMAKE_INCLUDE_CURRENT_DIR is
not target-specific in any way; it affects *all* targets in the current
directory.

Therefore, my suggestion would be to move setting it out of the function
altogether and perform it at CMakeList scope. Alternatively, put the
function's declaration into a separate CMake file, along with the set()
command. Then, whoever wants to use the function has to include() that
file, which will also cause them to have CMAKE_INCLUDE_CURRENT_DIR set
accordingly.

Petr

On 25 October 2016 at 00:55, Tiago Macarios <tiagomacarios at gmail.com> wrote:

> Hi Craig,
>
> Maybe my problem description was lacking. Below is the function I have.
> Both CMAKE_INCLUDE_CURRENT_DIR and the target are defined on the same
> function scope, but this does not seem to work. I need to define
> CMAKE_INCLUDE_CURRENT_DIR on the parent CMakeLists file.
>
> function(AddTest)
>     set(options)
>     set(oneValueArgs FILE FOLDER)
>     set(multiValueArgs LIBRARIES)
>     cmake_parse_arguments(TEST
>         "${options}"
>         "${oneValueArgs}"
>         "${multiValueArgs}"
>         ${ARGN}
>     )
>
>     # THIS DOES NOT WORK HERE I NEED TO SET IT IN THE PARENT FOLDER
>     set(CMAKE_INCLUDE_CURRENT_DIR ON)
>
>     get_filename_component(FILE_RAW ${TEST_FILE} NAME_WE)
>     add_executable(${FILE_RAW} ${TEST_FILE})
>
>     set_target_properties(${FILE_RAW}
>         PROPERTIES
>         CXX_STANDARD 14
>         CXX_EXTENSIONS OFF
>         AUTOMOC ON
>         AUTOUIC ON
>         FOLDER ${TEST_FOLDER}
>     )
>
>     find_package(Qt5Test)
>     target_link_libraries(${FILE_RAW} ${TEST_LIBRARIES})
>
>     add_test(NAME ${FILE_RAW} COMMAND ${FILE_RAW})
> endfunction()
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Oct 24, 2016 at 3:48 PM, Craig Scott <craig.scott at crascit.com>
> wrote:
>
>> function() introduces a new scope, so if you want changes you make to
>> variables inside the function to be visible outside the function, you need
>> to use set(... PARENT_SCOPE). Alternatively, a macro() does not introduce a
>> new scope, so replacing your function() with a macro() may also yield the
>> behaviour you want (but changing to a macro has other effects, so make sure
>> you read the docs before going down that path). Also note that setting it
>> in one directory does not make it apply to subdirectories as well, in case
>> that matters in your situation.
>>
>>
>>
>> On Tue, Oct 25, 2016 at 9:42 AM, Tiago Macarios <tiagomacarios at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Does CMAKE_INCLUDE_CURRENT_DIR need to be set outside of a function?
>>>
>>> I have a function where I define an executable "add_executable". This
>>> executable uses moc'ed Qt clasees, so I need to set
>>> CMAKE_INCLUDE_CURRENT_DIR. It seems like I have to set it from the top
>>> level script calling the function. If I set it inside the function the
>>> compilation fails with a missing moc file.
>>>
>>> Any ideas?
>>>
>>> Tiago
>>>
>>> --
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/41e12f6b/attachment.html>

From craig.scott at crascit.com  Tue Oct 25 07:50:16 2016
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 25 Oct 2016 22:50:16 +1100
Subject: [CMake] CMAKE_INCLUDE_CURRENT_DIR on a function
In-Reply-To: <CAKohaZfYLYBwX7HTUmh8mTgfHUjorzvPKkj7mm0CSTwchZW_ag@mail.gmail.com>
References: <CAKLVFYFp9J1QKOPTA=q=XaqA+mBPu2Zveb-LsBQ0FCoMLKCxHg@mail.gmail.com>
 <CA+dygY=UXNmGcZLxW56WtFZxp-Mph1+6yaXLE06gXq9FB8ZwVw@mail.gmail.com>
 <CAKLVFYGORSvFc2dqCCfYGz7eoOMZyo+0HScFtCY35PZx4QNPjg@mail.gmail.com>
 <CAKohaZfYLYBwX7HTUmh8mTgfHUjorzvPKkj7mm0CSTwchZW_ag@mail.gmail.com>
Message-ID: <CA+dygYk23NvBN3aPV1i0ZgoXMd70qdD6iFerGOFOUCzTVXGNHQ@mail.gmail.com>

Thinking about this some more, I suspect Petr's comments may be on the
right track. What matters is the value of this variable in the scope of the
*directory* being processed. You need the CMAKE_INCLUDE_CURRENT_DIR
variable to be set in that directory scope, if I'm understanding the docs
correctly. If you create an executable target inside the function, I would
hazard a guess that it is that directory scope's variable that will be
consulted to determine whether to include the current source and binary
dirs in the include path.

To be honest, when I've used the automoc feature in the past, I've always
set this variable directly in the CMakeLists.txt file where I want it to
apply, never inside a function. This has always Just Worked for me. If you
really want to get those two paths included in the search path without
having to rely on CMAKE_INCLUDE_CURRENT_DIR being set in the directory
scope, you can always just add them manually to your target inside the
function. For example:

function(AddTest)
    ...
    add_executable(${FILE_RAW} ${TEST_FILE})
    target_include_directories(${FILE_RAW} PRIVATE
        "${CMAKE_CURRENT_BINARY_DIR}"
        "${CMAKE_CURRENT_SOURCE_DIR}"
    )
    ...
endfunction()

Pretty sure that would work and it avoids the whole question of where
CMAKE_INCLUDE_CURRENT_DIR needs to be set. One could also argue that it
makes your function more self-contained with fewer side effects.


On Tue, Oct 25, 2016 at 4:20 PM, Petr Kmoch <petr.kmoch at gmail.com> wrote:

> Hi Tiago.
>
> Yes, Craig's original comment applies. Targets do not have scope,
> variables do. Because you're in a function, you'd need to set the variable
> using PARENT_SCOPE to have it apply outside the function:
>
> function(AddTest)
>   #...
>   set(CMAKE_INCLUDE_CURRENT_DIR ON PARENT_SCOPE)
>   #...
> endfunction()
>
> Note that this will only help if the funciton is called directly; if
> called from another function, it will fail again (since the variable would
> just be set in the calling function's scope and not at global level).
>
> However, taking a step back, I believe setting the variable doesn't belong
> into the `AddTest` function at all. Looking at it, it seems to be concerned
> with creating and setting up one target. IMO, such a function should not
> also modify global state. Do not forget that CMAKE_INCLUDE_CURRENT_DIR is
> not target-specific in any way; it affects *all* targets in the current
> directory.
>
> Therefore, my suggestion would be to move setting it out of the function
> altogether and perform it at CMakeList scope. Alternatively, put the
> function's declaration into a separate CMake file, along with the set()
> command. Then, whoever wants to use the function has to include() that
> file, which will also cause them to have CMAKE_INCLUDE_CURRENT_DIR set
> accordingly.
>
> Petr
>
>
> On 25 October 2016 at 00:55, Tiago Macarios <tiagomacarios at gmail.com>
> wrote:
>
>> Hi Craig,
>>
>> Maybe my problem description was lacking. Below is the function I have.
>> Both CMAKE_INCLUDE_CURRENT_DIR and the target are defined on the same
>> function scope, but this does not seem to work. I need to define
>> CMAKE_INCLUDE_CURRENT_DIR on the parent CMakeLists file.
>>
>> function(AddTest)
>>     set(options)
>>     set(oneValueArgs FILE FOLDER)
>>     set(multiValueArgs LIBRARIES)
>>     cmake_parse_arguments(TEST
>>         "${options}"
>>         "${oneValueArgs}"
>>         "${multiValueArgs}"
>>         ${ARGN}
>>     )
>>
>>     # THIS DOES NOT WORK HERE I NEED TO SET IT IN THE PARENT FOLDER
>>     set(CMAKE_INCLUDE_CURRENT_DIR ON)
>>
>>     get_filename_component(FILE_RAW ${TEST_FILE} NAME_WE)
>>     add_executable(${FILE_RAW} ${TEST_FILE})
>>
>>     set_target_properties(${FILE_RAW}
>>         PROPERTIES
>>         CXX_STANDARD 14
>>         CXX_EXTENSIONS OFF
>>         AUTOMOC ON
>>         AUTOUIC ON
>>         FOLDER ${TEST_FOLDER}
>>     )
>>
>>     find_package(Qt5Test)
>>     target_link_libraries(${FILE_RAW} ${TEST_LIBRARIES})
>>
>>     add_test(NAME ${FILE_RAW} COMMAND ${FILE_RAW})
>> endfunction()
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Oct 24, 2016 at 3:48 PM, Craig Scott <craig.scott at crascit.com>
>> wrote:
>>
>>> function() introduces a new scope, so if you want changes you make to
>>> variables inside the function to be visible outside the function, you need
>>> to use set(... PARENT_SCOPE). Alternatively, a macro() does not introduce a
>>> new scope, so replacing your function() with a macro() may also yield the
>>> behaviour you want (but changing to a macro has other effects, so make sure
>>> you read the docs before going down that path). Also note that setting it
>>> in one directory does not make it apply to subdirectories as well, in case
>>> that matters in your situation.
>>>
>>>
>>>
>>> On Tue, Oct 25, 2016 at 9:42 AM, Tiago Macarios <tiagomacarios at gmail.com
>>> > wrote:
>>>
>>>> Hi,
>>>>
>>>> Does CMAKE_INCLUDE_CURRENT_DIR need to be set outside of a function?
>>>>
>>>> I have a function where I define an executable "add_executable". This
>>>> executable uses moc'ed Qt clasees, so I need to set
>>>> CMAKE_INCLUDE_CURRENT_DIR. It seems like I have to set it from the top
>>>> level script calling the function. If I set it inside the function the
>>>> compilation fails with a missing moc file.
>>>>
>>>> Any ideas?
>>>>
>>>> Tiago
>>>>
>>>> --
>>>>
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Craig Scott
>>> Melbourne, Australia
>>> https://crascit.com
>>>
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/c181cc80/attachment-0001.html>

From homerocda at gmail.com  Tue Oct 25 08:06:40 2016
From: homerocda at gmail.com (Homero Cardoso de Almeida)
Date: Tue, 25 Oct 2016 12:06:40 +0000
Subject: [CMake] [EXTERNAL]:  FindProtobuf in specified dirs
In-Reply-To: <6C609AD4-4546-4943-BEA0-BDBA8015A6B2@ionic.com>
References: <CAPv0ZwpN8B5xysJvD9O2gboOFy4vNSDBtLqWgK9ftyDyPJ+QeA@mail.gmail.com>
 <6C609AD4-4546-4943-BEA0-BDBA8015A6B2@ionic.com>
Message-ID: <CAPv0Zwr_QS73FqA7PFOYh-Whf3swhGJUcrHNBQ_tMFFLU53HKQ@mail.gmail.com>

Thanks for your help.

I was able to download and compile protobuffers 2.7 using cmake, however
the cmake config for protobuffers is fixed for 2.8.12, while I need it to
work with cmake 2.8.9 as it's going to run in system frozen in Debian
Squeeze (Squeeze actually defaults on cmake 2.8.2 and I got it to install
2.8.9 from Wheezy).

Currently I'm trying to create a debian package from cmake 3.0.2 on
squeeze, but I'm having a hard time due to dependencies on sphinx. Do you
have any ideas on how to circumvent the doc generation?

Thanks and regards,
Homero.

Em qui, 20 de out de 2016 ?s 17:05, Parag Chandra <parag at ionicsecurity.com>
escreveu:

> I believe the protobuf-config.cmake.in generates a protobuf-config.cmake
> file once you actually use CMake to build protobuf itself.
>
>
>
>
>
>
>
> *Parag Chandra *Technical Lead, Mobile Team
> Mobile: +1.919.824.1410 <+1%20919-824-1410>
>
> Ionic Security Inc.
> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309
>
>
>
>
>
> *From: *CMake <cmake-bounces at cmake.org> on behalf of Homero Cardoso de
> Almeida <homerocda at gmail.com>
> *Date: *Thursday, October 20, 2016 at 2:56 PM
> *To: *"cmake at cmake.org" <cmake at cmake.org>
> *Subject: *[EXTERNAL]: [CMake] FindProtobuf in specified dirs
>
>
>
> Hello,
>
>
>
> I'm working on enhancing the build process in my company by using CMake,
> and I'm having trouble to have it find the Google Protocol Buffers binary
> and libraries in a specific directory in my workspace.
>
>
>
> Due to several reasons, we cannot install protobuffers directly in our
> environment, so I have it download and unpack a zip file with the
> protobuffer library and header files in a directory in my home folder.
> However, when I use the find_package directive giving said folder as a hint
> it complains that it could not find a protobuf-config.cmake file and fails.
> I couldn't find any such file anywhere, the only thing coming close is a "
> protobuf-config.cmake.in" in the protobuf source tree and I don't know if
> I can use that.
>
>
>
> Do I have to provide my own protobuf-config.cmake file, or I'm using it
> completely wrong?
>
>
>
> We are frozen in protocol buffers 2.4.1. I guess we can upgrade to 2.7.0,
> but we can't use 3.0.x.
>
>
>
> Thanks,
>
> Homero.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/58c60a8e/attachment.html>

From DLRdave at aol.com  Tue Oct 25 09:12:36 2016
From: DLRdave at aol.com (David Cole)
Date: Tue, 25 Oct 2016 09:12:36 -0400
Subject: [CMake] Prevent ExternalProject from updating git submodules
In-Reply-To: <CAPu9Sr7Lwgmp8oE_Xw+c2tbCUY8DSjqbpNSjsj_C4Do53XW8uA@mail.gmail.com>
References: <9cb3ed5e-f9c1-6d4e-27df-d6849c70a061@sbibits.com>
 <56263faa-9492-be51-d5b0-eaa238a7ecff@sbibits.com>
 <D8A9B810-E81F-4510-B3BB-9F4253E7B103@hendrik-sattler.de>
 <CAPu9Sr7Lwgmp8oE_Xw+c2tbCUY8DSjqbpNSjsj_C4Do53XW8uA@mail.gmail.com>
Message-ID: <FD52722C-6BE3-4459-9064-209DFCDF3921@aol.com>

Sounds like you should consider customizing the git clone with DOWNLOAD_COMMAND. You can do anything you want as a customization...

HTH,
David


> On Oct 24, 2016, at 11:35 PM, Timothy Rae <timothy.rae at sbibits.com> wrote:
> 
> Thanks for the tip, but I'd rather it didn't fetch the documentation submodule at all, as this unnecessarily slows down the build.
> 
>> On Tue, Oct 25, 2016 at 12:29 PM, Hendrik Sattler <post at hendrik-sattler.de> wrote:
>> Hi,
>> 
>> you can tell git where your copy of tree remote url is. This is site-specific and does not change the repository:
>> git config remote."$origirl".url "$newurl"
>> 
>> HS
>> 
>> 
>> Am 25. Oktober 2016 03:52:12 MESZ, schrieb Tim Rae <timothy.rae at sbibits.com>:
>> >Hi all,
>> >
>> >I'm using ExternalProject_Add to add the popular C++ library range-v3
>> >to
>> >one of our projects. However, since the build server only has local
>> >intranet access, and therefore can't access the main github repository,
>> >
>> >we have put a clone of that repo on our local gitlab:
>> >
>> >ExternalProject_Add(range-v3
>> >     PREFIX ${PREFIX_DIR}
>> >     GIT_REPOSITORY ${LOCAL_GITLAB_URI}
>> >)
>> >
>> >The problem is that range-v3 has a documentation submodule that points
>> >to github, so `git clone ${LOCAL_GITLAB_URI} --recursive` would fail
>> >when github is inaccessible, whereas git clone works fine without the
>> >recursive flag.
>> >
>> >I found a previous message from Tim Gallagher on the mailing list
>> >reporting the same problem, but it looks like the issue was never
>> >addressed upstream.
>> >
>> >https://cmake.org/pipermail/cmake/2015-March/060100.html
>> >
>> >Unfortunately, specifying GIT_SUBMODULES "" will add all submodules, so
>> >
>> >it doesn't appear that variable will help to solve the issue. I would
>> >suggest either having a special value like "__NONE__", or having a new
>> >boolean variable like INIT_GIT_SUBMODULES; either of which can be used
>> >to disable the automatic initialization of submodules entirely.
>> >
>> >You could also change the default to NOT pull in submodules. This would
>> >
>> >be much better IMHO, as the current behavior is unintuitive. Most
>> >developers (e.g. myself until yesterday) don't even know what a
>> >submodule is, and are only familiar with using git clone, as opposed to
>> >
>> >git clone --recursive. Obviously this would be a breaking change
>> >though,
>> >so I understand that you probably don't want to go with this option.
>> >
>> >For now I have "solved" the problem by adding a new commit to our
>> >range-v3 fork removing all git submodules, however this makes it more
>> >difficult to get the upstream changes in, so I highly recommend adding
>> >an option to disable the automatic initialization of git submodules.
>> >
>> >Best regards,
>> >Tim
>> >
>> >--
>> >*This correspondence (including any attachments) is for the intended
>> >recipient(s) only. It may contain confidential or privileged
>> >information or
>> >both. No confidentiality or privilege is waived or lost by any
>> >mis-transmission. If you receive this correspondence by mistake, please
>> >
>> >contact the sender immediately, delete this correspondence (and all
>> >attachments) and destroy any hard copies. You must not use, disclose,
>> >copy,
>> >distribute or rely on any part of this correspondence (including any
>> >attachments) if you are not the intended recipient(s). ?
>> >???????????????????? ?? ?????????????????????????????????? ?
>> >??????????????
>> >? ??????????????????? ? ??????????????????????????????????? ?
>> >???????????
>> >????????????????????? ?? ????????????????????? ??????????????? ?
>> >????????
>> >????????????????????? ????? ????????????????????? ??*
>> >--
>> >
>> >Powered by www.kitware.com
>> >
>> >Please keep messages on-topic and check the CMake FAQ at:
>> >http://www.cmake.org/Wiki/CMake_FAQ
>> >
>> >Kitware offers various services to support the CMake community. For
>> >more information on each offering, please visit:
>> >
>> >CMake Support: http://cmake.org/cmake/help/support.html
>> >CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> >CMake Training Courses: http://cmake.org/cmake/help/training.html
>> >
>> >Visit other Kitware open-source projects at
>> >http://www.kitware.com/opensource/opensource.html
>> >
>> >Follow this link to subscribe/unsubscribe:
>> >http://public.kitware.com/mailman/listinfo/cmake
>> 
>> --
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
>> 
> 
> 
> This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s). ? ???????????????????? ?? ?????????????????????????????????? ? ?????????????? ? ??????????????????? ? ??????????????????????????????????? ? ??????????? ????????????????????? ?? ????????????????????? ??????????????? ? ???????? ????????????????????? ????? ????????????????????? ??
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/07411d92/attachment-0001.html>

From homerocda at gmail.com  Tue Oct 25 09:28:50 2016
From: homerocda at gmail.com (Homero Cardoso de Almeida)
Date: Tue, 25 Oct 2016 13:28:50 +0000
Subject: [CMake] [EXTERNAL]:  FindProtobuf in specified dirs
In-Reply-To: <8590B55B-1501-4D0D-AA7E-FA731716CB19@ionic.com>
References: <CAPv0ZwpN8B5xysJvD9O2gboOFy4vNSDBtLqWgK9ftyDyPJ+QeA@mail.gmail.com>
 <6C609AD4-4546-4943-BEA0-BDBA8015A6B2@ionic.com>
 <CAPv0Zwr_QS73FqA7PFOYh-Whf3swhGJUcrHNBQ_tMFFLU53HKQ@mail.gmail.com>
 <8590B55B-1501-4D0D-AA7E-FA731716CB19@ionic.com>
Message-ID: <CAPv0ZwqnQQhdx4xAjzTF8gPMTuiawfydZpO3YH3S6_4wOq6kQw@mail.gmail.com>

Actually, I'm trying to compile cmake 3.0.2 now.

I did exactly that for protobuffers, and it compiled file. It's just the
package config file that still requires 2.8.12 and I'm not sure of the
consequences of changing that. So I'm trying to build 3.0.2 on squeeze now,
and having a hard time building the docs because of sphinx. If I could skip
the docs, that would be fantastic.

Thanks,
Homero

Em ter, 25 de out de 2016 ?s 11:23, Parag Chandra <parag at ionicsecurity.com>
escreveu:

> I actually haven?t ever tried to build protobuffers myself, so I can?t
> comment on its doc generation or sphinx dependency. Sorry if this seems
> obvious, but have you tried modifying protobuffer?s CMakeLists.txt file so
> that it uses the same 2.8.9 CMake you are using? 2.8.12 may not be that far
> off from 2.8.9; it just might be the version of CMake they happened to
> download at the time, rather than a hard requirement on it.
>
>
>
>
>
>
>
> *Parag Chandra *Technical Lead, Mobile Team
> Mobile: +1.919.824.1410 <+1%20919-824-1410>
>
> Ionic Security Inc.
> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309
>
>
>
>
>
> *From: *Homero Cardoso de Almeida <homerocda at gmail.com>
> *Date: *Tuesday, October 25, 2016 at 8:06 AM
> *To: *Parag Chandra <parag at ionicsecurity.com>, "cmake at cmake.org" <
> cmake at cmake.org>
> *Subject: *Re: [EXTERNAL]: [CMake] FindProtobuf in specified dirs
>
>
>
> Thanks for your help.
>
>
>
> I was able to download and compile protobuffers 2.7 using cmake, however
> the cmake config for protobuffers is fixed for 2.8.12, while I need it to
> work with cmake 2.8.9 as it's going to run in system frozen in Debian
> Squeeze (Squeeze actually defaults on cmake 2.8.2 and I got it to install
> 2.8.9 from Wheezy).
>
>
>
> Currently I'm trying to create a debian package from cmake 3.0.2 on
> squeeze, but I'm having a hard time due to dependencies on sphinx. Do you
> have any ideas on how to circumvent the doc generation?
>
>
>
> Thanks and regards,
>
> Homero.
>
>
>
> Em qui, 20 de out de 2016 ?s 17:05, Parag Chandra <parag at ionicsecurity.com>
> escreveu:
>
> I believe the protobuf-config.cmake.in generates a protobuf-config.cmake
> file once you actually use CMake to build protobuf itself.
>
>
>
>
>
>
> *Parag Chandra*
> Technical Lead, Mobile Team
> Mobile: +1.919.824.1410 <+1%20919-824-1410>
>
> Ionic Security Inc.
> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309
>
>
>
>
>
> *From: *CMake <cmake-bounces at cmake.org> on behalf of Homero Cardoso de
> Almeida <homerocda at gmail.com>
> *Date: *Thursday, October 20, 2016 at 2:56 PM
> *To: *"cmake at cmake.org" <cmake at cmake.org>
> *Subject: *[EXTERNAL]: [CMake] FindProtobuf in specified dirs
>
>
>
> Hello,
>
>
>
> I'm working on enhancing the build process in my company by using CMake,
> and I'm having trouble to have it find the Google Protocol Buffers binary
> and libraries in a specific directory in my workspace.
>
>
>
> Due to several reasons, we cannot install protobuffers directly in our
> environment, so I have it download and unpack a zip file with the
> protobuffer library and header files in a directory in my home folder.
> However, when I use the find_package directive giving said folder as a hint
> it complains that it could not find a protobuf-config.cmake file and fails.
> I couldn't find any such file anywhere, the only thing coming close is a "
> protobuf-config.cmake.in" in the protobuf source tree and I don't know if
> I can use that.
>
>
>
> Do I have to provide my own protobuf-config.cmake file, or I'm using it
> completely wrong?
>
>
>
> We are frozen in protocol buffers 2.4.1. I guess we can upgrade to 2.7.0,
> but we can't use 3.0.x.
>
>
>
> Thanks,
>
> Homero.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/40a08985/attachment.html>

From rcdailey.lists at gmail.com  Tue Oct 25 09:48:52 2016
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Tue, 25 Oct 2016 08:48:52 -0500
Subject: [CMake] CMake integration in Gradle (Android Studio)
Message-ID: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>

I'm not sure if the CMake mailing lists are the right place to ask
this question but I thought I'd ask just in case someone has gone down
this path or has experience with what Google/Gradle is actually trying
to accomplish with what seems to be a hand-built version of CMake with
custom patches that are not in upstream repositories.

Prior to switching to Android Studio / Gradle, I was using Eclipse /
Ant. The way I did CMake integration was not really integration at
all: I generated Ninja build scripts using CMake and implemented
custom targets to run "ant release" after all the C++ projects were
built. I made sure that CMake copied relevant *.so files to
appropriate directories in the Ant structure so they are packaged with
built APKs. That's how I did my Android development.

Now that I'm integrating CMake into Gradle, first annoyance I noticed
is that I can't use CMake 3.7 (or any external installation of CMake)
with Android Studio. It requires a version of CMake installed through
SDK Manager. This means I can't use the new Android toolchain
functionality built into CMake 3.7 (sad face). But this is something I
can work around...

Next I found out that stuff I'm setting in my CMake scripts, such as
CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
For whatever reason, Gradle is overriding these from the command line
(I'm guessing?). So this requires me to duplicate the toolchain /
compiler flag setup I already do in my CMake scripts now in the Gradle
build scripts. This seems completely unnecessary and a maintenance
burden.

What I was expecting Gradle to do was essentially provide me some
toolchain file so that CMake can find the compiler and linker to use
and then the rest would be determined by CMake itself.

Is there a way I can tell Gradle to not take so much control over
compiler flags? I want my CMake scripts to do this. I can't imagine
they had a good reason to do this. What have others done in this
situation with their own Gradle + CMake integration? Looking for
advice here, since information is sparse, especially since the Android
Studio 2.2 CMake integration is relatively new stuff.

From parag at ionicsecurity.com  Tue Oct 25 09:35:49 2016
From: parag at ionicsecurity.com (Parag Chandra)
Date: Tue, 25 Oct 2016 13:35:49 +0000
Subject: [CMake] [EXTERNAL]:  FindProtobuf in specified dirs
In-Reply-To: <CAPv0ZwqnQQhdx4xAjzTF8gPMTuiawfydZpO3YH3S6_4wOq6kQw@mail.gmail.com>
References: <CAPv0ZwpN8B5xysJvD9O2gboOFy4vNSDBtLqWgK9ftyDyPJ+QeA@mail.gmail.com>
 <6C609AD4-4546-4943-BEA0-BDBA8015A6B2@ionic.com>
 <CAPv0Zwr_QS73FqA7PFOYh-Whf3swhGJUcrHNBQ_tMFFLU53HKQ@mail.gmail.com>
 <8590B55B-1501-4D0D-AA7E-FA731716CB19@ionic.com>
 <CAPv0ZwqnQQhdx4xAjzTF8gPMTuiawfydZpO3YH3S6_4wOq6kQw@mail.gmail.com>
Message-ID: <B797DDBE-67B2-4DD6-85B5-B79CEBBA5796@ionic.com>

This is a shot in the dark, but if I remember correctly, building CMake requires a separate version of CMake in order to bootstrap itself. So when you run ccmake (or cmake-gui) to configure the new version of CMake you?re trying to build, there might be some Boolean option in there that will disable doc generation completely.



Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309




From: Homero Cardoso de Almeida <homerocda at gmail.com>
Date: Tuesday, October 25, 2016 at 9:28 AM
To: Parag Chandra <parag at ionicsecurity.com>, "cmake at cmake.org" <cmake at cmake.org>
Subject: Re: [EXTERNAL]: [CMake] FindProtobuf in specified dirs

Actually, I'm trying to compile cmake 3.0.2 now.

I did exactly that for protobuffers, and it compiled file. It's just the package config file that still requires 2.8.12 and I'm not sure of the consequences of changing that. So I'm trying to build 3.0.2 on squeeze now, and having a hard time building the docs because of sphinx. If I could skip the docs, that would be fantastic.

Thanks,
Homero

Em ter, 25 de out de 2016 ?s 11:23, Parag Chandra <parag at ionicsecurity.com<mailto:parag at ionicsecurity.com>> escreveu:
I actually haven?t ever tried to build protobuffers myself, so I can?t comment on its doc generation or sphinx dependency. Sorry if this seems obvious, but have you tried modifying protobuffer?s CMakeLists.txt file so that it uses the same 2.8.9 CMake you are using? 2.8.12 may not be that far off from 2.8.9; it just might be the version of CMake they happened to download at the time, rather than a hard requirement on it.



Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410<tel:+1%20919-824-1410>

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309




From: Homero Cardoso de Almeida <homerocda at gmail.com<mailto:homerocda at gmail.com>>
Date: Tuesday, October 25, 2016 at 8:06 AM
To: Parag Chandra <parag at ionicsecurity.com<mailto:parag at ionicsecurity.com>>, "cmake at cmake.org<mailto:cmake at cmake.org>" <cmake at cmake.org<mailto:cmake at cmake.org>>
Subject: Re: [EXTERNAL]: [CMake] FindProtobuf in specified dirs

Thanks for your help.

I was able to download and compile protobuffers 2.7 using cmake, however the cmake config for protobuffers is fixed for 2.8.12, while I need it to work with cmake 2.8.9 as it's going to run in system frozen in Debian Squeeze (Squeeze actually defaults on cmake 2.8.2 and I got it to install 2.8.9 from Wheezy).

Currently I'm trying to create a debian package from cmake 3.0.2 on squeeze, but I'm having a hard time due to dependencies on sphinx. Do you have any ideas on how to circumvent the doc generation?

Thanks and regards,
Homero.

Em qui, 20 de out de 2016 ?s 17:05, Parag Chandra <parag at ionicsecurity.com<mailto:parag at ionicsecurity.com>> escreveu:
I believe the protobuf-config.cmake.in<http://protobuf-config.cmake.in> generates a protobuf-config.cmake file once you actually use CMake to build protobuf itself.



Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410<tel:+1%20919-824-1410>

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309




From: CMake <cmake-bounces at cmake.org<mailto:cmake-bounces at cmake.org>> on behalf of Homero Cardoso de Almeida <homerocda at gmail.com<mailto:homerocda at gmail.com>>
Date: Thursday, October 20, 2016 at 2:56 PM
To: "cmake at cmake.org<mailto:cmake at cmake.org>" <cmake at cmake.org<mailto:cmake at cmake.org>>
Subject: [EXTERNAL]: [CMake] FindProtobuf in specified dirs

Hello,

I'm working on enhancing the build process in my company by using CMake, and I'm having trouble to have it find the Google Protocol Buffers binary and libraries in a specific directory in my workspace.

Due to several reasons, we cannot install protobuffers directly in our environment, so I have it download and unpack a zip file with the protobuffer library and header files in a directory in my home folder. However, when I use the find_package directive giving said folder as a hint it complains that it could not find a protobuf-config.cmake file and fails. I couldn't find any such file anywhere, the only thing coming close is a "protobuf-config.cmake.in<http://protobuf-config.cmake.in>" in the protobuf source tree and I don't know if I can use that.

Do I have to provide my own protobuf-config.cmake file, or I'm using it completely wrong?

We are frozen in protocol buffers 2.4.1. I guess we can upgrade to 2.7.0, but we can't use 3.0.x.

Thanks,
Homero.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/70f49254/attachment-0001.html>

From parag at ionicsecurity.com  Tue Oct 25 09:23:02 2016
From: parag at ionicsecurity.com (Parag Chandra)
Date: Tue, 25 Oct 2016 13:23:02 +0000
Subject: [CMake] [EXTERNAL]:  FindProtobuf in specified dirs
In-Reply-To: <CAPv0Zwr_QS73FqA7PFOYh-Whf3swhGJUcrHNBQ_tMFFLU53HKQ@mail.gmail.com>
References: <CAPv0ZwpN8B5xysJvD9O2gboOFy4vNSDBtLqWgK9ftyDyPJ+QeA@mail.gmail.com>
 <6C609AD4-4546-4943-BEA0-BDBA8015A6B2@ionic.com>
 <CAPv0Zwr_QS73FqA7PFOYh-Whf3swhGJUcrHNBQ_tMFFLU53HKQ@mail.gmail.com>
Message-ID: <8590B55B-1501-4D0D-AA7E-FA731716CB19@ionic.com>

I actually haven?t ever tried to build protobuffers myself, so I can?t comment on its doc generation or sphinx dependency. Sorry if this seems obvious, but have you tried modifying protobuffer?s CMakeLists.txt file so that it uses the same 2.8.9 CMake you are using? 2.8.12 may not be that far off from 2.8.9; it just might be the version of CMake they happened to download at the time, rather than a hard requirement on it.



Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309




From: Homero Cardoso de Almeida <homerocda at gmail.com>
Date: Tuesday, October 25, 2016 at 8:06 AM
To: Parag Chandra <parag at ionicsecurity.com>, "cmake at cmake.org" <cmake at cmake.org>
Subject: Re: [EXTERNAL]: [CMake] FindProtobuf in specified dirs

Thanks for your help.

I was able to download and compile protobuffers 2.7 using cmake, however the cmake config for protobuffers is fixed for 2.8.12, while I need it to work with cmake 2.8.9 as it's going to run in system frozen in Debian Squeeze (Squeeze actually defaults on cmake 2.8.2 and I got it to install 2.8.9 from Wheezy).

Currently I'm trying to create a debian package from cmake 3.0.2 on squeeze, but I'm having a hard time due to dependencies on sphinx. Do you have any ideas on how to circumvent the doc generation?

Thanks and regards,
Homero.

Em qui, 20 de out de 2016 ?s 17:05, Parag Chandra <parag at ionicsecurity.com<mailto:parag at ionicsecurity.com>> escreveu:
I believe the protobuf-config.cmake.in<http://protobuf-config.cmake.in> generates a protobuf-config.cmake file once you actually use CMake to build protobuf itself.



Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410<tel:+1%20919-824-1410>

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309




From: CMake <cmake-bounces at cmake.org<mailto:cmake-bounces at cmake.org>> on behalf of Homero Cardoso de Almeida <homerocda at gmail.com<mailto:homerocda at gmail.com>>
Date: Thursday, October 20, 2016 at 2:56 PM
To: "cmake at cmake.org<mailto:cmake at cmake.org>" <cmake at cmake.org<mailto:cmake at cmake.org>>
Subject: [EXTERNAL]: [CMake] FindProtobuf in specified dirs

Hello,

I'm working on enhancing the build process in my company by using CMake, and I'm having trouble to have it find the Google Protocol Buffers binary and libraries in a specific directory in my workspace.

Due to several reasons, we cannot install protobuffers directly in our environment, so I have it download and unpack a zip file with the protobuffer library and header files in a directory in my home folder. However, when I use the find_package directive giving said folder as a hint it complains that it could not find a protobuf-config.cmake file and fails. I couldn't find any such file anywhere, the only thing coming close is a "protobuf-config.cmake.in<http://protobuf-config.cmake.in>" in the protobuf source tree and I don't know if I can use that.

Do I have to provide my own protobuf-config.cmake file, or I'm using it completely wrong?

We are frozen in protocol buffers 2.4.1. I guess we can upgrade to 2.7.0, but we can't use 3.0.x.

Thanks,
Homero.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/547522f8/attachment.html>

From parag at ionicsecurity.com  Tue Oct 25 10:48:01 2016
From: parag at ionicsecurity.com (Parag Chandra)
Date: Tue, 25 Oct 2016 14:48:01 +0000
Subject: [CMake] [EXTERNAL]: CMake integration in Gradle (Android Studio)
In-Reply-To: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>
References: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>
Message-ID: <7FEEC5BE-25CE-42C4-AEFA-5356C12A4A29@ionic.com>

Hi Robert,

I?ve been struggling with the same thing. My cross-platform build already uses a combination of CMake and Gradle, which enables IDE integration on all supported platforms except Android. When I started this project about 3 years ago, there weren?t any real options for native code development on Android inside an IDE, so I initially went down the same Ant/Eclipse path as you, running separate commands to build the native portions via CMake and putting the .so files into the right place so Eclipse would find them. Even managed to get debugging to work with a little coaxing.

Fast forward a couple of years and Google has completely abandoned Ant+Eclipse, so my custom workflow is now outdated. There is now also an explosion of options for working with C++ code on Android, including:

? A first-party plug-in for Visual Studio from Microsoft;
? VisualGDB;
? WinGDB;
? Gradle?s own C/C++ support via its Native Build System;
? Google?s own CMake support via Android Studio
? JetBrains CLion

I spoke to a few people at Google when I was at I/O this year, and I got the general impression that CMake+Gradle+Android Studio is only going to work if you?re targeting Android exclusively. If you want to continue targeting multiple platforms, you?re still kind of on your own, and your experience with their custom version of CMake supports that impression.

I haven?t had time to explore all of the options I listed above to try to figure out which would provide the best workflow, but my general sense is that Android Studio needs to continue to treat your CMake build as a black box. Fortunately, there are a lot of extension points with the Gradle-based build that underpins all Android Studio projects, so you can effectively create pre-build steps that will essentially cmake ?build your native code and drop the .so files into the right place, before proceeding with the managed code Android toolchain. From there, it should be possible to attach Android Studio?s managed code and native code debuggers to your running app, to concurrently debug both sides.

At this point, I?ve probably strayed too far from the intent of this mailing list, but I?m happy to discuss further with you offline.

 

Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309
 

On 10/25/16, 9:48 AM, "CMake on behalf of Robert Dailey" <cmake-bounces at cmake.org on behalf of rcdailey.lists at gmail.com> wrote:

    I'm not sure if the CMake mailing lists are the right place to ask
    this question but I thought I'd ask just in case someone has gone down
    this path or has experience with what Google/Gradle is actually trying
    to accomplish with what seems to be a hand-built version of CMake with
    custom patches that are not in upstream repositories.
    
    Prior to switching to Android Studio / Gradle, I was using Eclipse /
    Ant. The way I did CMake integration was not really integration at
    all: I generated Ninja build scripts using CMake and implemented
    custom targets to run "ant release" after all the C++ projects were
    built. I made sure that CMake copied relevant *.so files to
    appropriate directories in the Ant structure so they are packaged with
    built APKs. That's how I did my Android development.
    
    Now that I'm integrating CMake into Gradle, first annoyance I noticed
    is that I can't use CMake 3.7 (or any external installation of CMake)
    with Android Studio. It requires a version of CMake installed through
    SDK Manager. This means I can't use the new Android toolchain
    functionality built into CMake 3.7 (sad face). But this is something I
    can work around...
    
    Next I found out that stuff I'm setting in my CMake scripts, such as
    CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
    For whatever reason, Gradle is overriding these from the command line
    (I'm guessing?). So this requires me to duplicate the toolchain /
    compiler flag setup I already do in my CMake scripts now in the Gradle
    build scripts. This seems completely unnecessary and a maintenance
    burden.
    
    What I was expecting Gradle to do was essentially provide me some
    toolchain file so that CMake can find the compiler and linker to use
    and then the rest would be determined by CMake itself.
    
    Is there a way I can tell Gradle to not take so much control over
    compiler flags? I want my CMake scripts to do this. I can't imagine
    they had a good reason to do this. What have others done in this
    situation with their own Gradle + CMake integration? Looking for
    advice here, since information is sparse, especially since the Android
    Studio 2.2 CMake integration is relatively new stuff.
    -- 
    
    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
    


From imbacen at gmail.com  Tue Oct 25 10:59:31 2016
From: imbacen at gmail.com (cen)
Date: Tue, 25 Oct 2016 16:59:31 +0200
Subject: [CMake] CPack DEB version info is missing patch level
Message-ID: <9a76b3dc-7bf3-fa9c-2f3e-444771499c39@gmail.com>

Hi

I am not sure if this is a CPack thing or a deb thing.

my CmakeLists.txt:

SET(VERSION_MAJOR "1")
SET(VERSION_MINOR "3")
SET(VERSION_PATCH "2")

SET(CPACK_PACKAGE_VERSION_MAJOR "${VERSION_MAJOR}")
SET(CPACK_PACKAGE_VERSION_MINOR "${VERSION_MINOR}")
SET(CPACK_PACKAGE_VERSION_PATCH "${VERSION_PATCH}")


Produced RPM, running rpm -qip my.rpm results in:

Version     : 1.3.2


Produced DEB, running dpkg-deb -I my.deb results in:

Version: 1.3


Why is patch level not baked into the DEB but it is in RPM? If install 
the deb, soft links have the proper patch level version so I guess it is 
ultimately ok but kinda annoying.


Best regards, cen



From homerocda at gmail.com  Tue Oct 25 11:10:16 2016
From: homerocda at gmail.com (Homero Cardoso de Almeida)
Date: Tue, 25 Oct 2016 15:10:16 +0000
Subject: [CMake] [EXTERNAL]:  FindProtobuf in specified dirs
In-Reply-To: <B797DDBE-67B2-4DD6-85B5-B79CEBBA5796@ionic.com>
References: <CAPv0ZwpN8B5xysJvD9O2gboOFy4vNSDBtLqWgK9ftyDyPJ+QeA@mail.gmail.com>
 <6C609AD4-4546-4943-BEA0-BDBA8015A6B2@ionic.com>
 <CAPv0Zwr_QS73FqA7PFOYh-Whf3swhGJUcrHNBQ_tMFFLU53HKQ@mail.gmail.com>
 <8590B55B-1501-4D0D-AA7E-FA731716CB19@ionic.com>
 <CAPv0ZwqnQQhdx4xAjzTF8gPMTuiawfydZpO3YH3S6_4wOq6kQw@mail.gmail.com>
 <B797DDBE-67B2-4DD6-85B5-B79CEBBA5796@ionic.com>
Message-ID: <CAPv0Zwq_50NgD3nBBJoE08PrFBars-6kVtbss-ZA8E1mK10vyw@mail.gmail.com>

That did not work. Even though I set the BUILD_DOCUMENTATION flag in the
debian/rules script, I cannot get it to skip doc build. Or maybe I'm
writing in the wrong folder, I don't know. :(


Em ter, 25 de out de 2016 ?s 11:35, Parag Chandra <parag at ionicsecurity.com>
escreveu:

> This is a shot in the dark, but if I remember correctly, building CMake
> requires a separate version of CMake in order to bootstrap itself. So when
> you run ccmake (or cmake-gui) to configure the new version of CMake you?re
> trying to build, there might be some Boolean option in there that will
> disable doc generation completely.
>
>
>
>
>
>
>
> *Parag Chandra *Technical Lead, Mobile Team
> Mobile: +1.919.824.1410 <+1%20919-824-1410>
>
> Ionic Security Inc.
> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309
>
>
>
>
>
> *From: *Homero Cardoso de Almeida <homerocda at gmail.com>
> *Date: *Tuesday, October 25, 2016 at 9:28 AM
>
>
> *To: *Parag Chandra <parag at ionicsecurity.com>, "cmake at cmake.org" <
> cmake at cmake.org>
> *Subject: *Re: [EXTERNAL]: [CMake] FindProtobuf in specified dirs
>
>
>
> Actually, I'm trying to compile cmake 3.0.2 now.
>
>
>
> I did exactly that for protobuffers, and it compiled file. It's just the
> package config file that still requires 2.8.12 and I'm not sure of the
> consequences of changing that. So I'm trying to build 3.0.2 on squeeze now,
> and having a hard time building the docs because of sphinx. If I could skip
> the docs, that would be fantastic.
>
>
>
> Thanks,
>
> Homero
>
>
>
> Em ter, 25 de out de 2016 ?s 11:23, Parag Chandra <parag at ionicsecurity.com>
> escreveu:
>
> I actually haven?t ever tried to build protobuffers myself, so I can?t
> comment on its doc generation or sphinx dependency. Sorry if this seems
> obvious, but have you tried modifying protobuffer?s CMakeLists.txt file so
> that it uses the same 2.8.9 CMake you are using? 2.8.12 may not be that far
> off from 2.8.9; it just might be the version of CMake they happened to
> download at the time, rather than a hard requirement on it.
>
>
>
>
>
>
> *Parag Chandra*
> Technical Lead, Mobile Team
> Mobile: +1.919.824.1410 <+1%20919-824-1410>
>
> Ionic Security Inc.
> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309
>
>
>
>
>
> *From: *Homero Cardoso de Almeida <homerocda at gmail.com>
> *Date: *Tuesday, October 25, 2016 at 8:06 AM
> *To: *Parag Chandra <parag at ionicsecurity.com>, "cmake at cmake.org" <
> cmake at cmake.org>
> *Subject: *Re: [EXTERNAL]: [CMake] FindProtobuf in specified dirs
>
>
>
> Thanks for your help.
>
>
>
> I was able to download and compile protobuffers 2.7 using cmake, however
> the cmake config for protobuffers is fixed for 2.8.12, while I need it to
> work with cmake 2.8.9 as it's going to run in system frozen in Debian
> Squeeze (Squeeze actually defaults on cmake 2.8.2 and I got it to install
> 2.8.9 from Wheezy).
>
>
>
> Currently I'm trying to create a debian package from cmake 3.0.2 on
> squeeze, but I'm having a hard time due to dependencies on sphinx. Do you
> have any ideas on how to circumvent the doc generation?
>
>
>
> Thanks and regards,
>
> Homero.
>
>
>
> Em qui, 20 de out de 2016 ?s 17:05, Parag Chandra <parag at ionicsecurity.com>
> escreveu:
>
> I believe the protobuf-config.cmake.in generates a protobuf-config.cmake
> file once you actually use CMake to build protobuf itself.
>
>
>
>
>
>
> *Parag Chandra*
> Technical Lead, Mobile Team
> Mobile: +1.919.824.1410 <+1%20919-824-1410>
>
> Ionic Security Inc.
> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309
>
>
>
>
>
> *From: *CMake <cmake-bounces at cmake.org> on behalf of Homero Cardoso de
> Almeida <homerocda at gmail.com>
> *Date: *Thursday, October 20, 2016 at 2:56 PM
> *To: *"cmake at cmake.org" <cmake at cmake.org>
> *Subject: *[EXTERNAL]: [CMake] FindProtobuf in specified dirs
>
>
>
> Hello,
>
>
>
> I'm working on enhancing the build process in my company by using CMake,
> and I'm having trouble to have it find the Google Protocol Buffers binary
> and libraries in a specific directory in my workspace.
>
>
>
> Due to several reasons, we cannot install protobuffers directly in our
> environment, so I have it download and unpack a zip file with the
> protobuffer library and header files in a directory in my home folder.
> However, when I use the find_package directive giving said folder as a hint
> it complains that it could not find a protobuf-config.cmake file and fails.
> I couldn't find any such file anywhere, the only thing coming close is a "
> protobuf-config.cmake.in" in the protobuf source tree and I don't know if
> I can use that.
>
>
>
> Do I have to provide my own protobuf-config.cmake file, or I'm using it
> completely wrong?
>
>
>
> We are frozen in protocol buffers 2.4.1. I guess we can upgrade to 2.7.0,
> but we can't use 3.0.x.
>
>
>
> Thanks,
>
> Homero.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/b5f27c22/attachment-0001.html>

From parag at ionicsecurity.com  Tue Oct 25 12:24:38 2016
From: parag at ionicsecurity.com (Parag Chandra)
Date: Tue, 25 Oct 2016 16:24:38 +0000
Subject: [CMake] [EXTERNAL]:  FindProtobuf in specified dirs
In-Reply-To: <CAPv0Zwq_50NgD3nBBJoE08PrFBars-6kVtbss-ZA8E1mK10vyw@mail.gmail.com>
References: <CAPv0ZwpN8B5xysJvD9O2gboOFy4vNSDBtLqWgK9ftyDyPJ+QeA@mail.gmail.com>
 <6C609AD4-4546-4943-BEA0-BDBA8015A6B2@ionic.com>
 <CAPv0Zwr_QS73FqA7PFOYh-Whf3swhGJUcrHNBQ_tMFFLU53HKQ@mail.gmail.com>
 <8590B55B-1501-4D0D-AA7E-FA731716CB19@ionic.com>
 <CAPv0ZwqnQQhdx4xAjzTF8gPMTuiawfydZpO3YH3S6_4wOq6kQw@mail.gmail.com>
 <B797DDBE-67B2-4DD6-85B5-B79CEBBA5796@ionic.com>
 <CAPv0Zwq_50NgD3nBBJoE08PrFBars-6kVtbss-ZA8E1mK10vyw@mail.gmail.com>
Message-ID: <8D923799-22B6-4D59-996E-F46970ECD0A6@ionic.com>

I just pulled down the latest source, ran CMake on it, and then ran ccmake to view the options available. Mine shows several SPHINX-related options, and since SPHINX_EXECUTABLE could not be found, all the other SPHINX options have been set to OFF. Can you verify the same on your end? It seems to me that if no SPHINX output formats are enabled, then doc generation should be skipped.



Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309




From: Homero Cardoso de Almeida <homerocda at gmail.com>
Date: Tuesday, October 25, 2016 at 11:10 AM
To: Parag Chandra <parag at ionicsecurity.com>, "cmake at cmake.org" <cmake at cmake.org>
Subject: Re: [EXTERNAL]: [CMake] FindProtobuf in specified dirs

That did not work. Even though I set the BUILD_DOCUMENTATION flag in the debian/rules script, I cannot get it to skip doc build. Or maybe I'm writing in the wrong folder, I don't know. :(


Em ter, 25 de out de 2016 ?s 11:35, Parag Chandra <parag at ionicsecurity.com<mailto:parag at ionicsecurity.com>> escreveu:
This is a shot in the dark, but if I remember correctly, building CMake requires a separate version of CMake in order to bootstrap itself. So when you run ccmake (or cmake-gui) to configure the new version of CMake you?re trying to build, there might be some Boolean option in there that will disable doc generation completely.



Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410<tel:+1%20919-824-1410>

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309




From: Homero Cardoso de Almeida <homerocda at gmail.com<mailto:homerocda at gmail.com>>
Date: Tuesday, October 25, 2016 at 9:28 AM

To: Parag Chandra <parag at ionicsecurity.com<mailto:parag at ionicsecurity.com>>, "cmake at cmake.org<mailto:cmake at cmake.org>" <cmake at cmake.org<mailto:cmake at cmake.org>>
Subject: Re: [EXTERNAL]: [CMake] FindProtobuf in specified dirs

Actually, I'm trying to compile cmake 3.0.2 now.

I did exactly that for protobuffers, and it compiled file. It's just the package config file that still requires 2.8.12 and I'm not sure of the consequences of changing that. So I'm trying to build 3.0.2 on squeeze now, and having a hard time building the docs because of sphinx. If I could skip the docs, that would be fantastic.

Thanks,
Homero

Em ter, 25 de out de 2016 ?s 11:23, Parag Chandra <parag at ionicsecurity.com<mailto:parag at ionicsecurity.com>> escreveu:
I actually haven?t ever tried to build protobuffers myself, so I can?t comment on its doc generation or sphinx dependency. Sorry if this seems obvious, but have you tried modifying protobuffer?s CMakeLists.txt file so that it uses the same 2.8.9 CMake you are using? 2.8.12 may not be that far off from 2.8.9; it just might be the version of CMake they happened to download at the time, rather than a hard requirement on it.



Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410<tel:+1%20919-824-1410>

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309




From: Homero Cardoso de Almeida <homerocda at gmail.com<mailto:homerocda at gmail.com>>
Date: Tuesday, October 25, 2016 at 8:06 AM
To: Parag Chandra <parag at ionicsecurity.com<mailto:parag at ionicsecurity.com>>, "cmake at cmake.org<mailto:cmake at cmake.org>" <cmake at cmake.org<mailto:cmake at cmake.org>>
Subject: Re: [EXTERNAL]: [CMake] FindProtobuf in specified dirs

Thanks for your help.

I was able to download and compile protobuffers 2.7 using cmake, however the cmake config for protobuffers is fixed for 2.8.12, while I need it to work with cmake 2.8.9 as it's going to run in system frozen in Debian Squeeze (Squeeze actually defaults on cmake 2.8.2 and I got it to install 2.8.9 from Wheezy).

Currently I'm trying to create a debian package from cmake 3.0.2 on squeeze, but I'm having a hard time due to dependencies on sphinx. Do you have any ideas on how to circumvent the doc generation?

Thanks and regards,
Homero.

Em qui, 20 de out de 2016 ?s 17:05, Parag Chandra <parag at ionicsecurity.com<mailto:parag at ionicsecurity.com>> escreveu:
I believe the protobuf-config.cmake.in<http://protobuf-config.cmake.in> generates a protobuf-config.cmake file once you actually use CMake to build protobuf itself.



Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410<tel:+1%20919-824-1410>

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309




From: CMake <cmake-bounces at cmake.org<mailto:cmake-bounces at cmake.org>> on behalf of Homero Cardoso de Almeida <homerocda at gmail.com<mailto:homerocda at gmail.com>>
Date: Thursday, October 20, 2016 at 2:56 PM
To: "cmake at cmake.org<mailto:cmake at cmake.org>" <cmake at cmake.org<mailto:cmake at cmake.org>>
Subject: [EXTERNAL]: [CMake] FindProtobuf in specified dirs

Hello,

I'm working on enhancing the build process in my company by using CMake, and I'm having trouble to have it find the Google Protocol Buffers binary and libraries in a specific directory in my workspace.

Due to several reasons, we cannot install protobuffers directly in our environment, so I have it download and unpack a zip file with the protobuffer library and header files in a directory in my home folder. However, when I use the find_package directive giving said folder as a hint it complains that it could not find a protobuf-config.cmake file and fails. I couldn't find any such file anywhere, the only thing coming close is a "protobuf-config.cmake.in<http://protobuf-config.cmake.in>" in the protobuf source tree and I don't know if I can use that.

Do I have to provide my own protobuf-config.cmake file, or I'm using it completely wrong?

We are frozen in protocol buffers 2.4.1. I guess we can upgrade to 2.7.0, but we can't use 3.0.x.

Thanks,
Homero.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/977758d6/attachment-0001.html>

From bballet at ivsweb.com  Tue Oct 25 12:41:01 2016
From: bballet at ivsweb.com (Benjamin Ballet)
Date: Tue, 25 Oct 2016 18:41:01 +0200
Subject: [CMake] ExternalProject_Add : set the location of CMakeLists.txt
Message-ID: <CAJoWGD0b0i-xTAqGuU79L1OWMsWv_bc-p_UGtJWNzrDsr-bMsA@mail.gmail.com>

Hi,

I'm trying to get GLEW (https://github.com/nigels-com/glew) with
ExternalProject_Add
It's buildable with cmake but the CMakeLists.txt is in build/cmake
directory.

Is there a way to specify the directory of the CMakeLists.txt file ?

If I change SOURCE_DIR it will only clone the repo in SOURCE_DIR and still
run the cmake command in repo root.

-- 
*Benjamin BALLET*
Ing?nieur R&D

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard T?l* :  01 44 69 37 37
*>* www.activisu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/9b7ec5df/attachment.html>

From konstantin at podsvirov.pro  Tue Oct 25 13:24:30 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Tue, 25 Oct 2016 20:24:30 +0300
Subject: [CMake] ExternalProject_Add : set the location of CMakeLists.txt
In-Reply-To: <CAJoWGD0b0i-xTAqGuU79L1OWMsWv_bc-p_UGtJWNzrDsr-bMsA@mail.gmail.com>
References: <CAJoWGD0b0i-xTAqGuU79L1OWMsWv_bc-p_UGtJWNzrDsr-bMsA@mail.gmail.com>
Message-ID: <2359531477416270@web1o.yandex.ru>

Hello, Benjamin.

25.10.2016, 19:41, "Benjamin Ballet via CMake" <cmake at cmake.org>:
> Hi,
>
> I'm trying to get GLEW (https://github.com/nigels-com/glew) with ExternalProject_Add
> It's buildable with cmake but the CMakeLists.txt is in build/cmake directory.
>
> Is there a way to specify the directory of the CMakeLists.txt file ?
>
> If I change SOURCE_DIR it will only clone the repo in SOURCE_DIR and still run the cmake command in repo root.
>
> --
> Benjamin BALLET
> Ing?nieur R&D
>
> ACTIVISU
> 19, rue Klock?- 92110 Clichy
>> Standard T?l?: ?01 44 69 37 37
>>?www.activisu.com
> ,--

Try it:

ExternalProject_Add(
  ...
  SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/source
  ...
  CONFIGURE_COMMAND ${CMAKE_COMMAND} [additional args...] ${CMAKE_CURRENT_BINARY_DIR}/source/build/cmake
  ...)

---
Regards,
Konstantin Podsvirov

From konstantin at podsvirov.pro  Tue Oct 25 13:54:35 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Tue, 25 Oct 2016 20:54:35 +0300
Subject: [CMake] ExternalProject_Add : set the location of CMakeLists.txt
In-Reply-To: <2359531477416270@web1o.yandex.ru>
References: <CAJoWGD0b0i-xTAqGuU79L1OWMsWv_bc-p_UGtJWNzrDsr-bMsA@mail.gmail.com>
 <2359531477416270@web1o.yandex.ru>
Message-ID: <2137731477418075@web29h.yandex.ru>

Hello again.

25.10.2016, 20:31, "Konstantin Podsvirov" <konstantin at podsvirov.pro>:
> Hello, Benjamin.
>
> 25.10.2016, 19:41, "Benjamin Ballet via CMake" <cmake at cmake.org>:
>> ?Hi,
>>
>> ?I'm trying to get GLEW (https://github.com/nigels-com/glew) with ExternalProject_Add
>> ?It's buildable with cmake but the CMakeLists.txt is in build/cmake directory.
>>
>> ?Is there a way to specify the directory of the CMakeLists.txt file ?
>>
>> ?If I change SOURCE_DIR it will only clone the repo in SOURCE_DIR and still run the cmake command in repo root.
>>
>> ?--
>> ?Benjamin BALLET
>> ?Ing?nieur R&D
>>
>> ?ACTIVISU
>> ?19, rue Klock?- 92110 Clichy
>>> ?Standard T?l?: ?01 44 69 37 37
>>> ?www.activisu.com
>> ?,--
>
> Try it:
>
> ExternalProject_Add(
> ??...
> ??SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/source
> ??...
> ??CONFIGURE_COMMAND ${CMAKE_COMMAND} [additional args...] ${CMAKE_CURRENT_BINARY_DIR}/source/build/cmake
> ??...)


Or try it:

ExternalProject_Add(
??...
??SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/source
??...
??CONFIGURE_COMMAND ${CMAKE_COMMAND} [additional args...]
   -DCMAKE_GENERATOR=${CMAKE_GENERATOR}
   -DCMAKE_GENERATOR_PLATFORM=${CMAKE_GENERATOR_PLATFORM}
   -DCMAKE_GENERATOR_TOOLSET=${CMAKE_GENERATOR_TOOLSET}
    ${CMAKE_CURRENT_BINARY_DIR}/source/build/cmake
??...)

--
Regards,
Konstantin Podsvirov

From boxerab at gmail.com  Tue Oct 25 15:04:48 2016
From: boxerab at gmail.com (Aaron Boxer)
Date: Tue, 25 Oct 2016 15:04:48 -0400
Subject: [CMake] cmake - ified libjpeg source code
Message-ID: <CAK8GPyB0+cr_25YhbxQe0hd_JEyaA2+3Vn_QKUQ5ck7yFF+SUw@mail.gmail.com>

Hello,

I am looking for a cmake-ified jpeg library to add to another cmake project.
Any recommendations?

Thanks,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/ac51ed85/attachment.html>

From domen.vrankar at gmail.com  Tue Oct 25 15:48:32 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 25 Oct 2016 21:48:32 +0200
Subject: [CMake] CPack DEB version info is missing patch level
In-Reply-To: <9a76b3dc-7bf3-fa9c-2f3e-444771499c39@gmail.com>
References: <9a76b3dc-7bf3-fa9c-2f3e-444771499c39@gmail.com>
Message-ID: <CAKgx6B+u=A00-ja-6TmzsY7oY147oj0Z0VK5dobdUmuDfzvf_Q@mail.gmail.com>

2016-10-25 16:59 GMT+02:00 cen <imbacen at gmail.com>:

>
> Why is patch level not baked into the DEB but it is in RPM? If install the
> deb, soft links have the proper patch level version so I guess it is
> ultimately ok but kinda annoying.
>

Which version of CPack are you using?

I can't reproduce this even with old CMake version 3.0.2 and minimal
CMakeLists.txt:

#------

cmake_minimum_required(VERSION 3.0)
project(test)

install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/CMakeLists.txt
    DESTINATION dest)

set(CPACK_PACKAGE_VERSION_MAJOR 1)
set(CPACK_PACKAGE_VERSION_MINOR 2)
set(CPACK_PACKAGE_VERSION_PATCH 3)
set(CPACK_PACKAGE_CONTACT "Test <test at test.com>")

include(CPack)

#------

cmake -D CPACK_BINARY_DEB:bool=ON ..
make package
dpkg-deb -I test-1.2.3-Linux.deb

result: Version: 1.2.3


Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/fb2d67af/attachment.html>

From boud at valdyas.org  Tue Oct 25 15:59:27 2016
From: boud at valdyas.org (Boudewijn Rempt)
Date: Tue, 25 Oct 2016 21:59:27 +0200 (CEST)
Subject: [CMake] cmake - ified libjpeg source code
In-Reply-To: <CAK8GPyB0+cr_25YhbxQe0hd_JEyaA2+3Vn_QKUQ5ck7yFF+SUw@mail.gmail.com>
References: <CAK8GPyB0+cr_25YhbxQe0hd_JEyaA2+3Vn_QKUQ5ck7yFF+SUw@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.1610252159130.26049@calcifer.valdyas.org>

On Tue, 25 Oct 2016, Aaron Boxer wrote:

> Hello,
> 
> I am looking for a cmake-ified jpeg library to add to another cmake project.
> Any recommendations?

I get mine here:

https://phabricator.kde.org/diffusion/EMERGE/browse/master/portage/win32libs/jpeg/

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

From imbacen at gmail.com  Tue Oct 25 16:05:34 2016
From: imbacen at gmail.com (cen)
Date: Tue, 25 Oct 2016 22:05:34 +0200
Subject: [CMake] CPack DEB version info is missing patch level
In-Reply-To: <CAKgx6B+u=A00-ja-6TmzsY7oY147oj0Z0VK5dobdUmuDfzvf_Q@mail.gmail.com>
References: <9a76b3dc-7bf3-fa9c-2f3e-444771499c39@gmail.com>
 <CAKgx6B+u=A00-ja-6TmzsY7oY147oj0Z0VK5dobdUmuDfzvf_Q@mail.gmail.com>
Message-ID: <b78fc97b-5264-0ac1-2550-9121d9c7b228@gmail.com>

Sorry for wasting your time, it does work indeed. I forgot to pull the 
correct version of CmakeLists.txt on my debian machine..

Thank you.


Domen Vrankar je 25. 10. 2016 ob 21:48 napisal:
> 2016-10-25 16:59 GMT+02:00 cen <imbacen at gmail.com 
> <mailto:imbacen at gmail.com>>:
>
>
>     Why is patch level not baked into the DEB but it is in RPM? If
>     install the deb, soft links have the proper patch level version so
>     I guess it is ultimately ok but kinda annoying.
>
>
> Which version of CPack are you using?
>
> I can't reproduce this even with old CMake version 3.0.2 and minimal 
> CMakeLists.txt:
>
> #------
>
> cmake_minimum_required(VERSION 3.0)
> project(test)
>
> install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/CMakeLists.txt
>     DESTINATION dest)
>
> set(CPACK_PACKAGE_VERSION_MAJOR 1)
> set(CPACK_PACKAGE_VERSION_MINOR 2)
> set(CPACK_PACKAGE_VERSION_PATCH 3)
> set(CPACK_PACKAGE_CONTACT "Test <test at test.com <mailto:test at test.com>>")
>
> include(CPack)
>
> #------
>
> cmake -D CPACK_BINARY_DEB:bool=ON ..
> make package
> dpkg-deb -I test-1.2.3-Linux.deb
>
> result: Version: 1.2.3
>
>
> Regards,
> Domen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/3c8878f3/attachment-0001.html>

From jack.stalnaker at gmail.com  Tue Oct 25 16:26:23 2016
From: jack.stalnaker at gmail.com (Jack Stalnaker)
Date: Tue, 25 Oct 2016 15:26:23 -0500
Subject: [CMake] make install gives cmake link errors for libstdc++
Message-ID: <CAOGUJ6EXymRvABUJuQM-oqZDg74Pw1qBH3O95p6w_sSx+EHvtQ@mail.gmail.com>

I'm having an odd problem. I built and installed cmake in a non-standard
location, using a compiler different from the system compiler on linux.
Cmake compiles without complaint, and installs without complaint. When I
attempt to build a piece of software using cmake, the configuration and
build stages are fine. However, when I run 'make install', I get errors
similar to:

/my/version/cmake: /usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.20' not
found (required by cmake)

The funny thing is, though /my/version/cmake is not linked to
/usr/lib64/libstdc++.so.6. Instead, it's linked to
/my/version/libstdc++.so.6, as I intended. I've verified this with ldd,
which only shows the latter expected results. /my/version/libstdc++.so.6 is
in the library path, too, Not sure what's going on. Can someone help?

--Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/adfadec6/attachment.html>

From tiagomacarios at gmail.com  Tue Oct 25 22:36:11 2016
From: tiagomacarios at gmail.com (Tiago Macarios)
Date: Tue, 25 Oct 2016 19:36:11 -0700
Subject: [CMake] clean custom_target
Message-ID: <CAKLVFYEMNjaBMGWBzRiVNJKEL-3NGQ8HDg1sPgHU0cmwFZZurw@mail.gmail.com>

Hi,

Is there a way to have a command to be run during a clean?

I have a custom_target which does a fair bit of things and it also has the
ability to clean up after itself. So conceptually something like this is
what I am looking for:

add_custom_target(Name ALL
    COMMAND command
    COMMAND_CLEAN command -clean
)


Tiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161025/bd5b867a/attachment.html>

From petr.kmoch at gmail.com  Wed Oct 26 01:59:54 2016
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Wed, 26 Oct 2016 07:59:54 +0200
Subject: [CMake] clean custom_target
In-Reply-To: <CAKLVFYEMNjaBMGWBzRiVNJKEL-3NGQ8HDg1sPgHU0cmwFZZurw@mail.gmail.com>
References: <CAKLVFYEMNjaBMGWBzRiVNJKEL-3NGQ8HDg1sPgHU0cmwFZZurw@mail.gmail.com>
Message-ID: <CAKohaZfzAksxWamT67qm=UL8wU1ysqE2+k7NORZ59exA96WtpQ@mail.gmail.com>

Hi Tiago.

The best I can think of is the directory property
ADDITIONAL_MAKE_CLEAN_FILES:
https://cmake.org/cmake/help/latest/prop_dir/ADDITIONAL_MAKE_CLEAN_FILES.html

You can set it to a list of files which will be removed as part of running
`make clean` or its equivalent for other generators.

Petr

On 26 October 2016 at 04:36, Tiago Macarios <tiagomacarios at gmail.com> wrote:

> Hi,
>
> Is there a way to have a command to be run during a clean?
>
> I have a custom_target which does a fair bit of things and it also has the
> ability to clean up after itself. So conceptually something like this is
> what I am looking for:
>
> add_custom_target(Name ALL
>     COMMAND command
>     COMMAND_CLEAN command -clean
> )
>
>
> Tiago
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161026/715d5b7b/attachment.html>

From roman.wueger at gmx.at  Wed Oct 26 05:27:24 2016
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Wed, 26 Oct 2016 11:27:24 +0200
Subject: [CMake] iwyu and clang-tidy not working under mac os
Message-ID: <280F26CD-3681-4738-916A-E2C6CABA14C1@gmx.at>

Hello,

I set CMAKE_CXX_INCLUDE_WHAT_YOU_USE and CMAKE_CXX_CLANG_TIDY. Both work as expected with CMake 3.6.2 under linux. Under Mac OS with the same sources and the same CMake version doesn't produce any output. 

On Linux clang 3.8 is used, on Mac OS it is AppleClang 7.3.0 with clang-tidy installed from homebrew.

Any hints?

Thanks in advance

Best regards
Roman

From bballet at ivsweb.com  Wed Oct 26 05:34:23 2016
From: bballet at ivsweb.com (Benjamin Ballet)
Date: Wed, 26 Oct 2016 11:34:23 +0200
Subject: [CMake] ExternalProject_Add : set the location of CMakeLists.txt
In-Reply-To: <2137731477418075@web29h.yandex.ru>
References: <CAJoWGD0b0i-xTAqGuU79L1OWMsWv_bc-p_UGtJWNzrDsr-bMsA@mail.gmail.com>
 <2359531477416270@web1o.yandex.ru> <2137731477418075@web29h.yandex.ru>
Message-ID: <CAJoWGD3dOCUQ6FOGPYbm67uMaePBuukr-dd50ZUkTcL4hzHcNw@mail.gmail.com>

Ok I'm quiet lucky : There is what I need in CMake 3.7 (SOURCE_SUBDIR)

2016-10-25 19:54 GMT+02:00 Konstantin Podsvirov <konstantin at podsvirov.pro>:

> Hello again.
>
> 25.10.2016, 20:31, "Konstantin Podsvirov" <konstantin at podsvirov.pro>:
> > Hello, Benjamin.
> >
> > 25.10.2016, 19:41, "Benjamin Ballet via CMake" <cmake at cmake.org>:
> >>  Hi,
> >>
> >>  I'm trying to get GLEW (https://github.com/nigels-com/glew) with
> ExternalProject_Add
> >>  It's buildable with cmake but the CMakeLists.txt is in build/cmake
> directory.
> >>
> >>  Is there a way to specify the directory of the CMakeLists.txt file ?
> >>
> >>  If I change SOURCE_DIR it will only clone the repo in SOURCE_DIR and
> still run the cmake command in repo root.
> >>
> >>  --
> >>  Benjamin BALLET
> >>  Ing?nieur R&D
> >>
> >>  ACTIVISU
> >>  19, rue Klock - 92110 Clichy
> >>>  Standard T?l :  01 44 69 37 37
> >>>  www.activisu.com
> >>  ,--
> >
> > Try it:
> >
> > ExternalProject_Add(
> >   ...
> >   SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/source
> >   ...
> >   CONFIGURE_COMMAND ${CMAKE_COMMAND} [additional args...]
> ${CMAKE_CURRENT_BINARY_DIR}/source/build/cmake
> >   ...)
>
>
> Or try it:
>
> ExternalProject_Add(
>   ...
>   SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/source
>   ...
>   CONFIGURE_COMMAND ${CMAKE_COMMAND} [additional args...]
>    -DCMAKE_GENERATOR=${CMAKE_GENERATOR}
>    -DCMAKE_GENERATOR_PLATFORM=${CMAKE_GENERATOR_PLATFORM}
>    -DCMAKE_GENERATOR_TOOLSET=${CMAKE_GENERATOR_TOOLSET}
>     ${CMAKE_CURRENT_BINARY_DIR}/source/build/cmake
>   ...)
>
> --
> Regards,
> Konstantin Podsvirov
>



-- 
*Benjamin BALLET*
Ing?nieur R&D

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard T?l* :  01 44 69 37 37
*>* www.activisu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161026/7bc25b18/attachment.html>

From bballet at ivsweb.com  Wed Oct 26 05:36:35 2016
From: bballet at ivsweb.com (Benjamin Ballet)
Date: Wed, 26 Oct 2016 11:36:35 +0200
Subject: [CMake] ExternalProject_Add : set the location of CMakeLists.txt
In-Reply-To: <CAJoWGD3dOCUQ6FOGPYbm67uMaePBuukr-dd50ZUkTcL4hzHcNw@mail.gmail.com>
References: <CAJoWGD0b0i-xTAqGuU79L1OWMsWv_bc-p_UGtJWNzrDsr-bMsA@mail.gmail.com>
 <2359531477416270@web1o.yandex.ru> <2137731477418075@web29h.yandex.ru>
 <CAJoWGD3dOCUQ6FOGPYbm67uMaePBuukr-dd50ZUkTcL4hzHcNw@mail.gmail.com>
Message-ID: <CAJoWGD2KHZb-ejok7rKvF05rNWi=tu10UT-m_CN+tm3MqMr7Eg@mail.gmail.com>

It's not listed in changelog though :
https://cmake.org/cmake/help/v3.7/release/3.7.html

2016-10-26 11:34 GMT+02:00 Benjamin Ballet <bballet at ivsweb.com>:

> Ok I'm quiet lucky : There is what I need in CMake 3.7 (SOURCE_SUBDIR)
>
> 2016-10-25 19:54 GMT+02:00 Konstantin Podsvirov <konstantin at podsvirov.pro>
> :
>
>> Hello again.
>>
>> 25.10.2016, 20:31, "Konstantin Podsvirov" <konstantin at podsvirov.pro>:
>> > Hello, Benjamin.
>> >
>> > 25.10.2016, 19:41, "Benjamin Ballet via CMake" <cmake at cmake.org>:
>> >>  Hi,
>> >>
>> >>  I'm trying to get GLEW (https://github.com/nigels-com/glew) with
>> ExternalProject_Add
>> >>  It's buildable with cmake but the CMakeLists.txt is in build/cmake
>> directory.
>> >>
>> >>  Is there a way to specify the directory of the CMakeLists.txt file ?
>> >>
>> >>  If I change SOURCE_DIR it will only clone the repo in SOURCE_DIR and
>> still run the cmake command in repo root.
>> >>
>> >>  --
>> >>  Benjamin BALLET
>> >>  Ing?nieur R&D
>> >>
>> >>  ACTIVISU
>> >>  19, rue Klock - 92110 Clichy
>> >>>  Standard T?l :  01 44 69 37 37
>> >>>  www.activisu.com
>> >>  ,--
>> >
>> > Try it:
>> >
>> > ExternalProject_Add(
>> >   ...
>> >   SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/source
>> >   ...
>> >   CONFIGURE_COMMAND ${CMAKE_COMMAND} [additional args...]
>> ${CMAKE_CURRENT_BINARY_DIR}/source/build/cmake
>> >   ...)
>>
>>
>> Or try it:
>>
>> ExternalProject_Add(
>>   ...
>>   SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/source
>>   ...
>>   CONFIGURE_COMMAND ${CMAKE_COMMAND} [additional args...]
>>    -DCMAKE_GENERATOR=${CMAKE_GENERATOR}
>>    -DCMAKE_GENERATOR_PLATFORM=${CMAKE_GENERATOR_PLATFORM}
>>    -DCMAKE_GENERATOR_TOOLSET=${CMAKE_GENERATOR_TOOLSET}
>>     ${CMAKE_CURRENT_BINARY_DIR}/source/build/cmake
>>   ...)
>>
>> --
>> Regards,
>> Konstantin Podsvirov
>>
>
>
>
> --
> *Benjamin BALLET*
> Ing?nieur R&D
>
> *ACTIVISU*
> 19, rue Klock - 92110 Clichy
> *> Standard T?l* :  01 44 69 37 37
> *>* www.activisu.com
>



-- 
*Benjamin BALLET*
Ing?nieur R&D

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard T?l* :  01 44 69 37 37
*>* www.activisu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161026/114b1a01/attachment-0001.html>

From steve.lorimer at gmail.com  Wed Oct 26 09:57:45 2016
From: steve.lorimer at gmail.com (Steve Lorimer)
Date: Wed, 26 Oct 2016 08:57:45 -0500
Subject: [CMake] clean custom_target
In-Reply-To: <CAKohaZfzAksxWamT67qm=UL8wU1ysqE2+k7NORZ59exA96WtpQ@mail.gmail.com>
References: <CAKLVFYEMNjaBMGWBzRiVNJKEL-3NGQ8HDg1sPgHU0cmwFZZurw@mail.gmail.com>
 <CAKohaZfzAksxWamT67qm=UL8wU1ysqE2+k7NORZ59exA96WtpQ@mail.gmail.com>
Message-ID: <CAE-NPOh4kB2ab2YAH4CoGny1+f3uBJA8LGB=Ct8B7L0zjAVwKw@mail.gmail.com>

There is an open issue about just this.

If ADDITIONAL_MAKE_CLEAN_FILES doesn't work for you, you may want to make
your case on the issue

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

On 26 October 2016 at 00:59, Petr Kmoch <petr.kmoch at gmail.com> wrote:

> Hi Tiago.
>
> The best I can think of is the directory property
> ADDITIONAL_MAKE_CLEAN_FILES: https://cmake.org/cmake/help/
> latest/prop_dir/ADDITIONAL_MAKE_CLEAN_FILES.html
>
> You can set it to a list of files which will be removed as part of running
> `make clean` or its equivalent for other generators.
>
> Petr
>
> On 26 October 2016 at 04:36, Tiago Macarios <tiagomacarios at gmail.com>
> wrote:
>
>> Hi,
>>
>> Is there a way to have a command to be run during a clean?
>>
>> I have a custom_target which does a fair bit of things and it also has
>> the ability to clean up after itself. So conceptually something like this
>> is what I am looking for:
>>
>> add_custom_target(Name ALL
>>     COMMAND command
>>     COMMAND_CLEAN command -clean
>> )
>>
>>
>> Tiago
>>
>> --
>>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161026/d347661b/attachment.html>

From roman.wueger at gmx.at  Wed Oct 26 14:27:12 2016
From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=)
Date: Wed, 26 Oct 2016 20:27:12 +0200
Subject: [CMake] [cmake-developers] iwyu and clang-tidy not working
	under mac os
In-Reply-To: <CANZMcXopPceX6XWOseP7Jf6ckaTVOSyvPgx-=UebCmBQbyuZAQ@mail.gmail.com>
References: <280F26CD-3681-4738-916A-E2C6CABA14C1@gmx.at>
 <CANZMcXopPceX6XWOseP7Jf6ckaTVOSyvPgx-=UebCmBQbyuZAQ@mail.gmail.com>
Message-ID: <EBA1B496-698B-4516-A547-2BECF118B4F3@gmx.at>

Ok, I've got it.
If anyone is interested, here is my configuration:
find_program(iwyu_path NAMES include-what-you-use iwyu PATHS ${CMAKE_SOURCE_DIR}/tools/include-what-you-use/${iwyu_os}/bin) if(NOT iwyu_path) message(STATUS "Program include-what-you-use: Not found") else() message(STATUS "Program include-what-you-use: Found") set(CMAKE_CXX_INCLUDE_WHAT_YOU_USE ${iwyu_path}) endif() find_program(clang_tidy NAMES clang-tidy clang-tidy-3.8) if(NOT clang_tidy) message(STATUS "Program clang-tidy: Not found") else() message(STATUS "Program clang-tidy: Found") set(CMAKE_CXX_CLANG_TIDY "${clang_tidy};-checks=-*,clang-analyzer-*,-clang-analyzer-alpha*,performance-*,cppcoreguidelines-*,cert-*,modernize-*") endif() 

Regards
Roman

> Am 26.10.2016 um 11:50 schrieb Daniel Pfeifer <daniel at pfeifer-mail.de>:
> 
>> On Wed, Oct 26, 2016 at 11:27 AM, Roman W?ger <roman.wueger at gmx.at> wrote:
>> Hello,
>> 
>> I set CMAKE_CXX_INCLUDE_WHAT_YOU_USE and CMAKE_CXX_CLANG_TIDY. Both work as expected with CMake 3.6.2 under linux. Under Mac OS with the same sources and the same CMake version doesn't produce any output.
>> 
>> On Linux clang 3.8 is used, on Mac OS it is AppleClang 7.3.0 with clang-tidy installed from homebrew.
>> 
>> Any hints?
> 
> When you run "make VERBOSE=1" and look at what is executed, do you see any "cmake --iwyu" invocations?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161026/6a259dcf/attachment.html>

From rcdailey.lists at gmail.com  Thu Oct 27 17:48:06 2016
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Thu, 27 Oct 2016 16:48:06 -0500
Subject: [CMake] CMake integration in Gradle (Android Studio)
In-Reply-To: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>
References: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>
Message-ID: <CAHd499AkCqD0Oid7qgHPNp-P2fiCpY_z-8C3B=WZtKEyWJVY+g@mail.gmail.com>

I'm at a bit of a loss on finding more information. Can anyone at
least confirm that this isn't a reliable place to find the answers I'm
looking for? Does anyone have real experience with android + gradle +
cmake integration and can provide some pointers?

On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> I'm not sure if the CMake mailing lists are the right place to ask
> this question but I thought I'd ask just in case someone has gone down
> this path or has experience with what Google/Gradle is actually trying
> to accomplish with what seems to be a hand-built version of CMake with
> custom patches that are not in upstream repositories.
>
> Prior to switching to Android Studio / Gradle, I was using Eclipse /
> Ant. The way I did CMake integration was not really integration at
> all: I generated Ninja build scripts using CMake and implemented
> custom targets to run "ant release" after all the C++ projects were
> built. I made sure that CMake copied relevant *.so files to
> appropriate directories in the Ant structure so they are packaged with
> built APKs. That's how I did my Android development.
>
> Now that I'm integrating CMake into Gradle, first annoyance I noticed
> is that I can't use CMake 3.7 (or any external installation of CMake)
> with Android Studio. It requires a version of CMake installed through
> SDK Manager. This means I can't use the new Android toolchain
> functionality built into CMake 3.7 (sad face). But this is something I
> can work around...
>
> Next I found out that stuff I'm setting in my CMake scripts, such as
> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
> For whatever reason, Gradle is overriding these from the command line
> (I'm guessing?). So this requires me to duplicate the toolchain /
> compiler flag setup I already do in my CMake scripts now in the Gradle
> build scripts. This seems completely unnecessary and a maintenance
> burden.
>
> What I was expecting Gradle to do was essentially provide me some
> toolchain file so that CMake can find the compiler and linker to use
> and then the rest would be determined by CMake itself.
>
> Is there a way I can tell Gradle to not take so much control over
> compiler flags? I want my CMake scripts to do this. I can't imagine
> they had a good reason to do this. What have others done in this
> situation with their own Gradle + CMake integration? Looking for
> advice here, since information is sparse, especially since the Android
> Studio 2.2 CMake integration is relatively new stuff.

From tiagomacarios at gmail.com  Thu Oct 27 18:25:42 2016
From: tiagomacarios at gmail.com (Tiago Macarios)
Date: Thu, 27 Oct 2016 15:25:42 -0700
Subject: [CMake] clean custom_target
In-Reply-To: <CAE-NPOh4kB2ab2YAH4CoGny1+f3uBJA8LGB=Ct8B7L0zjAVwKw@mail.gmail.com>
References: <CAKLVFYEMNjaBMGWBzRiVNJKEL-3NGQ8HDg1sPgHU0cmwFZZurw@mail.gmail.com>
 <CAKohaZfzAksxWamT67qm=UL8wU1ysqE2+k7NORZ59exA96WtpQ@mail.gmail.com>
 <CAE-NPOh4kB2ab2YAH4CoGny1+f3uBJA8LGB=Ct8B7L0zjAVwKw@mail.gmail.com>
Message-ID: <CAKLVFYGOZ+fFcw032NsUfr4RHFTMso0hF5MCDJucJXDZ5ijwGA@mail.gmail.com>

Thanks Steve. I added a comment to the gitlab thread.

On Wed, Oct 26, 2016 at 6:57 AM, Steve Lorimer <steve.lorimer at gmail.com>
wrote:

> There is an open issue about just this.
>
> If ADDITIONAL_MAKE_CLEAN_FILES doesn't work for you, you may want to make
> your case on the issue
>
> https://gitlab.kitware.com/cmake/cmake/issues/16358
>
> On 26 October 2016 at 00:59, Petr Kmoch <petr.kmoch at gmail.com> wrote:
>
>> Hi Tiago.
>>
>> The best I can think of is the directory property
>> ADDITIONAL_MAKE_CLEAN_FILES: https://cmake.org/cmake/help/l
>> atest/prop_dir/ADDITIONAL_MAKE_CLEAN_FILES.html
>>
>> You can set it to a list of files which will be removed as part of
>> running `make clean` or its equivalent for other generators.
>>
>> Petr
>>
>> On 26 October 2016 at 04:36, Tiago Macarios <tiagomacarios at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Is there a way to have a command to be run during a clean?
>>>
>>> I have a custom_target which does a fair bit of things and it also has
>>> the ability to clean up after itself. So conceptually something like this
>>> is what I am looking for:
>>>
>>> add_custom_target(Name ALL
>>>     COMMAND command
>>>     COMMAND_CLEAN command -clean
>>> )
>>>
>>>
>>> Tiago
>>>
>>> --
>>>
>>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161027/711634e6/attachment.html>

From seb at knzl.de  Fri Oct 28 06:14:15 2016
From: seb at knzl.de (Sebastian Kienzl)
Date: Fri, 28 Oct 2016 12:14:15 +0200
Subject: [CMake] EXCLUDE_FROM_ALL vs. EXCLUDE_FROM_DEFAULT_BUILD
Message-ID: <e9fbac2c-7884-01e0-f6aa-6e66fad04ea1@knzl.de>

Hello all,

I like "EXCLUDE_FROM_ALL", because with the Make-generator I can define
library-targets that will not be built with "make all" *unless* another
target depends on it.

This way, I can define libraries that will only be built if another
target depends on it.

Maybe that's not exactly the idea of EXCLUDE_FROM_ALL, but it is
convenient this way.


However, I don't see how exactly the same can be achieved with
Visual Studio.

Yes, I could tell developers to build the "ALL_BUILD" project instead
of hitting F7 (to build the solution) but that's not convenient.


Why is this a problem for us?

Because a library that no one depends on may actually not even build
under Windows and we don't want to clutter our CMakeLists with

if(WIN32)
   add_subdirectory(...)
endif()
.

Build times is another thing.


This issue has already been filed:

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

and discussed in these threads:

http://public.kitware.com/pipermail/cmake/2011-August/045662.html
http://public.kitware.com/pipermail/cmake/2013-February/053528.html


I can think of two solutions, the latter being the cleaner IMO:

1. A property on a library-target that inhibits generation of the
   respective Visual Studio project if no other target depends on it.

2. Being able to mark targets as being "non-standalone" in the sense
   that they'll be ignored by the generator if no other targets depends
   on them.


For our case I found myself this workaround:
https://gist.github.com/sebknzl/ff6524420890fe6fdbdbc7d3264b103a


Thanks for your attention and greetings from Munich,
Sebastian Kienzl


From imbacen at gmail.com  Sat Oct 29 06:22:07 2016
From: imbacen at gmail.com (cen)
Date: Sat, 29 Oct 2016 12:22:07 +0200
Subject: [CMake] Proper way to support 64bit and 32bit builds
Message-ID: <818f9da8-70de-d9ee-0951-241639f77dc9@gmail.com>

Hi

Once I switch to 32bit builds, CMake fails to recognise that 
glibc-devel.i686 is not installed resulting in an error when running make.
In the same way, my own FindGMP fails to recognize that gmp-devel.i686 
is not installed. I need CMake to fail if these things are missing.
At least for the compiler part, I'm pretty sure I am missing some var or 
flag to tell CMake I expect a 32 bit build.

This is what I use to switch between builds in CMakeLists.txt (ARCH var 
is irrelevant here,  I use it later on for CPack):

if (BUILD_32)
         set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS 
"-m32" LINK_FLAGS "-m32")
         MESSAGE(STATUS "Excluding 64bit library paths from search.")
         set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS OFF)
         set(ARCH i686)
elseif (BUILD_64)
         set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS 
"-m64" LINK_FLAGS "-m64")
         set(ARCH amd64)
else()
         set(ARCH amd64)
endif()


For the FindGMP module, I am not really sure what the best practice 
is.Does the BUILD_32 and BUILD_64 flag propagate into the FindGMP? Do I 
explicitly specify paths for 32bit libs (eg: /usr/lib64) or can  cmake 
be smarter than this?

From post at hendrik-sattler.de  Sat Oct 29 09:25:13 2016
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Sat, 29 Oct 2016 15:25:13 +0200
Subject: [CMake] Proper way to support 64bit and 32bit builds
In-Reply-To: <818f9da8-70de-d9ee-0951-241639f77dc9@gmail.com>
References: <818f9da8-70de-d9ee-0951-241639f77dc9@gmail.com>
Message-ID: <EED6FC49-E92A-4AA6-9135-449C6F09C7A5@hendrik-sattler.de>

You need to set these compiler flags BEFORE the project() call to let CMake detect all stuff properly. There is a CMake  variable telling you the size of a void*.


Am 29. Oktober 2016 12:22:07 MESZ, schrieb cen <imbacen at gmail.com>:
>Hi
>
>Once I switch to 32bit builds, CMake fails to recognise that 
>glibc-devel.i686 is not installed resulting in an error when running
>make.
>In the same way, my own FindGMP fails to recognize that gmp-devel.i686 
>is not installed. I need CMake to fail if these things are missing.
>At least for the compiler part, I'm pretty sure I am missing some var
>or 
>flag to tell CMake I expect a 32 bit build.
>
>This is what I use to switch between builds in CMakeLists.txt (ARCH var
>
>is irrelevant here,  I use it later on for CPack):
>
>if (BUILD_32)
>        set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS 
>"-m32" LINK_FLAGS "-m32")
>         MESSAGE(STATUS "Excluding 64bit library paths from search.")
>         set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS OFF)
>         set(ARCH i686)
>elseif (BUILD_64)
>        set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS 
>"-m64" LINK_FLAGS "-m64")
>         set(ARCH amd64)
>else()
>         set(ARCH amd64)
>endif()
>
>
>For the FindGMP module, I am not really sure what the best practice 
>is.Does the BUILD_32 and BUILD_64 flag propagate into the FindGMP? Do I
>
>explicitly specify paths for 32bit libs (eg: /usr/lib64) or can  cmake 
>be smarter than this?

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

From imbacen at gmail.com  Sat Oct 29 09:46:30 2016
From: imbacen at gmail.com (cen)
Date: Sat, 29 Oct 2016 15:46:30 +0200
Subject: [CMake] Proper way to support 64bit and 32bit builds
In-Reply-To: <EED6FC49-E92A-4AA6-9135-449C6F09C7A5@hendrik-sattler.de>
References: <818f9da8-70de-d9ee-0951-241639f77dc9@gmail.com>
 <EED6FC49-E92A-4AA6-9135-449C6F09C7A5@hendrik-sattler.de>
Message-ID: <e195772f-2b66-72dc-bcd9-092987471a4b@gmail.com>

I tried setting CXXFLAGS and CMAKE_CXX_FLAGS to -m32 before the 
project() call but nothing changed. I could make it fail with 
"CXXFLAGS=-m32 cmake -G ..." from command line but this seems wrong. A 
minimal CMakeLists.txt example would be nice.


Hendrik Sattler je 29. 10. 2016 ob 15:25 napisal:
> You need to set these compiler flags BEFORE the project() call to let CMake detect all stuff properly. There is a CMake  variable telling you the size of a void*.
>
>
> Am 29. Oktober 2016 12:22:07 MESZ, schrieb cen <imbacen at gmail.com>:
>> Hi
>>
>> Once I switch to 32bit builds, CMake fails to recognise that
>> glibc-devel.i686 is not installed resulting in an error when running
>> make.
>> In the same way, my own FindGMP fails to recognize that gmp-devel.i686
>> is not installed. I need CMake to fail if these things are missing.
>> At least for the compiler part, I'm pretty sure I am missing some var
>> or
>> flag to tell CMake I expect a 32 bit build.
>>
>> This is what I use to switch between builds in CMakeLists.txt (ARCH var
>>
>> is irrelevant here,  I use it later on for CPack):
>>
>> if (BUILD_32)
>>         set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS
>> "-m32" LINK_FLAGS "-m32")
>>          MESSAGE(STATUS "Excluding 64bit library paths from search.")
>>          set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS OFF)
>>          set(ARCH i686)
>> elseif (BUILD_64)
>>         set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS
>> "-m64" LINK_FLAGS "-m64")
>>          set(ARCH amd64)
>> else()
>>          set(ARCH amd64)
>> endif()
>>
>>
>> For the FindGMP module, I am not really sure what the best practice
>> is.Does the BUILD_32 and BUILD_64 flag propagate into the FindGMP? Do I
>>
>> explicitly specify paths for 32bit libs (eg: /usr/lib64) or can  cmake
>> be smarter than this?


From annulen at yandex.ru  Sat Oct 29 11:45:32 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Sat, 29 Oct 2016 18:45:32 +0300
Subject: [CMake] Proper way to support 64bit and 32bit builds
In-Reply-To: <e195772f-2b66-72dc-bcd9-092987471a4b@gmail.com>
References: <818f9da8-70de-d9ee-0951-241639f77dc9@gmail.com>
 <EED6FC49-E92A-4AA6-9135-449C6F09C7A5@hendrik-sattler.de>
 <e195772f-2b66-72dc-bcd9-092987471a4b@gmail.com>
Message-ID: <1165011477755932@web26o.yandex.ru>



29.10.2016, 16:46, "cen" <imbacen at gmail.com>:
> I tried setting CXXFLAGS and CMAKE_CXX_FLAGS to -m32 before the
> project() call but nothing changed. I could make it fail with
> "CXXFLAGS=-m32 cmake -G ..." from command line but this seems wrong. A
> minimal CMakeLists.txt example would be nice.

Use toolchain file

>
> Hendrik Sattler je 29. 10. 2016 ob 15:25 napisal:
>> ?You need to set these compiler flags BEFORE the project() call to let CMake detect all stuff properly. There is a CMake variable telling you the size of a void*.
>>
>> ?Am 29. Oktober 2016 12:22:07 MESZ, schrieb cen <imbacen at gmail.com>:
>>> ?Hi
>>>
>>> ?Once I switch to 32bit builds, CMake fails to recognise that
>>> ?glibc-devel.i686 is not installed resulting in an error when running
>>> ?make.
>>> ?In the same way, my own FindGMP fails to recognize that gmp-devel.i686
>>> ?is not installed. I need CMake to fail if these things are missing.
>>> ?At least for the compiler part, I'm pretty sure I am missing some var
>>> ?or
>>> ?flag to tell CMake I expect a 32 bit build.
>>>
>>> ?This is what I use to switch between builds in CMakeLists.txt (ARCH var
>>>
>>> ?is irrelevant here, I use it later on for CPack):
>>>
>>> ?if (BUILD_32)
>>> ?????????set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS
>>> ?"-m32" LINK_FLAGS "-m32")
>>> ??????????MESSAGE(STATUS "Excluding 64bit library paths from search.")
>>> ??????????set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS OFF)
>>> ??????????set(ARCH i686)
>>> ?elseif (BUILD_64)
>>> ?????????set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS
>>> ?"-m64" LINK_FLAGS "-m64")
>>> ??????????set(ARCH amd64)
>>> ?else()
>>> ??????????set(ARCH amd64)
>>> ?endif()
>>>
>>> ?For the FindGMP module, I am not really sure what the best practice
>>> ?is.Does the BUILD_32 and BUILD_64 flag propagate into the FindGMP? Do I
>>>
>>> ?explicitly specify paths for 32bit libs (eg: /usr/lib64) or can cmake
>>> ?be smarter than this?
>
> --
>
> 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

From d3ck0r at gmail.com  Sat Oct 29 11:51:14 2016
From: d3ck0r at gmail.com (J Decker)
Date: Sat, 29 Oct 2016 08:51:14 -0700
Subject: [CMake] Proper way to support 64bit and 32bit builds
In-Reply-To: <818f9da8-70de-d9ee-0951-241639f77dc9@gmail.com>
References: <818f9da8-70de-d9ee-0951-241639f77dc9@gmail.com>
Message-ID: <CAA2GJqUykLvGg=FsWb3nOg4khVWXHGcqsVUJaWLYeyfUqyUC_Q@mail.gmail.com>

I would think the find is using something like...  so you'll need to adjust
cmake_sizeof_void_p

if( CMAKE_SIZEOF_VOID_P EQUAL 8 )
    DEFINE_DEFAULT( __64__ ON )
else( CMAKE_SIZEOF_VOID_P EQUAL 8 )
    DEFINE_DEFAULT( __64__ OFF )
endif( CMAKE_SIZEOF_VOID_P EQUAL 8 )
SET( __64__ ${__64__} CACHE BOOL "Enable 64 considerations" )


On Sat, Oct 29, 2016 at 3:22 AM, cen <imbacen at gmail.com> wrote:

> Hi
>
> Once I switch to 32bit builds, CMake fails to recognise that
> glibc-devel.i686 is not installed resulting in an error when running make.
> In the same way, my own FindGMP fails to recognize that gmp-devel.i686 is
> not installed. I need CMake to fail if these things are missing.
> At least for the compiler part, I'm pretty sure I am missing some var or
> flag to tell CMake I expect a 32 bit build.
>
> This is what I use to switch between builds in CMakeLists.txt (ARCH var is
> irrelevant here,  I use it later on for CPack):
>
> if (BUILD_32)
>         set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS
> "-m32" LINK_FLAGS "-m32")
>         MESSAGE(STATUS "Excluding 64bit library paths from search.")
>         set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS OFF)
>         set(ARCH i686)
> elseif (BUILD_64)
>         set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS
> "-m64" LINK_FLAGS "-m64")
>         set(ARCH amd64)
> else()
>         set(ARCH amd64)
> endif()
>
>
> For the FindGMP module, I am not really sure what the best practice
> is.Does the BUILD_32 and BUILD_64 flag propagate into the FindGMP? Do I
> explicitly specify paths for 32bit libs (eg: /usr/lib64) or can  cmake be
> smarter than this?
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161029/15156192/attachment.html>

From rjh at sixdemonbag.org  Sat Oct 29 12:14:26 2016
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sat, 29 Oct 2016 12:14:26 -0400
Subject: [CMake] CPack: avoid creating unnecessary man dirs
Message-ID: <fb804ffc-db40-3704-26e1-8291722b93fd@sixdemonbag.org>

I'm migrating a project from Autotools to CMake.  So far it's been a
good experience save for installing manpages.

I'm using include(GNUInstallDirs) to help make the migration easier.  In
my manpage subdir I have the following CMakeLists.txt:

set(MAN_NAMES nsrlsvr.1 nsrlupdate.1)
add_custom_target(man ALL DEPENDS ${MAN_NAMES})
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/nsrlsvr.1 DESTINATION
${CMAKE_INSTALL_MANDIR}/man1/)
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/nsrlupdate.1 DESTINATION
${CMAKE_INSTALL_MANDIR}/man1/)

This seems to work just fine for a "make install", and it successfully
generates RPMs with a "make package".  However, those RPMs are
uninstallable on a Fedora system:

Error: Transaction check error:
  file /usr/share/man from install of nsrlsvr-1.6.1-1.x86_64 conflicts
with file from package filesystem-3.2-37.fc24.x86_64
  file /usr/share/man/man1 from install of nsrlsvr-1.6.1-1.x86_64
conflicts with file from package filesystem-3.2-37.fc24.x86_64

Apparently, CMake is trying to create dirs even if they already exist.
Is there any way to suppress this?  What's the best way to address this?

(The full source tree, along with all the CMakeLists.txt files, is
available at https://github.com/rjhansen/nsrlsvr/ )

From i.zaufi at gmail.com  Sat Oct 29 12:59:55 2016
From: i.zaufi at gmail.com (Alex Turbov)
Date: Sun, 30 Oct 2016 00:59:55 +0800
Subject: [CMake] CPack: avoid creating unnecessary man dirs
In-Reply-To: <fb804ffc-db40-3704-26e1-8291722b93fd@sixdemonbag.org>
References: <fb804ffc-db40-3704-26e1-8291722b93fd@sixdemonbag.org>
Message-ID: <CANktQttcd54HA=jbGqt_JMWF9uB-n=gX_TXSjfEssksAqNrDOg@mail.gmail.com>

Use `CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION` to add a man's dir to
'exclude' list, so RPM package wouldn't have a dir, but files from it... so
it wouldn't conflict w/ `filesystem` package.

On Sun, Oct 30, 2016 at 12:14 AM, Robert J. Hansen <rjh at sixdemonbag.org>
wrote:

> I'm migrating a project from Autotools to CMake.  So far it's been a
> good experience save for installing manpages.
>
> I'm using include(GNUInstallDirs) to help make the migration easier.  In
> my manpage subdir I have the following CMakeLists.txt:
>
> set(MAN_NAMES nsrlsvr.1 nsrlupdate.1)
> add_custom_target(man ALL DEPENDS ${MAN_NAMES})
> install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/nsrlsvr.1 DESTINATION
> ${CMAKE_INSTALL_MANDIR}/man1/)
> install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/nsrlupdate.1 DESTINATION
> ${CMAKE_INSTALL_MANDIR}/man1/)
>
> This seems to work just fine for a "make install", and it successfully
> generates RPMs with a "make package".  However, those RPMs are
> uninstallable on a Fedora system:
>
> Error: Transaction check error:
>   file /usr/share/man from install of nsrlsvr-1.6.1-1.x86_64 conflicts
> with file from package filesystem-3.2-37.fc24.x86_64
>   file /usr/share/man/man1 from install of nsrlsvr-1.6.1-1.x86_64
> conflicts with file from package filesystem-3.2-37.fc24.x86_64
>
> Apparently, CMake is trying to create dirs even if they already exist.
> Is there any way to suppress this?  What's the best way to address this?
>
> (The full source tree, along with all the CMakeLists.txt files, is
> available at https://github.com/rjhansen/nsrlsvr/ )
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161030/3ac1a0f0/attachment.html>

From rjh at sixdemonbag.org  Sat Oct 29 14:39:09 2016
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sat, 29 Oct 2016 14:39:09 -0400
Subject: [CMake] CPack: avoid creating unnecessary man dirs
In-Reply-To: <CANktQttcd54HA=jbGqt_JMWF9uB-n=gX_TXSjfEssksAqNrDOg@mail.gmail.com>
References: <fb804ffc-db40-3704-26e1-8291722b93fd@sixdemonbag.org>
 <CANktQttcd54HA=jbGqt_JMWF9uB-n=gX_TXSjfEssksAqNrDOg@mail.gmail.com>
Message-ID: <c343bcbf-dcff-f989-e304-bd848c1f17c2@sixdemonbag.org>

> Use `|CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION` to add a man's dir
> to 'exclude' list, so RPM package wouldn't have a dir, but files from
> it... so it wouldn't conflict w/ `filesystem` package.

Thank you; that solved one problem and exposed another.

In my old Autotools build, I used preprocessor defines to set at
compile-time where the binary should look for its data files.  In my
top-level CMakeLists.txt I set a CMake variable as:

	set(PKGDATADIR ${CMAKE_INSTALL_FULL_DATADIR}/nsrlsvr)

And in src/CMakeLists.txt I set the preprocessor define:

	add_definitions(-DPKGDATADIR="${PKGDATADIR}")

When I build the RPM and install it, though, something weird happens:

	[rjh at localhost nsrlsvr]$ /usr/bin/nsrlsvr --help
	nsrlsvr options:
	  ... (output omitted) ...
	  -f [ --file ] arg (=/usr/local/share/nsrlsvr/hashes.txt)
	                                        hash file

The default argument for -f is not /usr/share/nsrlsvr/hashes.txt, as it
should be for an RPM, but /usr/local/share/nsrlsvr/hashes.txt, as if it
were a locally-compiled package.

My first thought was that I should replace CMAKE_INSTALL_FULL_DATADIR
with CMAKE_INSTALL_DATADIR, but that was also less than useful:

	nsrlsvr options:
	  ... (output omitted) ...
	  -f [ --file ] arg (=share/nsrlsvr/hashes.txt)
	                                        hash file

How can I fix this?

("Have your code use a relative offset from where the binary is located"
is an acceptable answer; I'm hoping there's a better one, though!)

From i.zaufi at gmail.com  Sat Oct 29 15:04:33 2016
From: i.zaufi at gmail.com (Alex Turbov)
Date: Sun, 30 Oct 2016 03:04:33 +0800
Subject: [CMake] CPack: avoid creating unnecessary man dirs
In-Reply-To: <c343bcbf-dcff-f989-e304-bd848c1f17c2@sixdemonbag.org>
References: <fb804ffc-db40-3704-26e1-8291722b93fd@sixdemonbag.org>
 <CANktQttcd54HA=jbGqt_JMWF9uB-n=gX_TXSjfEssksAqNrDOg@mail.gmail.com>
 <c343bcbf-dcff-f989-e304-bd848c1f17c2@sixdemonbag.org>
Message-ID: <CANktQtszLAUS7fB7rDr8uFExkL2RUk5H6JXn261d71ZnpqhE2g@mail.gmail.com>

set `CPACK_INSTALL_PREFIX` to `/usr`... by default it set to
`CMAKE_INSTALL_PREFIX` which is `/usr/local` if you don't set it at `cmake`
run


On Sun, Oct 30, 2016 at 2:39 AM, Robert J. Hansen <rjh at sixdemonbag.org>
wrote:

> > Use `|CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION` to add a man's dir
> > to 'exclude' list, so RPM package wouldn't have a dir, but files from
> > it... so it wouldn't conflict w/ `filesystem` package.
>
> Thank you; that solved one problem and exposed another.
>
> In my old Autotools build, I used preprocessor defines to set at
> compile-time where the binary should look for its data files.  In my
> top-level CMakeLists.txt I set a CMake variable as:
>
>         set(PKGDATADIR ${CMAKE_INSTALL_FULL_DATADIR}/nsrlsvr)
>
> And in src/CMakeLists.txt I set the preprocessor define:
>
>         add_definitions(-DPKGDATADIR="${PKGDATADIR}")
>
> When I build the RPM and install it, though, something weird happens:
>
>         [rjh at localhost nsrlsvr]$ /usr/bin/nsrlsvr --help
>         nsrlsvr options:
>           ... (output omitted) ...
>           -f [ --file ] arg (=/usr/local/share/nsrlsvr/hashes.txt)
>                                                 hash file
>
> The default argument for -f is not /usr/share/nsrlsvr/hashes.txt, as it
> should be for an RPM, but /usr/local/share/nsrlsvr/hashes.txt, as if it
> were a locally-compiled package.
>
> My first thought was that I should replace CMAKE_INSTALL_FULL_DATADIR
> with CMAKE_INSTALL_DATADIR, but that was also less than useful:
>
>         nsrlsvr options:
>           ... (output omitted) ...
>           -f [ --file ] arg (=share/nsrlsvr/hashes.txt)
>                                                 hash file
>
> How can I fix this?
>
> ("Have your code use a relative offset from where the binary is located"
> is an acceptable answer; I'm hoping there's a better one, though!)
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161030/87a0691c/attachment.html>

From ramey at rrsd.com  Sat Oct 29 16:03:30 2016
From: ramey at rrsd.com (Robert Ramey)
Date: Sat, 29 Oct 2016 13:03:30 -0700
Subject: [CMake] CMake 3.6 and OSX
Message-ID: <nv2vag$n8l$1@blaine.gmane.org>

I've just "upgraded" to version 3.6 of CMake.  I'm using Xcode with the 
clang compiler.  Now when I'm trying to configure a project I'm getting:

The C compiler identification is unknown
The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:14 (project):
   No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:14 (project):
   No CMAKE_CXX_COMPILER could be found.

What do I have to do to make this work?

Robert Ramey


From congzhangzh at gmail.com  Sun Oct 30 10:04:54 2016
From: congzhangzh at gmail.com (Cong Monkey)
Date: Sun, 30 Oct 2016 22:04:54 +0800
Subject: [CMake] CMake integration in Gradle (Android Studio)
In-Reply-To: <CAHd499AkCqD0Oid7qgHPNp-P2fiCpY_z-8C3B=WZtKEyWJVY+g@mail.gmail.com>
References: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>
 <CAHd499AkCqD0Oid7qgHPNp-P2fiCpY_z-8C3B=WZtKEyWJVY+g@mail.gmail.com>
Message-ID: <CAOXDmPq-FxzFaith+4hObEGm0PSHDddKz58Aj69mKyHaET8fDQ@mail.gmail.com>

The latest release of android studio work with CMAKE well.

you can create a new project with c++ support to test CMAKE support!

You can follow https://code.google.com/p/android/issues/detail?id=212007
to get the details.

2016-10-28 5:48 GMT+08:00 Robert Dailey <rcdailey.lists at gmail.com>:
> I'm at a bit of a loss on finding more information. Can anyone at
> least confirm that this isn't a reliable place to find the answers I'm
> looking for? Does anyone have real experience with android + gradle +
> cmake integration and can provide some pointers?
>
> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
>> I'm not sure if the CMake mailing lists are the right place to ask
>> this question but I thought I'd ask just in case someone has gone down
>> this path or has experience with what Google/Gradle is actually trying
>> to accomplish with what seems to be a hand-built version of CMake with
>> custom patches that are not in upstream repositories.
>>
>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>> Ant. The way I did CMake integration was not really integration at
>> all: I generated Ninja build scripts using CMake and implemented
>> custom targets to run "ant release" after all the C++ projects were
>> built. I made sure that CMake copied relevant *.so files to
>> appropriate directories in the Ant structure so they are packaged with
>> built APKs. That's how I did my Android development.
>>
>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>> is that I can't use CMake 3.7 (or any external installation of CMake)
>> with Android Studio. It requires a version of CMake installed through
>> SDK Manager. This means I can't use the new Android toolchain
>> functionality built into CMake 3.7 (sad face). But this is something I
>> can work around...
>>
>> Next I found out that stuff I'm setting in my CMake scripts, such as
>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>> For whatever reason, Gradle is overriding these from the command line
>> (I'm guessing?). So this requires me to duplicate the toolchain /
>> compiler flag setup I already do in my CMake scripts now in the Gradle
>> build scripts. This seems completely unnecessary and a maintenance
>> burden.
>>
>> What I was expecting Gradle to do was essentially provide me some
>> toolchain file so that CMake can find the compiler and linker to use
>> and then the rest would be determined by CMake itself.
>>
>> Is there a way I can tell Gradle to not take so much control over
>> compiler flags? I want my CMake scripts to do this. I can't imagine
>> they had a good reason to do this. What have others done in this
>> situation with their own Gradle + CMake integration? Looking for
>> advice here, since information is sparse, especially since the Android
>> Studio 2.2 CMake integration is relatively new stuff.
> --
>
> 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

From gjasny at googlemail.com  Mon Oct 31 05:39:32 2016
From: gjasny at googlemail.com (Gregor Jasny)
Date: Mon, 31 Oct 2016 10:39:32 +0100
Subject: [CMake] CMake 3.6 and OSX
In-Reply-To: <nv2vag$n8l$1@blaine.gmane.org>
References: <nv2vag$n8l$1@blaine.gmane.org>
Message-ID: <f568b066-e824-e162-6c75-f9bffcaad80a@googlemail.com>

Hello Robert,

On 29/10/2016 22:03, Robert Ramey wrote:
> I've just "upgraded" to version 3.6 of CMake.  I'm using Xcode with the
> clang compiler.  Now when I'm trying to configure a project I'm getting:
> 
> The C compiler identification is unknown
> The CXX compiler identification is unknown
> CMake Error at CMakeLists.txt:14 (project):
>   No CMAKE_C_COMPILER could be found.
> CMake Error at CMakeLists.txt:14 (project):
>   No CMAKE_CXX_COMPILER could be found.
> 
> What do I have to do to make this work?

Have a look into <build_dir>/CMakeFiles/CMakeOutput.log and
CMakeError.log. There should be an error visible. Most often someone
forgets to accept the Xcode license. The resulting output leads to CMake
errors.

Thanks,
Gregor

From rcdailey.lists at gmail.com  Mon Oct 31 09:31:22 2016
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Mon, 31 Oct 2016 08:31:22 -0500
Subject: [CMake] CMake integration in Gradle (Android Studio)
In-Reply-To: <CAOXDmPq-FxzFaith+4hObEGm0PSHDddKz58Aj69mKyHaET8fDQ@mail.gmail.com>
References: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>
 <CAHd499AkCqD0Oid7qgHPNp-P2fiCpY_z-8C3B=WZtKEyWJVY+g@mail.gmail.com>
 <CAOXDmPq-FxzFaith+4hObEGm0PSHDddKz58Aj69mKyHaET8fDQ@mail.gmail.com>
Message-ID: <CAHd499AOnr5kVstDg2NS3eh=nNiwS-aqMGvp=Hd1rPFBZHApVA@mail.gmail.com>

Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
talking about dev/beta builds?

On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey <congzhangzh at gmail.com> wrote:
> The latest release of android studio work with CMAKE well.
>
> you can create a new project with c++ support to test CMAKE support!
>
> You can follow https://code.google.com/p/android/issues/detail?id=212007
> to get the details.
>
> 2016-10-28 5:48 GMT+08:00 Robert Dailey <rcdailey.lists at gmail.com>:
>> I'm at a bit of a loss on finding more information. Can anyone at
>> least confirm that this isn't a reliable place to find the answers I'm
>> looking for? Does anyone have real experience with android + gradle +
>> cmake integration and can provide some pointers?
>>
>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
>>> I'm not sure if the CMake mailing lists are the right place to ask
>>> this question but I thought I'd ask just in case someone has gone down
>>> this path or has experience with what Google/Gradle is actually trying
>>> to accomplish with what seems to be a hand-built version of CMake with
>>> custom patches that are not in upstream repositories.
>>>
>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>> Ant. The way I did CMake integration was not really integration at
>>> all: I generated Ninja build scripts using CMake and implemented
>>> custom targets to run "ant release" after all the C++ projects were
>>> built. I made sure that CMake copied relevant *.so files to
>>> appropriate directories in the Ant structure so they are packaged with
>>> built APKs. That's how I did my Android development.
>>>
>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>> with Android Studio. It requires a version of CMake installed through
>>> SDK Manager. This means I can't use the new Android toolchain
>>> functionality built into CMake 3.7 (sad face). But this is something I
>>> can work around...
>>>
>>> Next I found out that stuff I'm setting in my CMake scripts, such as
>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>>> For whatever reason, Gradle is overriding these from the command line
>>> (I'm guessing?). So this requires me to duplicate the toolchain /
>>> compiler flag setup I already do in my CMake scripts now in the Gradle
>>> build scripts. This seems completely unnecessary and a maintenance
>>> burden.
>>>
>>> What I was expecting Gradle to do was essentially provide me some
>>> toolchain file so that CMake can find the compiler and linker to use
>>> and then the rest would be determined by CMake itself.
>>>
>>> Is there a way I can tell Gradle to not take so much control over
>>> compiler flags? I want my CMake scripts to do this. I can't imagine
>>> they had a good reason to do this. What have others done in this
>>> situation with their own Gradle + CMake integration? Looking for
>>> advice here, since information is sparse, especially since the Android
>>> Studio 2.2 CMake integration is relatively new stuff.
>> --
>>
>> 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

From congzhangzh at gmail.com  Mon Oct 31 09:55:03 2016
From: congzhangzh at gmail.com (Cong Monkey)
Date: Mon, 31 Oct 2016 21:55:03 +0800
Subject: [CMake] CMake integration in Gradle (Android Studio)
In-Reply-To: <CAOXDmPoZQP5id6VfSjjSaa=DLz-XLdBetDYcLg26Q6DEKhMfWg@mail.gmail.com>
References: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>
 <CAHd499AkCqD0Oid7qgHPNp-P2fiCpY_z-8C3B=WZtKEyWJVY+g@mail.gmail.com>
 <CAOXDmPq-FxzFaith+4hObEGm0PSHDddKz58Aj69mKyHaET8fDQ@mail.gmail.com>
 <CAHd499AOnr5kVstDg2NS3eh=nNiwS-aqMGvp=Hd1rPFBZHApVA@mail.gmail.com>
 <CAOXDmPoZQP5id6VfSjjSaa=DLz-XLdBetDYcLg26Q6DEKhMfWg@mail.gmail.com>
Message-ID: <CAOXDmPoQE+LYf++mR-mWQZyx+nae9XNfDFkh_p-PVkT3zviB7Q@mail.gmail.com>

Try to update your Android SDK from android studio?

2016?10?31? 21:31?"Robert Dailey" <rcdailey.lists at gmail.com>???

Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
talking about dev/beta builds?

On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey <congzhangzh at gmail.com> wrote:
> The latest release of android studio work with CMAKE well.
>
> you can create a new project with c++ support to test CMAKE support!
>
> You can follow https://code.google.com/p/android/issues/detail?id=212007
> to get the details.
>
> 2016-10-28 5:48 GMT+08:00 Robert Dailey <rcdailey.lists at gmail.com>:
>> I'm at a bit of a loss on finding more information. Can anyone at
>> least confirm that this isn't a reliable place to find the answers I'm
>> looking for? Does anyone have real experience with android + gradle +
>> cmake integration and can provide some pointers?
>>
>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.lists at gmail.com>
wrote:
>>> I'm not sure if the CMake mailing lists are the right place to ask
>>> this question but I thought I'd ask just in case someone has gone down
>>> this path or has experience with what Google/Gradle is actually trying
>>> to accomplish with what seems to be a hand-built version of CMake with
>>> custom patches that are not in upstream repositories.
>>>
>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>> Ant. The way I did CMake integration was not really integration at
>>> all: I generated Ninja build scripts using CMake and implemented
>>> custom targets to run "ant release" after all the C++ projects were
>>> built. I made sure that CMake copied relevant *.so files to
>>> appropriate directories in the Ant structure so they are packaged with
>>> built APKs. That's how I did my Android development.
>>>
>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>> with Android Studio. It requires a version of CMake installed through
>>> SDK Manager. This means I can't use the new Android toolchain
>>> functionality built into CMake 3.7 (sad face). But this is something I
>>> can work around...
>>>
>>> Next I found out that stuff I'm setting in my CMake scripts, such as
>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>>> For whatever reason, Gradle is overriding these from the command line
>>> (I'm guessing?). So this requires me to duplicate the toolchain /
>>> compiler flag setup I already do in my CMake scripts now in the Gradle
>>> build scripts. This seems completely unnecessary and a maintenance
>>> burden.
>>>
>>> What I was expecting Gradle to do was essentially provide me some
>>> toolchain file so that CMake can find the compiler and linker to use
>>> and then the rest would be determined by CMake itself.
>>>
>>> Is there a way I can tell Gradle to not take so much control over
>>> compiler flags? I want my CMake scripts to do this. I can't imagine
>>> they had a good reason to do this. What have others done in this
>>> situation with their own Gradle + CMake integration? Looking for
>>> advice here, since information is sparse, especially since the Android
>>> Studio 2.2 CMake integration is relatively new stuff.
>> --
>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161031/7bec3c1e/attachment.html>

From rcdailey.lists at gmail.com  Mon Oct 31 10:13:18 2016
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Mon, 31 Oct 2016 09:13:18 -0500
Subject: [CMake] CMake integration in Gradle (Android Studio)
In-Reply-To: <CAOXDmPoQE+LYf++mR-mWQZyx+nae9XNfDFkh_p-PVkT3zviB7Q@mail.gmail.com>
References: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>
 <CAHd499AkCqD0Oid7qgHPNp-P2fiCpY_z-8C3B=WZtKEyWJVY+g@mail.gmail.com>
 <CAOXDmPq-FxzFaith+4hObEGm0PSHDddKz58Aj69mKyHaET8fDQ@mail.gmail.com>
 <CAHd499AOnr5kVstDg2NS3eh=nNiwS-aqMGvp=Hd1rPFBZHApVA@mail.gmail.com>
 <CAOXDmPoZQP5id6VfSjjSaa=DLz-XLdBetDYcLg26Q6DEKhMfWg@mail.gmail.com>
 <CAOXDmPoQE+LYf++mR-mWQZyx+nae9XNfDFkh_p-PVkT3zviB7Q@mail.gmail.com>
Message-ID: <CAHd499C_cCdTRPeRZWPCw0AThF48N3Y7yrz7jFZnp-=SvQ5yXg@mail.gmail.com>

I'm sorry but that doesn't really answer my questions.

On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey <congzhangzh at gmail.com> wrote:
> Try to update your Android SDK from android studio?
>
>
> 2016?10?31? 21:31?"Robert Dailey" <rcdailey.lists at gmail.com>???
>
> Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
> talking about dev/beta builds?
>
> On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey <congzhangzh at gmail.com> wrote:
>> The latest release of android studio work with CMAKE well.
>>
>> you can create a new project with c++ support to test CMAKE support!
>>
>> You can follow https://code.google.com/p/android/issues/detail?id=212007
>> to get the details.
>>
>> 2016-10-28 5:48 GMT+08:00 Robert Dailey <rcdailey.lists at gmail.com>:
>>> I'm at a bit of a loss on finding more information. Can anyone at
>>> least confirm that this isn't a reliable place to find the answers I'm
>>> looking for? Does anyone have real experience with android + gradle +
>>> cmake integration and can provide some pointers?
>>>
>>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.lists at gmail.com>
>>> wrote:
>>>> I'm not sure if the CMake mailing lists are the right place to ask
>>>> this question but I thought I'd ask just in case someone has gone down
>>>> this path or has experience with what Google/Gradle is actually trying
>>>> to accomplish with what seems to be a hand-built version of CMake with
>>>> custom patches that are not in upstream repositories.
>>>>
>>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>>> Ant. The way I did CMake integration was not really integration at
>>>> all: I generated Ninja build scripts using CMake and implemented
>>>> custom targets to run "ant release" after all the C++ projects were
>>>> built. I made sure that CMake copied relevant *.so files to
>>>> appropriate directories in the Ant structure so they are packaged with
>>>> built APKs. That's how I did my Android development.
>>>>
>>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>>> with Android Studio. It requires a version of CMake installed through
>>>> SDK Manager. This means I can't use the new Android toolchain
>>>> functionality built into CMake 3.7 (sad face). But this is something I
>>>> can work around...
>>>>
>>>> Next I found out that stuff I'm setting in my CMake scripts, such as
>>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>>>> For whatever reason, Gradle is overriding these from the command line
>>>> (I'm guessing?). So this requires me to duplicate the toolchain /
>>>> compiler flag setup I already do in my CMake scripts now in the Gradle
>>>> build scripts. This seems completely unnecessary and a maintenance
>>>> burden.
>>>>
>>>> What I was expecting Gradle to do was essentially provide me some
>>>> toolchain file so that CMake can find the compiler and linker to use
>>>> and then the rest would be determined by CMake itself.
>>>>
>>>> Is there a way I can tell Gradle to not take so much control over
>>>> compiler flags? I want my CMake scripts to do this. I can't imagine
>>>> they had a good reason to do this. What have others done in this
>>>> situation with their own Gradle + CMake integration? Looking for
>>>> advice here, since information is sparse, especially since the Android
>>>> Studio 2.2 CMake integration is relatively new stuff.
>>> --
>>>
>>> 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
>
>

From parag at ionicsecurity.com  Mon Oct 31 10:29:15 2016
From: parag at ionicsecurity.com (Parag Chandra)
Date: Mon, 31 Oct 2016 14:29:15 +0000
Subject: [CMake] [EXTERNAL]: Re: CMake integration in Gradle (Android
 Studio)
In-Reply-To: <CAHd499AkCqD0Oid7qgHPNp-P2fiCpY_z-8C3B=WZtKEyWJVY+g@mail.gmail.com>
References: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>
 <CAHd499AkCqD0Oid7qgHPNp-P2fiCpY_z-8C3B=WZtKEyWJVY+g@mail.gmail.com>
Message-ID: <11CDD6B4-070E-48F5-8790-F053EEB42942@ionic.com>

Presumably you?ve tried this?

https://developer.android.com/studio/projects/add-native-code.html

Keep in mind that this is going to use Google?s cross-toolchain file, which may be incompatible with what you already have.

 

Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309
 

On 10/27/16, 5:48 PM, "CMake on behalf of Robert Dailey" <cmake-bounces at cmake.org on behalf of rcdailey.lists at gmail.com> wrote:

    I'm at a bit of a loss on finding more information. Can anyone at
    least confirm that this isn't a reliable place to find the answers I'm
    looking for? Does anyone have real experience with android + gradle +
    cmake integration and can provide some pointers?
    
    On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
    > I'm not sure if the CMake mailing lists are the right place to ask
    > this question but I thought I'd ask just in case someone has gone down
    > this path or has experience with what Google/Gradle is actually trying
    > to accomplish with what seems to be a hand-built version of CMake with
    > custom patches that are not in upstream repositories.
    >
    > Prior to switching to Android Studio / Gradle, I was using Eclipse /
    > Ant. The way I did CMake integration was not really integration at
    > all: I generated Ninja build scripts using CMake and implemented
    > custom targets to run "ant release" after all the C++ projects were
    > built. I made sure that CMake copied relevant *.so files to
    > appropriate directories in the Ant structure so they are packaged with
    > built APKs. That's how I did my Android development.
    >
    > Now that I'm integrating CMake into Gradle, first annoyance I noticed
    > is that I can't use CMake 3.7 (or any external installation of CMake)
    > with Android Studio. It requires a version of CMake installed through
    > SDK Manager. This means I can't use the new Android toolchain
    > functionality built into CMake 3.7 (sad face). But this is something I
    > can work around...
    >
    > Next I found out that stuff I'm setting in my CMake scripts, such as
    > CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
    > For whatever reason, Gradle is overriding these from the command line
    > (I'm guessing?). So this requires me to duplicate the toolchain /
    > compiler flag setup I already do in my CMake scripts now in the Gradle
    > build scripts. This seems completely unnecessary and a maintenance
    > burden.
    >
    > What I was expecting Gradle to do was essentially provide me some
    > toolchain file so that CMake can find the compiler and linker to use
    > and then the rest would be determined by CMake itself.
    >
    > Is there a way I can tell Gradle to not take so much control over
    > compiler flags? I want my CMake scripts to do this. I can't imagine
    > they had a good reason to do this. What have others done in this
    > situation with their own Gradle + CMake integration? Looking for
    > advice here, since information is sparse, especially since the Android
    > Studio 2.2 CMake integration is relatively new stuff.
    -- 
    
    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
    


From dflogeras2 at gmail.com  Mon Oct 31 12:42:55 2016
From: dflogeras2 at gmail.com (Dave Flogeras)
Date: Mon, 31 Oct 2016 13:42:55 -0300
Subject: [CMake] COMPONENT question
Message-ID: <CANB0TnT39Yb7_g2TUgVDfLqm0LjGUHTV4h9wsypBNxLok7XhpA@mail.gmail.com>

Hi, are static libraries able to be added to a component?

The following minimal example doesn't work as I expected:

CMAKE_MINIMUM_REQUIRED( VERSION 3.0.0 )
PROJECT( foo )

ADD_LIBRARY( foo foo.c )
INSTALL( TARGETS foo ARCHIVE DESTINATION lib
                     RUNTIME DESTINATION bin
                     LIBRARY DESTINATION bin
                     COMPONENT bar )

INCLUDE( CPack )

If I run "make list_install_components" it says "Unspecified"

However, if I add "SHARED" to the ADD_LIBRARY call (or set
BUILD_SHARED_LIBS), it lists the component as "bar" which is what I'd
expect.

Is this a bug, or by design?  I'm attempting to figure out how I can
separate shared/static libraries in my project for different install
types.  For example, if I am packaging a binary only install, I don't need
to install static libraries, but I would need the runtime libraries.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161031/ef1d5d57/attachment.html>

From iosif.neitzke+cmake at gmail.com  Mon Oct 31 13:57:41 2016
From: iosif.neitzke+cmake at gmail.com (iosif neitzke)
Date: Mon, 31 Oct 2016 12:57:41 -0500
Subject: [CMake] COMPONENT question
In-Reply-To: <CANB0TnT39Yb7_g2TUgVDfLqm0LjGUHTV4h9wsypBNxLok7XhpA@mail.gmail.com>
References: <CANB0TnT39Yb7_g2TUgVDfLqm0LjGUHTV4h9wsypBNxLok7XhpA@mail.gmail.com>
Message-ID: <23f970b8-4681-e9f4-1d3e-b29e497f06da@gmail.com>

On 10/31/2016 11:42 AM, Dave Flogeras wrote:
> Hi, are static libraries able to be added to a component?

Yes!

> 
> The following minimal example doesn't work as I expected:
> 
> CMAKE_MINIMUM_REQUIRED( VERSION 3.0.0 )
> PROJECT( foo )
> 
> ADD_LIBRARY( foo foo.c )
> INSTALL( TARGETS foo ARCHIVE DESTINATION lib
>                      RUNTIME DESTINATION bin
>                      LIBRARY DESTINATION bin
>                      COMPONENT bar )
> 
> INCLUDE( CPack )
> 
> If I run "make list_install_components" it says "Unspecified"
> 
> However, if I add "SHARED" to the ADD_LIBRARY call (or set
> BUILD_SHARED_LIBS), it lists the component as "bar" which is what I'd
> expect.
> 

Try something like:
INSTALL( TARGETS foo ARCHIVE DESTINATION lib COMPONENT bar
                     RUNTIME DESTINATION bin COMPONENT bar
                     LIBRARY DESTINATION bin COMPONENT bar )

The nesting of brackets "[]" in docs [0], requires a COMPONENT keyword
and argument (should you choose to use components) for each kind of
target file keyword (ARCHIVE, RUNTIME, LIBRARY, etc..) you use.

I believe you get the puzzling behavior varying with STATIC versus
SHARED library type because of the way the command is parsed.  When
building a STATIC library, there is only an ARCHIVE, which has no
COMPONENT listed, so you get "Unspecified" when listing components.
When building a SHARED library on non-DLL platforms, the binary is a
LIBRARY target, which has the COMPONENT "bar" listed.

Each kind of target file keyword (ARCHIVE, RUNTIME, LIBRARY, etc..) has
its own list of subsequent properties.

[0]
https://cmake.org/cmake/help/v3.7/command/install.html#installing-targets

[1] example in ParaView:
https://github.com/Kitware/ParaView/blob/6714c5c4d1e643f451421dd1004d9540d8607524/CMakeLists.txt#L710

> Is this a bug, or by design?  I'm attempting to figure out how I can
> separate shared/static libraries in my project for different install
> types.  For example, if I am packaging a binary only install, I don't
> need to install static libraries, but I would need the runtime libraries.
> 
> Dave
> 
> 

From dflogeras2 at gmail.com  Mon Oct 31 14:10:22 2016
From: dflogeras2 at gmail.com (Dave Flogeras)
Date: Mon, 31 Oct 2016 15:10:22 -0300
Subject: [CMake] COMPONENT question
In-Reply-To: <23f970b8-4681-e9f4-1d3e-b29e497f06da@gmail.com>
References: <CANB0TnT39Yb7_g2TUgVDfLqm0LjGUHTV4h9wsypBNxLok7XhpA@mail.gmail.com>
 <23f970b8-4681-e9f4-1d3e-b29e497f06da@gmail.com>
Message-ID: <CANB0TnTfqk9LmOaxP+cG_3a__Vuc4wZi59ZAGYbNnxBtTed4nw@mail.gmail.com>

Iosif, that's exactly it, I was not paying attention to the [ ] in the
docs!  Thanks for your help.

On Mon, Oct 31, 2016 at 2:57 PM, iosif neitzke <
iosif.neitzke+cmake at gmail.com> wrote:

> Try something like:
> INSTALL( TARGETS foo ARCHIVE DESTINATION lib COMPONENT bar
>                      RUNTIME DESTINATION bin COMPONENT bar
>                      LIBRARY DESTINATION bin COMPONENT bar )
>
> The nesting of brackets "[]" in docs [0], requires a COMPONENT keyword
> and argument (should you choose to use components) for each kind of
> target file keyword (ARCHIVE, RUNTIME, LIBRARY, etc..) you use.
>
> I believe you get the puzzling behavior varying with STATIC versus
> SHARED library type because of the way the command is parsed.  When
> building a STATIC library, there is only an ARCHIVE, which has no
> COMPONENT listed, so you get "Unspecified" when listing components.
> When building a SHARED library on non-DLL platforms, the binary is a
> LIBRARY target, which has the COMPONENT "bar" listed.
>
> Each kind of target file keyword (ARCHIVE, RUNTIME, LIBRARY, etc..) has
> its own list of subsequent properties.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161031/a66aba8b/attachment.html>

From ewmailing at gmail.com  Mon Oct 31 14:39:15 2016
From: ewmailing at gmail.com (Eric Wing)
Date: Mon, 31 Oct 2016 11:39:15 -0700
Subject: [CMake] CMake integration in Gradle (Android Studio)
In-Reply-To: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>
References: <CAHd499C-sKBK0Y0czQCBf-67s+2AO_VCn_trv5X1z1KPDt85-Q@mail.gmail.com>
Message-ID: <CA+Q62MA7f58uLZk8tREiGrNhcWRX4TN+XmuO9ko_T504wue0Ew@mail.gmail.com>

So I have been using (a custom) CMake + Android Studio/Gradle for some
years now. I only recently saw that both official CMake is adding
Android support, and that the official Android tools are supporting
CMake. I?m actually still confused on the differences between the two
and what each offers in terms of features.

My custom/jury-rigged CMake is derived from the OpenCV Android
toolchain which has forked around for many years. Currently, I have a
combination of custom shell scripts + modified toolchain + modified
CMake to make things work.


My cross-platform requirements have been:

- Must generate be able to generate a new Android Studio/Gradle
project, like how Xcode, Visual Studio, etc. are generated.

- Must handle multiple Android architectures (armv5, armv7, x86, arm64, x86_64)

- Must be able to handle both the native code stuff, and the annoying
Android specific Java code in order to build a complete/working
Android application that can be installed/run through the normal
Android Studio/Gradle user interface.

- Should work on Mac, Linux, and Android



The way it currently works is:

- I have a front end scripts you must run which ultimately invoke
cmake -G ?Unix Makefiles? for the Android NDK. These scripts feed my
android toolchain as well as provide the locations to the Android NDK
and SDK. Also, these scripts will generate Gradle and Android Studio
projects. (I basically brute force stripped down a real Gradle/Studio
project and figured out what values I need to inject into it to use as
a template. Many of the injected values are provided from CMake
variables I define in my project CMakeLists.txt)

- The Gradle/Studio project generated has a custom Groovy script phase
that when building, invokes an external shell script as part of the
build process. This external script ultimately calls CMake to build
the native components of the project.

- Because CMake doesn?t handle multiple architectures for Android, my
script actually generates multiple CMake projects, one for each
architecture, separated into directory structures that try to mimic
the official names of the different Android architectures. (This is
kind of brute force, and is not currently easy to opt-out of different
architectures.)

- At the end of the script phase, I use a CMake ?install? to copy the
build products for each architecture to the correct location in the
Gradle/Studio Java layout, so the Java part of the build will continue
on doing the right thing.

- The rest of the Gradle/Studio build will continue on and build the
Android Java parts of the project. (I have a specific convention for
where the Android/Java files go in my project structure. Unlike the
annoying thing that Google forced us to do with ndk-build, the Java
stuff is no longer at the root of the source tree, but parked in a
special Android subdirectory. The former was a stupid/evil requirement
for every pre-existing cross-platform project out there, and an
arrogant presumption for new projects, so I did away with it.)



Here are a few videos that show the workflow (in my SDK called Blurrr)

"Workflow" in Swift: The Android Addendum (shows just the Android part)
https://www.youtube.com/watch?v=w6FY_qSi8yY


Workflow": Cross-platform Dev in Swift
(This shows the same project as above, but for the non-Android
platforms, showing it is indeed a single, unified CMake project that
can drive Linux, OS X, iOS, Windows, and Raspberry Pi (and Android).
https://www.youtube.com/watch?v=w8ftI9mpGdY


Blurrr Introduction Part 3 (Shows the different build platforms in a
little more detail. This video is the oldest, so things have improved
a bit.)
https://www.youtube.com/watch?v=exPtM-02YRY



So my wish list for the new CMake versions is that is handles all of
this. (Multi-arch and Gradle/Studio generation especially.)

I have not yet investigated how hard it will be to migrate to one of
the two other versions of CMake. Since Swift is one of my supported
languages, this currently requires me to use a forked CMake I?ve been
working on. However, I am happy to work with people who want to try to
integrate some of my features directly into CMake if they are still
missing (such as the Gradle/Studio generation).

Thanks,
Eric