[ANNOUNCE] CMake 3.16.0-rc1 is ready for testing

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANNOUNCE] CMake 3.16.0-rc1 is ready for testing

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

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

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

Some of the more significant changes in CMake 3.16 are:

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.

* The "target_precompile_headers()" command was added to specify a
  list of headers to precompile for faster compilation times.

* The "UNITY_BUILD" target property was added to tell generators to
  batch include source files for faster compilation times.

* The "find_file()", "find_library()", "find_path()",
  "find_package()", and "find_program()" commands have learned to
  check the following variables to control searching

  * "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
    the cmake-specific environment variables.

  * "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
    specific cache variables.

  * "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
    cmake platform specific variables.

  * "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
    "<PackageName>_ROOT" variables.

  * "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
    searching the standard system environment variables.

* The "file()" command learned a new sub-command,
  "GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
  list of libraries linked by an executable or library. This sub-
  command is intended as a replacement for "GetPrerequisites".

* "ctest(1)" now has the ability to serialize tests based on
  hardware requirements for each test. See Hardware Allocation for
  details.

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  front. One may manually enable runtime linking for shared libraries
  and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
  in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
  variable). One may manually enable runtime linking for executables
  by adding "-Wl,-brtl" to their link flags (e.g. in the
  "CMAKE_EXE_LINKER_FLAGS" variable).

* "cmake(1)" "-E" now supports "true" and "false" commands, which do
  nothing while returning exit codes of 0 and 1, respectively.

* "cmake(1)" gained a "--trace-redirect=<file>" command line option
  that can be used to redirect "--trace" output to a file instead of
  "stderr".

* The "cmake(1)" "--loglevel" command line option has been renamed
  to "--log-level" to make it consistent with the naming of other
  command line options.  The "--loglevel" option is still supported to
  preserve backward compatibility.

* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
  deprecated.  Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
  instead.

* The "GetPrerequisites" module has been deprecated, as it has been
  superceded by "file(GET_RUNTIME_DEPENDENCIES)".


CMake 3.16 Release Notes
************************

Changes made since CMake 3.15 include the following.


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


Languages
---------

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.


Compilers
---------

* The "Clang" compiler is now supported on "Solaris".


Platforms
---------

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  front. One may manually enable runtime linking for shared libraries
  and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
  in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
  variable). One may manually enable runtime linking for executables
  by adding "-Wl,-brtl" to their link flags (e.g. in the
  "CMAKE_EXE_LINKER_FLAGS" variable).


Command-Line
------------

* "cmake(1)" "-E" now supports "true" and "false" commands, which do
  nothing while returning exit codes of 0 and 1, respectively.

* "cmake(1)" gained a "--trace-redirect=<file>" command line option
  that can be used to redirect "--trace" output to a file instead of
  "stderr".

* The "cmake(1)" "--loglevel" command line option has been renamed
  to "--log-level" to make it consistent with the naming of other
  command line options.  The "--loglevel" option is still supported to
  preserve backward compatibility.


Commands
--------

* The "add_test()" command learned the option "COMMAND_EXPAND_LISTS"
  which causes lists in the "COMMAND" argument to be expanded,
  including lists created by generator expressions.

* The "file()" command learned a new sub-command,
  "GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
  list of libraries linked by an executable or library. This sub-
  command is intended as a replacement for "GetPrerequisites".

* The "find_file()", "find_library()", "find_path()",
  "find_package()", and "find_program()" commands have learned to
  check the following variables to control searching

  * "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
    the cmake-specific environment variables.

  * "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
    specific cache variables.

  * "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
    cmake platform specific variables.

  * "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
    "<PackageName>_ROOT" variables.

  * "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
    searching the standard system environment variables.

* The "find_package()" command has learned to check the following
  variables to control searching

  * "CMAKE_FIND_USE_PACKAGE_REGISTRY" - Controls the searching the
    cmake user registry.

* The "message()" command learned indentation control with the new
  "CMAKE_MESSAGE_INDENT" variable.

