[Cmake-commits] CMake branch, master, updated. v3.13.0-rc3-446-g44a5400

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  44a5400d105b957d27780d515d0f1d51781f8de9 (commit)
  from  a786062db2bbfe375b51c200122eb3227120af2a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=44a5400d105b957d27780d515d0f1d51781f8de9
commit 44a5400d105b957d27780d515d0f1d51781f8de9
Author: Kitware Robot 
AuthorDate: Thu Nov 15 00:01:04 2018 -0500
Commit: Kitware Robot 
CommitDate: Thu Nov 15 00:01:04 2018 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 823..616e7d8 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 13)
-set(CMake_VERSION_PATCH 20181114)
+set(CMake_VERSION_PATCH 20181115)
 #set(CMake_VERSION_RC 1)

---

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


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.13.0-rc3-445-ga786062

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  a786062db2bbfe375b51c200122eb3227120af2a (commit)
   via  254a84986471d6f3405d9bf1798bc3f9582a81e8 (commit)
   via  b173c641c4efbb5fd3f3f4c18676be81abafb066 (commit)
  from  117272412e9dee1a1595718590a48e4c6750df59 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a786062db2bbfe375b51c200122eb3227120af2a
commit a786062db2bbfe375b51c200122eb3227120af2a
Merge: 1172724 254a849
Author: Brad King 
AuthorDate: Wed Nov 14 20:18:09 2018 +
Commit: Kitware Robot 
CommitDate: Wed Nov 14 15:18:15 2018 -0500

Merge topic 'WIN32'

254a849864 Help: Spell out MFC
b173c641c4 Help: Add links to variables

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=254a84986471d6f3405d9bf1798bc3f9582a81e8
commit 254a84986471d6f3405d9bf1798bc3f9582a81e8
Author: Joachim Wuttke (o) 
AuthorDate: Wed Nov 14 17:47:36 2018 +0100
Commit: Joachim Wuttke (o) 
CommitDate: Wed Nov 14 17:50:45 2018 +0100

Help: Spell out MFC

And shorten text that was hard to understand and redundant.

diff --git a/Help/prop_tgt/WIN32_EXECUTABLE.rst 
b/Help/prop_tgt/WIN32_EXECUTABLE.rst
index ceda621..060d166 100644
--- a/Help/prop_tgt/WIN32_EXECUTABLE.rst
+++ b/Help/prop_tgt/WIN32_EXECUTABLE.rst
@@ -7,6 +7,7 @@ When this property is set to true the executable when linked on
 Windows will be created with a WinMain() entry point instead of just
 main().  This makes it a GUI executable instead of a console application.
 See the :variable:`CMAKE_MFC_FLAG` variable documentation to
-configure use of MFC for WinMain executables.  This property is
-initialized by the value of the :variable:`CMAKE_WIN32_EXECUTABLE`
-variable if it is set when a target is created.
+configure use of the Microsoft Foundation Classes (MFC) for WinMain
+executables.  This property is initialized by the value of the
+:variable:`CMAKE_WIN32_EXECUTABLE` variable if it is set when
+a target is created.
diff --git a/Help/variable/CMAKE_MFC_FLAG.rst b/Help/variable/CMAKE_MFC_FLAG.rst
index 5a392bf..2c4d1c5 100644
--- a/Help/variable/CMAKE_MFC_FLAG.rst
+++ b/Help/variable/CMAKE_MFC_FLAG.rst
@@ -1,15 +1,16 @@
 CMAKE_MFC_FLAG
 --
 
-Tell cmake to use MFC for an executable or dll.
+Use the MFC library for an executable or dll.
 
-This can be set in a ``CMakeLists.txt`` file and will enable MFC in the
-application.  It should be set to ``1`` for the static MFC library, and ``2``
-for the shared MFC library.  This is used in Visual Studio
-project files.  The CMakeSetup dialog used MFC and the ``CMakeLists.txt``
-looks like this:
+Enables the use of the Microsoft Foundation Classes (MFC).
+It should be set to ``1`` for the static MFC library, and
+``2`` for the shared MFC library.  This is used in Visual Studio
+project files.
 
-::
+Usage example:
+
+.. code-block:: cmake
 
   add_definitions(-D_AFXDLL)
   set(CMAKE_MFC_FLAG 2)

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b173c641c4efbb5fd3f3f4c18676be81abafb066
commit b173c641c4efbb5fd3f3f4c18676be81abafb066
Author: Joachim Wuttke (o) 
AuthorDate: Wed Nov 14 17:38:32 2018 +0100
Commit: Joachim Wuttke (o) 
CommitDate: Wed Nov 14 17:50:45 2018 +0100

Help: Add links to variables

diff --git a/Help/prop_tgt/WIN32_EXECUTABLE.rst 
b/Help/prop_tgt/WIN32_EXECUTABLE.rst
index 336d5f7..ceda621 100644
--- a/Help/prop_tgt/WIN32_EXECUTABLE.rst
+++ b/Help/prop_tgt/WIN32_EXECUTABLE.rst
@@ -5,8 +5,8 @@ Build an executable with a WinMain entry point on windows.
 
 When this property is set to true the executable when linked on
 Windows will be created with a WinMain() entry point instead of just
-main().  This makes it a GUI executable instead of a console
-application.  See the CMAKE_MFC_FLAG variable documentation to
+main().  This makes it a GUI executable instead of a console application.
+See the :variable:`CMAKE_MFC_FLAG` variable documentation to
 configure use of MFC for WinMain executables.  This property is
-initialized by the value of the variable CMAKE_WIN32_EXECUTABLE if it
-is set when a target is created.
+initialized by the value of the :variable:`CMAKE_WIN32_EXECUTABLE`
+variable if it is set when a target is created.

---

Summary of changes:
 Help/prop_tgt/WIN32_EXECUTABLE.rst | 11 ++-
 Help/variable/CMAKE_MFC_FLAG.rst   | 15 ---
 2 files changed, 14 insertions(+), 12 deletions(-)


hooks/post-receive
-- 
CMake
___

Re: [CMake] Odd Behavior in macOS Mojave

[Steven Stallion]

On Wed, Nov 14, 2018 at 10:54 AM Sean McBride  wrote:

> I see.  Well, I just checked my macOS 10.14.1 / Xcode 10.1 bot 
> "RogueResearch12" and indeed it does not have a /usr/include folder.  It is 
> however able to build CMake, VTK, and ITK nightly without any compiler errors.
>
> Perhaps it's not so much a CMake bug as a bug in the project you're trying to 
> build?

Interesting. I'll take another look - I wonder if it's a bad
interaction from calling clang from a custom command.

Thanks for taking a look!
Steve
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tips on reducing configure time

[Eric Noulard]

Le mer. 14 nov. 2018 à 13:25, Poughon Victor  a
écrit :

> Yes you are correct on all your observations. We already use ninja and
> ccache wherever we can. In fact we have an issue about the whole end-to-end
> build performance where we track all effort on this throughout the project
> (if you're interested:
> https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1649)
>

End-to-end build performance is a subject of interest to me, I'll have a
look.


> There are indeed quick and easy wins to be had with those tools (and we
> are working on it). But my original question is not about that. It's about
> speeding up the configure step with makefile generator. I still don't think
> it's normal that it does hundreds of thousands of I/O on files that are a
> few bytes or even empty. However it's possible that it's because we do
> something incorrect in our CMakeLists.txt and not CMake's fault.
>

I don't really know makefile-generator internals so I cannot tell.
For sur the current OTB build dir constructed with Makefile generator is
spitting out around 180 Makefile.
May be you can profile the cmake execution by building a debug version of
CMake and collect more precise insight on where the bottlenecks may reside.

You may track try_compile which could obviously be slow and may be
configure_file as well.
Otherwise I don't know, I guess you'll have to profile the cmake run.

It's true that a few minutes of configure is not much when doing a full
> build, but consider incremental builds where all you do is change one cxx
> file (and cmake is triggered because you changed git branch or something).
> Then the generate step is a significant part of the time you wait.
>

Yes that right.
Note however that changing git branch should nor per-se trigger a cmake run.
Only changing a CMakeLists.txt or configured file or explicitely specified
by
CMAKE_CONFIGURE_DEPENDS.

Otherwise changing branch with git that only modifies source shouldn't
trigger cmake rebuild.
I do that all the time in a classical git branch dev model.