* The "target_precompile_headers()" command was added to specify a
  list of headers to precompile for faster compilation times.


Variables
---------

* The "CMAKE_CUDA_RESOLVE_DEVICE_SYMBOLS" variable has been
  introduced to optionally initialize the
  "CUDA_RESOLVE_DEVICE_SYMBOLS" target property.

* The "CMAKE_ECLIPSE_RESOURCE_ENCODING" variable was added to
  specify the resource encoding for the the "Eclipse CDT4" extra
  generator.


Properties
----------

* The "BUILD_RPATH" and "INSTALL_RPATH" target properties now
  support "generator expressions".

* The "INSTALL_REMOVE_ENVIRONMENT_RPATH" target property was added
  to remove compiler-defined "RPATH" entries from a target. This
  property is initialized by the
  "CMAKE_INSTALL_REMOVE_ENVIRONMENT_RPATH" variable.

* The "PRECOMPILE_HEADERS" target property was added to specify a
  list of headers to precompile for faster compilation times. Set it
  using the "target_precompile_headers()" command.

* The "UNITY_BUILD" target property was added to tell generators to
  batch include source files for faster compilation times.

* The "VS_CONFIGURATION_TYPE" target property now supports
  "generator expressions".

* The "VS_DPI_AWARE" target property was added to tell Visual Studio
  Generators to set the "EnableDpiAwareness" property in ".vcxproj"
  files.

* The "XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING" target property was
  added to tell the "Xcode" generator to set the value of the "Allow
  debugging when using document Versions Browser" schema option.


Modules
-------

* The "FindDoxygen" module "doxygen_add_docs()" command gained a new
  "USE_STAMP_FILE" option.  When this option present, the custom
  target created by the command will only re-run Doxygen if any of the
  source files have changed since the last successful run.

* The "FindGnuTLS" module now provides an imported target.

* The "FindPackageHandleStandardArgs" module
  "find_package_handle_standard_args()" command gained a new
  "REASON_FAILURE_MESSAGE" option to specify a message giving the
  reason for the failure.

* The "FindPkgConfig" module "pkg_search_module()" macro now defines
  a "<prefix>_MODULE_NAME" result variable containing the first
  matching module name.

* The "FindPython3" and "FindPython" modules gained options to
  control which "ABIs" will be searched.

* The "FindPython3", "FindPython2", and "FindPython" modules now
  support direct specification of artifacts via cache entries.


Autogen
-------

* When using "AUTOMOC", CMake now generates the "-p" path prefix
  option for "moc".  This ensures that "moc" output files are
  identical on different build setups (given, that the headers
  compiled by "moc" are in an "include directory"). Also it ensures
  that "moc" output files will compile correctly when the source
  and/or build directory is a symbolic link.

  The "moc" path prefix generation behavior can be configured by
  setting the new "CMAKE_AUTOMOC_PATH_PREFIX" variable and/or
  "AUTOMOC_PATH_PREFIX" target property.


CTest
-----

* "ctest(1)" now has the ability to serialize tests based on
  hardware requirements for each test. See Hardware Allocation for
  details.

* A new test property, "SKIP_REGULAR_EXPRESSION", has been added.
  This property is similar to "FAIL_REGULAR_EXPRESSION" and
  "PASS_REGULAR_EXPRESSION", but with the same meaning as
  "SKIP_RETURN_CODE". This is useful, for example, in cases where the
  user has no control over the return code of the test. For example,
  in Catch2, the return value is the number of assertion failed,
  therefore it is impossible to use it for "SKIP_RETURN_CODE".


CPack
-----

* CPack variable "CPACK_INSTALL_CMAKE_CONFIGURATIONS" was added to
  control what configurations are to be packaged for multi-
  configuration CMake generators.

* The "CPack DEB Generator" is now able to format generic text
  (usually used as the description for multiple CPack generators)
  according to the Debian Policy Manual.  See the
  "CPACK_PACKAGE_DESCRIPTION_FILE" and
  "CPACK_DEBIAN_<COMPONENT>_DESCRIPTION" variables.