-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Odd Behavior in macOS Mojave

[Sean McBride]

On Wed, 14 Nov 2018 10:43:28 -0600, Steven Stallion said:

>We first noticed that some sources would fail to find certain system
>headers (stddef.h in this case) when using Xcode 10 (also seen on
>Xcode 10.1). It looks like Apple decided to relocate system include
>paths under /Library /Developer and did away with /usr/include. After
>some spelunking, it looks like this was tucked away in the release
>notes for Xcode:
>https://developer.apple.com/documentation/xcode_release_notes/
>xcode_10_release_notes

I see.  Well, I just checked my macOS 10.14.1 / Xcode 10.1 bot 
"RogueResearch12" and indeed it does not have a /usr/include folder.  It is 
however able to build CMake, VTK, and ITK nightly without any compiler errors.

Perhaps it's not so much a CMake bug as a bug in the project you're trying to 
build?

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cmake 3.12 - python libs / 32 / 64 bits

[Marc CHEVRIER]

The way you proceed is wrong.
The system configuration is determined during the 'project' function call.
Setting information after this call is useless. So, in your example, on a
64bit system, the compilation configuration will be 64bit (variable
CMAKE_SIZEOF_VOID_P has value 8).
This explain why 'FIND_LIBRARY_USE_LIB32_PATHS' has no effect. This
property is taken in consideration only on 32bit systems.

Moreover, I am not sure that modifying variable 'CMAKE_SYSTEM_PROCESSOR' is
a valid action.

To configure a 32bit compilation environment, two possibilities:
* using environment variables: env CFLAGS=-m32 CXXFLAGS=-m32 cmake ...
* using a toolchain file: see
https://cmake.org/cmake/help/v3.13/manual/cmake-toolchains.7.html


Le mer. 14 nov. 2018 à 14:06, Stéphane Ancelot  a
écrit :

> Hi,
>
> My system is 64 bits but I can cross compile python c modules for 32 bits .
>
> Unfortunately I don't manage to retrieve python 32 libs , always the 64
> bits version is found.
>
>
> here is what I tried :
>
> cmake_minimum_required(VERSION 3.10)
> project(py_autom)
>
>
> set(CMAKE_SYSTEM_PROCESSOR "i686")
>
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" CACHE STRING "c++ flags")
> set(CMAKE_C_FLAGS   "${CMAKE_C_FLAGS} -m32" CACHE STRING "c flags")
>
> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS TRUE)
> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)
>
> include_directories(python2.6)
> find_package(Python2 COMPONENTS Development)
>
>
>
> message(STATUS "python ${PYTHON_INCLUDE_DIRS} ${Python2_LIBRARIES_DIR}
> ${Python2_FOUND}")
>
> Regards
>
> Steph
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Odd Behavior in macOS Mojave

[Steven Stallion]

On Wed, Nov 14, 2018 at 8:19 AM Sean McBride  wrote:

> Could you elaborate?  What odd behaviour are you seeing?  Any error message 
> to share?  What 'workaround package' are you speaking of?  What version of 
> Xcode?

We first noticed that some sources would fail to find certain system
headers (stddef.h in this case) when using Xcode 10 (also seen on
Xcode 10.1). It looks like Apple decided to relocate system include
paths under /Library /Developer and did away with /usr/include. After
some spelunking, it looks like this was tucked away in the release
notes for Xcode:
https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes

"The Command Line Tools package installs the macOS system headers
inside the macOS SDK. Software that compiles with the installed tools
will search for headers within the macOS SDK provided by either Xcode
at:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk

or the Command Line Tools at:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

depending on which is selected using xcode-select.

The command line tools will search the SDK for system headers by
default. However, some software may fail to build correctly against
the SDK and require macOS headers to be installed in the base system
under /usr/include. If you are the maintainer of such software, we
encourage you to update your project to work with the SDK or file a
bug report for issues that are preventing you from doing so. As a
workaround, an extra package is provided which will install the
headers to the base system. In a future release, this package will no
longer be provided. You can find this package at:

/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg


To make sure that you're using the intended version of the command
line tools, run xcode-select -s  or xcode select -s
/Library/Developer/CommandLineTools after installing."

Installing the package seemed to resolve the issues we had building
with AppleClang, which made me wonder if something is needed in the
platform modules to account for this change.

HTH,
Steve
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Preferred case for macro names?

[Ben Boeckel]

On Tue, Nov 13, 2018 at 11:36:24 +0100, Eric Noulard wrote:
> > My personal tendency is to use lower case for local variables and upper
> > case for global variables. May be we can normalize variables to upper case
> > regarding global variables used by CMake itself (which is globally the
> > current rule).
> 
> Having a convention for local is nice and I tend to prefix with _ (single
> or double) variables that should be local.
> lowercasing locals is fine too, however I think that enforcing casing on
> "user-defined" variable may not be desirable, concerning CMAKE_ CTEST_ and
> CPACK_
> I guess they already are all UPPERCASE so we may stick with this as a
> convention?

My personal style is to use lowercase for derived or internal variables
(and properties). Uppercase is left for environment (e.g., CMake) or
user variables. Note that CMake also defines some un-namespaced
variables including:

  - BUILD_SHARED_LIBS
  - BUILD_TESTING
  - many CTest variables (*_COMMAND, DART_TESTING_TIMEOUT, etc.)

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Preferred case for macro names?

[Ben Boeckel]

On Tue, Nov 13, 2018 at 06:11:26 -0500, David Cole via cmake-developers wrote:
> I would just like to point out that some modules (ExternalData,
> ExternalProject, to name two specific examples) adopted the convention
> to prefix all their provided function names with the module name and
> an underscore: for example, ExternalProject_Add and
> ExternalData_Expand_Arguments.
> 
> These functions adopt a mixed-case function naming convention, since
> the module name is mixed case, and since module names are file names,
> and some file systems have case sensitive file names .. they
> should stay that way regardless of any convention you may like to try
> to adopt elsewhere.

Agreed. I use lower case everywhere I can, but externalproject_add just
looks worse than ExternalProject_add (though I'd really prefer
external_project_add, that ship sailed long ago).

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Odd Behavior in macOS Mojave

[Sean McBride]

On Tue, 13 Nov 2018 18:42:43 -0600, Steven Stallion said:

>It appears there have been some changes to how macOS handles the
>system include path starting with macOS Mojave. It looks like Apple
>has provided a workaround package you can install to re-instate the
>/usr/include hierarchy, however I was wondering if this is something
>that could be handled by AppleClang support?

Could you elaborate?  What odd behaviour are you seeing?  Any error message to 
share?  What 'workaround package' are you speaking of?  What version of Xcode?

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada


-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, master, updated. v3.13.0-rc3-442-g1172724

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  117272412e9dee1a1595718590a48e4c6750df59 (commit)
   via  f835f189aeb38a791ad09ba5c2d89300a3fd16f1 (commit)
   via  4c0d97dd98805a5d9fc73ab9818a653888c16103 (commit)
   via  1b8f0ca5154c9fe8122b31e25dac65a4df94f5b1 (commit)
  from  aa4ab1f904dfd7f6e3a95d310cd4d38875902c4b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=117272412e9dee1a1595718590a48e4c6750df59
commit 117272412e9dee1a1595718590a48e4c6750df59
Merge: aa4ab1f f835f18
Author: Brad King 
AuthorDate: Wed Nov 14 13:59:10 2018 +
Commit: Kitware Robot 
CommitDate: Wed Nov 14 08:59:19 2018 -0500

Merge topic 'GNUInstallDirs-FreeBSD-info'

f835f189ae GNUInstallDirs: Update FreeBSD "info" destination to share/info
4c0d97dd98 GNUInstallDirs: Split "info" and "man" default logic
1b8f0ca515 Tests: Split GNUInstallDirs expectations for FreeBSD

Acked-by: Kitware Robot 
Acked-by: Rolf Eike Beer 
Merge-request: !2588


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f835f189aeb38a791ad09ba5c2d89300a3fd16f1
commit f835f189aeb38a791ad09ba5c2d89300a3fd16f1
Author: Tobias C. Berner 
AuthorDate: Sun Nov 11 20:04:46 2018 +0100
Commit: Brad King 
CommitDate: Tue Nov 13 13:35:50 2018 -0500

GNUInstallDirs: Update FreeBSD "info" destination to share/info

FreeBSD ports commit r484628 (Install texinfo files (GNU info) into
${PREFIX}/share/info, 2018-11-10) changed the "info" destination
from "info" to "share/info".  The commit included a patch to their
distribution of CMake to fix the `GNUInstallDirs` module too.
Apply a similar logic change to our upstream version of the module.

We already made a similar change for GNU/kFreeBSD in commit
v3.13.0-rc2~8^2 (GNUInstallDirs: Don't use BSD info and man paths on
GNU/kFreeBSD, 2018-10-21).

Fixes: #18585

diff --git a/Modules/GNUInstallDirs.cmake b/Modules/GNUInstallDirs.cmake
index 49d36f6..4db4e18 100644
--- a/Modules/GNUInstallDirs.cmake
+++ b/Modules/GNUInstallDirs.cmake
@@ -277,7 +277,7 @@ _GNUInstallDirs_cache_path(CMAKE_INSTALL_DATAROOTDIR "share"
 _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_DATADIR 
"${CMAKE_INSTALL_DATAROOTDIR}"
   "Read-only architecture-independent data (DATAROOTDIR)")
 
-if(CMAKE_SYSTEM_NAME MATCHES "^(([^k].*)?BSD|DragonFly)$")
+if(CMAKE_SYSTEM_NAME MATCHES "^(([^kF].*)?BSD|DragonFly)$")
   _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_INFODIR "info"
 "Info documentation (info)")
 else()