* The "CPack Archive Generator" learned to generate ".tar.zst"
  packages with Zstandard compression.


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

* An explicit deprecation diagnostic was added for policy "CMP0067"
  ("CMP0066" and below were already deprecated). The "cmake-
  policies(7)" manual explains that the OLD behaviors of all policies
  are deprecated and that projects should port to the NEW behaviors.

* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
  deprecated.  Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
  instead.

* The "GetPrerequisites" module has been deprecated, as it has been
  superceded by "file(GET_RUNTIME_DEPENDENCIES)".

* The "CPACK_INSTALL_SCRIPT" variable has been deprecated in favor
  of the new, more accurately named "CPACK_INSTALL_SCRIPTS" variable.


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

* The "cmake(1)" "-C <initial-cache>" option now evaluates the
  initial cache script with "CMAKE_SOURCE_DIR" and "CMAKE_BINARY_DIR"
  set to the top-level source and build trees.

* The "cmake(1)" "-E remove_directory" command-line tool, when given
  the path to a symlink to a directory, now removes just the symlink.
  It no longer removes content of the linked directory.

* The "ctest(1)"  "--build-makeprogram" command-line option now
  specifies the make program used when configuring a project with the
  "Ninja" generator or the Makefile Generators.

* The "ExternalProject" module "ExternalProject_Add()" command has
  been updated so that "GIT_SUBMODULES """ initializes no submodules.
  See policy "CMP0097".

* The "FindGTest" module has been updated to recognize MSVC build
  trees generated by GTest 1.8.1.

* The "project()" command no longer strips leading zeros in version
  components.  See policy "CMP0096".

* The Qt Compressed Help file is now named "CMake.qch", which no
  longer contains the release version in the file name.  When CMake is
  upgraded in-place, the name and location of this file will remain
  constant. Tools such as IDEs, help viewers, etc. should now be able
  to refer to this file at a fixed location that remains valid across
  CMake upgrades.

* "RPATH" entries are properly escaped in the generated CMake
  scripts used for installation.  See policy "CMP0095".

* When using "CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS" on Windows the auto-
  generated exports are now updated only when the object files
  providing the symbols are updated.
--

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
Reply | Threaded
Open this post in threaded view
|

Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

Paul Smith
On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> * The "UNITY_BUILD" target property was added to tell generators to
>   batch include source files for faster compilation times.

Are there any instructions on how to make this work?  I tried this:

  cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON .

Then ran "make".  The output showed I had just as many output .o files
as input .cpp files and that make ran one compile command per .cpp
file.

Is there something else I need to do to enable unity builds in my cmake
files, than just give the above option?  The docs imply that the above
is all that's needed.

Cheers!