diff --git a/Tests/RunCMake/GNUInstallDirs/Opt-FreeBSD-stderr.txt 
b/Tests/RunCMake/GNUInstallDirs/Opt-FreeBSD-stderr.txt
index 09ae303..feb747b 100644
--- a/Tests/RunCMake/GNUInstallDirs/Opt-FreeBSD-stderr.txt
+++ b/Tests/RunCMake/GNUInstallDirs/Opt-FreeBSD-stderr.txt
@@ -3,7 +3,7 @@ CMAKE_INSTALL_DATADIR='share'
 CMAKE_INSTALL_DATAROOTDIR='share'
 CMAKE_INSTALL_DOCDIR='share/doc/Opt'
 CMAKE_INSTALL_INCLUDEDIR='include'
-CMAKE_INSTALL_INFODIR='info'
+CMAKE_INSTALL_INFODIR='share/info'
 CMAKE_INSTALL_LIBDIR='(lib|lib64)'
 CMAKE_INSTALL_LIBEXECDIR='libexec'
 CMAKE_INSTALL_LOCALEDIR='share/locale'
@@ -18,7 +18,7 @@ CMAKE_INSTALL_FULL_DATADIR='/opt/Opt/share'
 CMAKE_INSTALL_FULL_DATAROOTDIR='/opt/Opt/share'
 CMAKE_INSTALL_FULL_DOCDIR='/opt/Opt/share/doc/Opt'
 CMAKE_INSTALL_FULL_INCLUDEDIR='/opt/Opt/include'
-CMAKE_INSTALL_FULL_INFODIR='/opt/Opt/info'
+CMAKE_INSTALL_FULL_INFODIR='/opt/Opt/share/info'
 CMAKE_INSTALL_FULL_LIBDIR='/opt/Opt/(lib|lib64)'
 CMAKE_INSTALL_FULL_LIBEXECDIR='/opt/Opt/libexec'
 CMAKE_INSTALL_FULL_LOCALEDIR='/opt/Opt/share/locale'
diff --git a/Tests/RunCMake/GNUInstallDirs/Root-FreeBSD-stderr.txt 
b/Tests/RunCMake/GNUInstallDirs/Root-FreeBSD-stderr.txt
index 4be66bc..4284a15 100644
--- a/Tests/RunCMake/GNUInstallDirs/Root-FreeBSD-stderr.txt
+++ b/Tests/RunCMake/GNUInstallDirs/Root-FreeBSD-stderr.txt
@@ -3,7 +3,7 @@ CMAKE_INSTALL_DATADIR='usr/share'
 CMAKE_INSTALL_DATAROOTDIR='usr/share'
 CMAKE_INSTALL_DOCDIR='usr/share/doc/Root'
 CMAKE_INSTALL_INCLUDEDIR='usr/include'
-CMAKE_INSTALL_INFODIR='usr/info'
+CMAKE_INSTALL_INFODIR='usr/share/info'
 CMAKE_INSTALL_LIBDIR='usr/(lib|lib64)'
 CMAKE_INSTALL_LIBEXECDIR='usr/libexec'
 CMAKE_INSTALL_LOCALEDIR='usr/share/locale'
@@ -18,7 +18,7 @@ CMAKE_INSTALL_FULL_DATADIR='/usr/share'
 CMAKE_INSTALL_FULL_DATAROOTDIR='/usr/share'
 CMAKE_INSTALL_FULL_DOCDIR='/usr/share/doc/Root'
 CMAKE_INSTALL_FULL_INCLUDEDIR='/usr/include'
-CMAKE_INSTALL_FULL_INFODIR='/usr/info'
+CMAKE_INSTALL_FULL_INFODIR='/usr/share/info'
 CMAKE_INSTALL_FULL_LIBDIR='/usr/(lib|lib64)'
 

[CMake] cmake 3.12 - python libs / 32 / 64 bits

[Stéphane Ancelot]

Hi,

My system is 64 bits but I can cross compile python c modules for 32 bits .

Unfortunately I don't manage to retrieve python 32 libs , always the 64 
bits version is found.



here is what I tried :

cmake_minimum_required(VERSION 3.10)
project(py_autom)


set(CMAKE_SYSTEM_PROCESSOR "i686")

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" CACHE STRING "c++ flags")
set(CMAKE_C_FLAGS   "${CMAKE_C_FLAGS} -m32" CACHE STRING "c flags")

set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS TRUE)
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)

include_directories(python2.6)
find_package(Python2 COMPONENTS Development)