--

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Unity builds vs. compile_commands.json (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

Paul Smith
In reply to this post by CMake mailing list
On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> * The "UNITY_BUILD" target property was added to tell generators to
>   batch include source files for faster compilation times.

For some reason this didn't work with my actual cmake environment, but
I could enable it on a simple test environment.  I can look into that
later.

Here my concern is that you cannot use unity builds if you need
compile_commands.json (-DCMAKE_EXPORT_COMPILE_COMMANDS=ON); for example
if this is required by your IDE or other build tools.  When unity
builds are enabled the json file is not usable since it contains only
commands for the unity source files and doesn't describe the original
source files.

Is there an intent to address this before the 3.16 release?  

Or is this a known limitation, which may or may not be addressed in
some future version of CMake?

If the latter it should probably be added to the release notes and/or
documentation for unity builds.

Thanks!

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

Alan W. Irwin-2
In reply to this post by Paul Smith
On 2019-10-10 18:21-0400 Paul Smith wrote:

> On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
>> * The "UNITY_BUILD" target property was added to tell generators to
>>   batch include source files for faster compilation times.
>
> Are there any instructions on how to make this work?  I tried this:
>
>  cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON .
>
> Then ran "make".  The output showed I had just as many output .o files
> as input .cpp files and that make ran one compile command per .cpp
> file.
>
> Is there something else I need to do to enable unity builds in my cmake
> files, than just give the above option?  The docs imply that the above
> is all that's needed.

Hi Paul:

I have never tried unity builds, but your question did inspire me to
look at [the unity build
documentation](https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html)
which if you follow the links to other related documentation does imply what
you have done above is correct and should by default group 8
source-code files into a lump to be compiled together.  Since you are
not getting that behaviour, I am wondering if one or more of the
documented reasons for skipping unity builds is making a difference in your
case. Those reasons are the following:

"The source files marked by GENERATED will be skipped from unity build. This applies also for the source files marked with SKIP_UNITY_BUILD_INCLUSION.

The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped."

Good luck, and I hope you will keep the list informed of any further
progress you make with your unity build experiments.

Alan
__________________________
Alan W. Irwin

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.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Unity builds vs. compile_commands.json

CMake mailing list
In reply to this post by Paul Smith
On 10/10/19 6:53 PM, Paul Smith wrote:
> Is there an intent to address this before the 3.16 release?  
>
> Or is this a known limitation, which may or may not be addressed in
> some future version of CMake?
>
> If the latter it should probably be added to the release notes and/or
> documentation for unity builds.

I've opened an issue for it:

* https://gitlab.kitware.com/cmake/cmake/issues/19826

This won't block the release so I've updated the documentation to
mention this limitation.

-Brad
--

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

CMake mailing list
In reply to this post by Alan W. Irwin-2
On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin
<[hidden email]> wrote:
> The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped."

This is by far the most likely reason. We added this restriction
because we don't want files that have different COMPILE_FLAGS etc. to
be lumped together in a unity file. We decided that this was good
enough as a first past, but the way forward is to intelligently group
together files that have the same COMPILE_OPTIONS,
COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES.

Kyle
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

Paul Smith
On Fri, 2019-10-11 at 10:17 -0400, Kyle Edwards wrote:

> On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin
> <
> [hidden email]
> > wrote:
> > The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS,
> > COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped."
>
> This is by far the most likely reason. We added this restriction
> because we don't want files that have different COMPILE_FLAGS etc. to
> be lumped together in a unity file. We decided that this was good
> enough as a first past, but the way forward is to intelligently group
> together files that have the same COMPILE_OPTIONS,
> COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES.

I saw this in the manual, and I interpreted it to mean that if we used
something like set_source_files_properties() or set_property(SOURCE) to
set these properties on specific source files, then those files which
are impacted by this won't be part of unity builds.

That seems quite sensible to me.

However, I don't do that hardly anywhere at all; maybe one or two files
have an extra INCLUDE_DIRECTORIES setting or similar.

Virtually all my properties are set on a per-target basis, so I assumed
they wouldn't be an issue here.

Am I misunderstanding that?

It's also possible that a previous attempt to introduce unity builds to
our setup via cotire is interfering with the new, standardized unity
builds.  I am not too familiar with the details of that but I can try
to look into it.

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

Alan W. Irwin-2
On 2019-10-12 15:40-0400 Paul Smith wrote:

> On Fri, 2019-10-11 at 10:17 -0400, Kyle Edwards wrote:
>> On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin
>> <
>> [hidden email]
>>> wrote:
>>> The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS,
>>> COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped."
>>
>> This is by far the most likely reason. We added this restriction
>> because we don't want files that have different COMPILE_FLAGS etc. to
>> be lumped together in a unity file. We decided that this was good
>> enough as a first past, but the way forward is to intelligently group
>> together files that have the same COMPILE_OPTIONS,
>> COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES.
>
> I saw this in the manual, and I interpreted it to mean that if we used
> something like set_source_files_properties() or set_property(SOURCE) to
> set these properties on specific source files, then those files which
> are impacted by this won't be part of unity builds.
>
> That seems quite sensible to me.
>
> However, I don't do that hardly anywhere at all; maybe one or two files
> have an extra INCLUDE_DIRECTORIES setting or similar.
>
> Virtually all my properties are set on a per-target basis, so I assumed
> they wouldn't be an issue here.
>
> Am I misunderstanding that?

I think the current documentation is ambiguous about this.  But
certain target and directory properties can affect the flags used to
compile the source code just as much as source code properties.  So I
am virtually positive the implementation has to pay attention to all
these sources of properties to decide what can/cannot be lumped into a
Unity source file.  If Kyle confirms this guess, then the
documentation should be changed accordingly to remove the ambiguity
about this.

Alan
__________________________
Alan W. Irwin

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.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

Paul Smith
On Sat, 2019-10-12 at 19:25 -0700, Alan W. Irwin wrote:

> > Virtually all my properties are set on a per-target basis, so I assumed
> > they wouldn't be an issue here.
> >
> > Am I misunderstanding that?
>
> I think the current documentation is ambiguous about this.  But
> certain target and directory properties can affect the flags used to
> compile the source code just as much as source code properties.  So I
> am virtually positive the implementation has to pay attention to all
> these sources of properties to decide what can/cannot be lumped into a
> Unity source file.  If Kyle confirms this guess, then the
> documentation should be changed accordingly to remove the ambiguity
> about this.

I know no more than you but I'm quite sure that it's not the case that
adding library/executable-level options can cause unity to be disabled.
I've never heard of _ANY_ such target that didn't have at least some
properties defined for it.

A unity source file can lump together N real source files from the same
target (library/executable) as long as those files don't have extra
source-specific flags, because all other files in a given target have
the same flags.

--

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

CMake mailing list
In reply to this post by Paul Smith
Hi Paul,

As another reference point, I verified that -DCMAKE_UNITY_BUILD=ON
works with the VTK-m ( https://gitlab.kitware.com/vtk/vtk-m ) project.
I only verified using a clean CMake 3.16 build directory.

On Thu, Oct 10, 2019 at 6:43 PM Paul Smith <[hidden email]> wrote:

>
> On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> > * The "UNITY_BUILD" target property was added to tell generators to
> >   batch include source files for faster compilation times.
>
> Are there any instructions on how to make this work?  I tried this:
>
>   cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON .
>
> Then ran "make".  The output showed I had just as many output .o files
> as input .cpp files and that make ran one compile command per .cpp
> file.
>
> Is there something else I need to do to enable unity builds in my cmake
> files, than just give the above option?  The docs imply that the above
> is all that's needed.
>
> Cheers!
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

Alan W. Irwin-2
In reply to this post by Paul Smith
On 2019-10-13 17:15-0400 Paul Smith wrote:

> A unity source file can lump together N real source files from the same
> target (library/executable) as long as those files don't have extra
> source-specific flags, because all other files in a given target have
> the same flags.

I agree that it is not at all clear whether this is the cause of the
issue.  So I will stop speculating about that cause even though that
is a fun activity.  :-)

Nevertheless, it does sound like your complex test case does expose
some issue with EITHER how you have implemented the build system for
your complex case OR how CMake currently rejects certain builds from
being included in Unity builds.  So to figure out which it is, I think
your next step should be to attempt to implement the simplest possible
self-contained test case that illustrates the Unity exclusion issue
you have found.

I believe that course has already been suggested in this thread so I
am seconding that motion.  My own experiences with such
implementations is I often cannot demonstrate the issue in a simple
way, i.e., the "CMake bug" often tends to be due to an issue with my
implementation of the build system for the complex case.  However, when
I have demonstrated with such a simple test case there really is a
CMake bug, that test case normally helps CMake developers in a big way
to find and fix the issue.

Alan
__________________________
Alan W. Irwin

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.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

Powered by www.kitware.com

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

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

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

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

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