message(STATUS "python ${PYTHON_INCLUDE_DIRS} ${Python2_LIBRARIES_DIR} 
${Python2_FOUND}")


Regards

Steph
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tips on reducing configure time

[Poughon Victor]

Yes you are correct on all your observations. We already use ninja and ccache 
wherever we can. In fact we have an issue about the whole end-to-end build 
performance where we track all effort on this throughout the project (if you're 
interested: https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1649)

There are indeed quick and easy wins to be had with those tools (and we are 
working on it). But my original question is not about that. It's about speeding 
up the configure step with makefile generator. I still don't think it's normal 
that it does hundreds of thousands of I/O on files that are a few bytes or even 
empty. However it's possible that it's because we do something incorrect in our 
CMakeLists.txt and not CMake's fault.

It's true that a few minutes of configure is not much when doing a full build, 
but consider incremental builds where all you do is change one cxx file (and 
cmake is triggered because you changed git branch or something). Then the 
generate step is a significant part of the time you wait.

Victor Poughon

De : Eric Noulard 
Envoyé : mercredi 14 novembre 2018 12:34
À : Poughon Victor 
Cc : CMake Mailinglist 
Objet : Re: [CMake] Tips on reducing configure time


Le mer. 14 nov. 2018 à 12:06, Poughon Victor 
mailto:victor.poug...@cnes.fr>> a écrit :
Thanks for the replies

You can see configure times on our dashboard (switch to advanced view): 
https://dash.orfeo-toolbox.org/index.php?project=OTB
It ranges from 1-3min. There's even one windows machine that's at 4m30s.

Somes windows system are known to be slow on many files accesses.
However on this particular machine 
(https://dash.orfeo-toolbox.org/buildSummary.php?buildid=342008 I guess) you 
already seem
to be using NInja + MSVC. so many small files access to ?makefiles? should not 
be the culprit.

That said whatever the system your build and test time seems to dominate the 
overall time (in the CI).

I have had great speed-up experience using CMake+ninja+ccache  for our build in 
CI. We did go from 1 hour down to less than 10min.
We only have various linux build (no Windows) it is really a big time savior 
combo.

We even share the compil' cache between the CI and the developers. So everybody 
is feeding compile cache and takes benefits from others including CI.

You seem to be using that as well here:
https://dash.orfeo-toolbox.org/buildSummary.php?buildid=341993
and you get less than 5min build time which corroborate my suggestion.

The same machine build with clang: 
https://dash.orfeo-toolbox.org/buildSummary.php?buildid=342033 is lasting 30min+
and is not using ccache.

Thanks for the tip about Ninja generator, it's indeed much faster. But 
switching the entire dev team + CI servers from make to ninja is not really an 
option for us right now because of a bug in ninja that affects our SuperBuild 
configuration (see here if you're interested in the details: 
https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1625)

I see.
Not using ninja in the Superbuild case does not mean you cannot use it in other 
cases, right?
May be the one-size fits all is a little too much to ask at this point? My 
opinion though.
Did you report the issue upstream (ninja or cmake)?

I was impressed in the past by the amount of tests orfeo is doing, I'm still 
are !!
Are you running those tests in parallel (with ctest --parallel) ? It can be a 
time savior as well is the running machine has a fair amount of cores and 
memory.


--
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tips on reducing configure time

[Eric Noulard]

Le mer. 14 nov. 2018 à 12:06, Poughon Victor  a
écrit :

> Thanks for the replies
>
>
>
> You can see configure times on our dashboard (switch to advanced view):
> https://dash.orfeo-toolbox.org/index.php?project=OTB
>
> It ranges from 1-3min. There's even one windows machine that's at 4m30s.
>

Somes windows system are known to be slow on many files accesses.
However on this particular machine (
https://dash.orfeo-toolbox.org/buildSummary.php?buildid=342008 I guess) you
already seem
to be using NInja + MSVC. so many small files access to ?makefiles? should
not be the culprit.

That said whatever the system your build and test time seems to dominate
the overall time (in the CI).

I have had great speed-up experience using CMake+ninja+ccache  for our
build in CI. We did go from 1 hour down to less than 10min.
We only have various linux build (no Windows) it is really a big time
savior combo.

We even share the compil' cache between the CI and the developers. So
everybody is feeding compile cache and takes benefits from others including
CI.

You seem to be using that as well here:
https://dash.orfeo-toolbox.org/buildSummary.php?buildid=341993
and you get less than 5min build time which corroborate my suggestion.

The same machine build with clang:
https://dash.orfeo-toolbox.org/buildSummary.php?buildid=342033 is lasting
30min+
and is not using ccache.


> Thanks for the tip about Ninja generator, it's indeed much faster. But
> switching the entire dev team + CI servers from make to ninja is not really
> an option for us right now because of a bug in ninja that affects our
> SuperBuild configuration (see here if you're interested in the details:
> https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1625)
>

I see.
Not using ninja in the Superbuild case does not mean you cannot use it in
other cases, right?
May be the one-size fits all is a little too much to ask at this point? My
opinion though.
Did you report the issue upstream (ninja or cmake)?

I was impressed in the past by the amount of tests orfeo is doing, I'm
still are !!
Are you running those tests in parallel (with ctest --parallel) ? It can be
a time savior as well is the running machine has a fair amount of cores and
memory.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tips on reducing configure time

[Poughon Victor]

Thanks for the replies

You can see configure times on our dashboard (switch to advanced view): 
https://dash.orfeo-toolbox.org/index.php?project=OTB
It ranges from 1-3min. There's even one windows machine that's at 4m30s.

Thanks for the tip about Ninja generator, it's indeed much faster. But 
switching the entire dev team + CI servers from make to ninja is not really an 
option for us right now because of a bug in ninja that affects our SuperBuild 
configuration (see here if you're interested in the details: 
https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1625)


Victor Poughon

De : Eric Noulard 
Envoyé : mercredi 14 novembre 2018 11:12
À : Poughon Victor 
Cc : CMake Mailinglist 
Objet : Re: [CMake] Tips on reducing configure time

Hi Victor,
Le mer. 14 nov. 2018 à 10:20, Poughon Victor 
mailto:victor.poug...@cnes.fr>> a écrit :
Hi all

I am working on a large C++ project using CMake 
(https://www.orfeo-toolbox.org/) and our 'configure' step takes quite a lot of 
time. This can be annoying for developers working on features where the 
configure step needs to be re-run, or for CI in general.

Could you give us a clue on "takes quite a lot of time"?
Are we speaking of tens of seconds, minutes etc... ?


We have looked into it a bit and it seems like one issue is that the 
configure/generate steps do a lot of small files I/O. Specifically, using:

inotofy-wait -mr 

shows that "cmake ." causes about 150K file access/modify, etc. There are some 
especially guilty looking files like 'Makefile2.tmp' or 'progress.tmp' that 
appear thousands of times in most of the log file.

I have an SSD which somewhat helps, but for colleagues still on mechanical 
drives this is especially painful. Is there a way to disable writing all those 
files to the disk?

Any other tips on optimizing the performance of 'cmake .'?

Did you try to test drive a switch to ninja generator ?
Ninja generator generates only two files (build.ninja and rules.ninja) you 
won't have the "mny small files issue".
You can have long configuration times as well but not coming from file access.




Thanks,

Victor Poughon


--

Powered by www.kitware.com

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

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

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

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

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


--
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tips on reducing configure time

[Cristian Adam]

On Wed, Nov 14, 2018 at 10:20 AM Poughon Victor 
wrote:

> Hi all
>
> I am working on a large C++ project using CMake (
> https://www.orfeo-toolbox.org/) and our 'configure' step takes quite a
> lot of time. This can be annoying for developers working on features where
> the configure step needs to be re-run, or for CI in general.
>
> We have looked into it a bit and it seems like one issue is that the
> configure/generate steps do a lot of small files I/O. Specifically, using:
>
> inotofy-wait -mr 
>
> shows that "cmake ." causes about 150K file access/modify, etc. There are
> some especially guilty looking files like 'Makefile2.tmp' or 'progress.tmp'
> that appear thousands of times in most of the log file.
>
> I have an SSD which somewhat helps, but for colleagues still on mechanical
> drives this is especially painful. Is there a way to disable writing all
> those files to the disk?
>
> Any other tips on optimizing the performance of 'cmake .'?
>
> Thanks,
>
> Victor Poughon
>
>
Hi,

if a subsequent CMake  run is faster than the initial one, you can have a
look at
https://github.com/cristianadam/cmake-checks-cache

If you cache the results of the configure checks you can have the initial
run as fast as subsequent ones!

Cheers,
Cristian.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tips on reducing configure time

[Eric Noulard]

Hi Victor,

Le mer. 14 nov. 2018 à 10:20, Poughon Victor  a
écrit :

> Hi all
>
> I am working on a large C++ project using CMake (
> https://www.orfeo-toolbox.org/) and our 'configure' step takes quite a
> lot of time. This can be annoying for developers working on features where
> the configure step needs to be re-run, or for CI in general.
>

Could you give us a clue on "takes quite a lot of time"?
Are we speaking of tens of seconds, minutes etc... ?


>
> We have looked into it a bit and it seems like one issue is that the
> configure/generate steps do a lot of small files I/O. Specifically, using:
>
> inotofy-wait -mr 
>
> shows that "cmake ." causes about 150K file access/modify, etc. There are
> some especially guilty looking files like 'Makefile2.tmp' or 'progress.tmp'
> that appear thousands of times in most of the log file.
>
> I have an SSD which somewhat helps, but for colleagues still on mechanical
> drives this is especially painful. Is there a way to disable writing all
> those files to the disk?
>
> Any other tips on optimizing the performance of 'cmake .'?
>

Did you try to test drive a switch to ninja generator ?
Ninja generator generates only two files (build.ninja and rules.ninja) you
won't have the "mny small files issue".
You can have long configuration times as well but not coming from file
access.




>
> Thanks,
>
> Victor Poughon
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Tips on reducing configure time

[Poughon Victor]

Hi all

I am working on a large C++ project using CMake 
(https://www.orfeo-toolbox.org/) and our 'configure' step takes quite a lot of 
time. This can be annoying for developers working on features where the 
configure step needs to be re-run, or for CI in general. 

We have looked into it a bit and it seems like one issue is that the 
configure/generate steps do a lot of small files I/O. Specifically, using:

inotofy-wait -mr 

shows that "cmake ." causes about 150K file access/modify, etc. There are some 
especially guilty looking files like 'Makefile2.tmp' or 'progress.tmp' that 
appear thousands of times in most of the log file.

I have an SSD which somewhat helps, but for colleagues still on mechanical 
drives this is especially painful. Is there a way to disable writing all those 
files to the disk?

Any other tips on optimizing the performance of 'cmake .'?

Thanks,

Victor Poughon


-- 

Powered by www.kitware.com

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

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

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

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

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