Discussion:
[cmake-developers] [ANNOUNCE] CMake 3.13.0-rc3 is ready for testing
Robert Maynard
2018-11-07 17:21:32 UTC
Permalink
I am proud to announce the third CMake 3.13 release candidate.
https://cmake.org/download/

The first 3.13.0 release candidates included a change to allow
generator expressions in "install(CODE)" and "install(SCRIPT)".
This has been reverted in rc2 due to breaking backwards
compatibility. See issue #18435.

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

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

Some of the more significant changes in CMake 3.13 are:

* The Visual Studio Generators for VS 2010 and above learned to
support the "INTERPROCEDURAL_OPTIMIZATION" target property and
supporting "CheckIPOSupported" module.

* The "Green Hills MULTI" generator has been updated to include
support for platform, architecture, and toolset selection.

* The "cmake" command gained the "-S <source_dir>" command line
option to specify the location of the source directory. This option
can be used independently of "-B".

* The "cmake" command gained the "-B <build_dir>" command line
option to specify the location of the build directory. This option
can be used independently of "-S".

* The "cmake" "-E create_symlink" command can now be used on
Windows.

* The "target_link_directories()" command was created to specify
link directories for targets and their dependents.

* The "target_link_options()" command was created to specify link
options for targets and their dependents.

* The "target_link_libraries()" command may now be called to modify
targets created outside the current directory. See policy "CMP0079".

* The "install(TARGETS)" command learned to install targets created
outside the current directory.

* A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to
set the debugging command line arguments with Visual Studio
Generators for VS 2010 and above.

* A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the
debugging environment with Visual Studio Generators for VS 2010 and
above.

* The "option()" command now honors an existing normal variable of
the same name and does nothing instead of possibly creating a cache
entry (or setting its type) and removing the normal variable. See
policy "CMP0077".

* The "target_sources()" command now interprets relative source file
paths as relative to the current source directory. This simplifies
incrementally building up a target's sources from subdirectories.
The "CMP0076" policy was added to provide backward compatibility
with the old behavior where required.


CMake 3.13 Release Notes
************************

Changes made since CMake 3.12 include the following.


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


Generators
----------

* The Visual Studio Generators for VS 2010 and above learned to
support the "INTERPROCEDURAL_OPTIMIZATION" target property and
supporting "CheckIPOSupported" module.

* The "Xcode" generator learned to configure more Xcode Scheme
fields. See the "CMAKE_XCODE_GENERATE_SCHEME" variable.

* The "Green Hills MULTI" generator has been updated:

* Added support for architecture selection through
"CMAKE_GENERATOR_PLATFORM": e.g. "arm", "ppc", and "86".

* Added support for toolset selection through
"CMAKE_GENERATOR_TOOLSET", e.g. "comp_201205", "comp_201510",
"comp_201722_beta".

* Added support for platform selection through
"GHS_TARGET_PLATFORM", e.g. "integrity", "linux", "standalone",
etc.

* No longer checks that "arm" based compilers are installed but
ensures that the correct "gbuild.exe" exists.

* No longer hard-codes ARM files, BSP, toolset, or OS locations.


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

* The "cmake(1)" command gained the "-S <source_dir>" command line
option to specify the location of the source directory. This option
can be used independently of "-B".

* The "cmake(1)" command gained the "-B <build_dir>" command line
option to specify the location of the build directory. This option
can be used independently of "-S".

* The "cmake(1)" "-E create_symlink" command can now be used on
Windows.


Commands
--------

* The "add_custom_command()" and "add_custom_target()" commands
learned to support generator expressions in "WORKING_DIRECTORY"
options.

* The "add_link_options()" command was created to add link options
in the current directory.

* The "install(TARGETS)" command learned to install targets created
outside the current directory.

* The "link_directories()" command gained options to control
insertion position.

* The "list(SORT)" command gained options to control the comparison
operation used to order the entries.

* The "math()" command gained options for hexadecimal.

* The "target_link_directories()" command was created to specify
link directories for targets and their dependents.

* The "target_link_options()" command was created to specify link
options for targets and their dependents.

* The "target_link_libraries()" command may now be called to modify
targets created outside the current directory. See policy "CMP0079".


Variables
---------

* A "CMAKE_AUTOGEN_VERBOSE" variable was added to optionally
increase the verbosity of "AUTOMOC", "AUTOUIC" and "AUTORCC" from
within CMake project code.

* A "CMAKE_VS_GLOBALS" variable was added to initialize
"VS_GLOBAL_<variable>" target properties on targets as they are
created.


Properties
----------

* The "DEPLOYMENT_ADDITIONAL_FILES" target property was added to
tell the "Visual Studio 9 2008" generator to specify additional
files for deployment to WinCE devices for remote debugging.

* The "INTERFACE_LINK_DEPENDS" target property was created to
specify transitive link dependencies on files.

* The "LINK_DEPENDS" target property learned to support "generator
expressions".

* "LINK_DIRECTORIES" and "INTERFACE_LINK_DIRECTORIES" target
properties were added to collect link directories for a target and
its dependents. Use the "target_link_directories()" command to set
them.

* "LINK_OPTIONS" and "INTERFACE_LINK_OPTIONS" target properties were
added to collect link options for a target and its dependents. Use
the "target_link_options()" command to set them.

* A "LINK_OPTIONS" directory property was added to collect link
options for targets created under the current directory. Use the
"add_link_options()" command to set it.

* A "STATIC_LIBRARY_OPTIONS" target property was created to specify
archiver options to use when creating static libraries.

* A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to
set the debugging command line arguments with Visual Studio
Generators for VS 2010 and above.

* A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the
debugging environment with Visual Studio Generators for VS 2010 and
above.

* The "VS_DEBUGGER_COMMAND" and "VS_DEBUGGER_WORKING_DIRECTORY"
target properties now support generator expressions.


Modules
-------

* The "FindBoost" module gained a "Boost_ARCHITECTURE" option to
specify a Boost architecture-specific library filename fragment.

* The "FindCURL" module learned to find debug and release variants
separately.

* The "FindMatlab" module gained new components "ENGINE_LIBRARY" and
"DATAARRAY_LIBRARY" to request finding the Matlab C++ Engine and
DataArray libraries respectively.

* The "FindMatlab" module now explicitly exports mexFunction in
Visual Studio.

* The "FindMatlab" module gained a new "MCC_COMPILER" component to
request finding the Matlab Compiler add-on.

* The "FindPkgConfig" module gained an option to create imported
targets in global scope.

* The "FindPkgConfig" module gained support for "<" and ">"
operators for version checks in addition to the already supported
operators ">=", "<=", and "=".

* Modules "FindPython3", "FindPython2" and "FindPython" gain
capability to control order of resource lookup on macOS (Framework)
and Windows (Registry).

* The "FindSubversion" module "Subversion_WC_INFO" command gained an
"IGNORE_SVN_FAILURE" option to suppress failures, e.g. when the
source tree is not under Subversion control.

* The "UseSWIG" module learned to manage target property
"INCLUDE_DIRECTORIES" for "SWIG" compilation.


CTest
-----

* "ctest(1)" gained a "--progress" option to enable a live test
progress summary when output goes to a terminal.


CPack
-----

* The "CPack DEB Generator" learned to split debug symbols into a
corresponding .ddeb package when "CPACK_DEBIAN_DEBUGINFO_PACKAGE" is
set.

* The "CPack DEB Generator" learned to honor the "SOURCE_DATE_EPOCH"
environment variable when packaging files. This is useful for
generating reproducible packages.

* CPack gained a new "CPack External Generator" which is used to
export the CPack metadata in a format that other software can
understand. The intention of this generator is to allow external
packaging software to take advantage of CPack's features when it may
not be possible to use CPack for the entire packaging process.


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

* An explicit deprecation diagnostic was added for policies
"CMP0055" through "CMP0063" ("CMP0054" 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.


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

* The precompiled binaries provided on "cmake.org" now include
qthelp- format documentation.

* The "option()" command now honors an existing normal variable of
the same name and does nothing instead of possibly creating a cache
entry (or setting its type) and removing the normal variable. See
policy "CMP0077".

* The Makefile Generators learned to remove custom command and
custom target byproducts during "make clean".

* The "target_sources()" command now interprets relative source file
paths as relative to the current source directory. This simplifies
incrementally building up a target's sources from subdirectories.
The "CMP0076" policy was added to provide backward compatibility
with the old behavior where required.

* The "BundleUtilities" module may no longer be included at
configure time. This was always a bug anyway. See policy "CMP0080".

* The "UseSWIG" module has changed strategy for target naming. See
policy "CMP0078".

* The "LINK_DIRECTORIES" target property now expects absolute paths.
See policy "CMP0081".

* The CPack generators have been moved into their own separate
section in the documentation, rather than having the documentation
in their internal implementation modules. These internal
implementation modules are also no longer available to scripts that
may have been incorrectly including them, because they should never
have been available in the first place.

----------------------------------------------------------------------------
Changes made since CMake 3.13.0-rc2:

Brad King (12):
FindMPI: Pass -pthread to CUDA compiler through -Xcompiler
set_directory_properties: Restore in script mode
Flang: Fix command-line used to preprocess sources
CSharp: Fix regression in VS project type selection for custom target
curl: Update script to get curl 7.62.0
curl: Update build within CMake to account for 7.62 changes
FindProtobuf: Add missing link dependencies on threads
curl: Modernize tiny test code used for build inside CMake
curl: backport upstream fix to 7.62.0 regression
add_custom_{command,target}: Fix WORKING_DIRECTORY leading genex
FindBoost: Add explicit Boost_ARCHITECTURE option
CMake 3.13.0-rc3

Craig Scott (3):
Help: Fix generators link in cpack(1) manual
CPack: Rename Ext generator to External
Help: Use correct CPack generator names

Curl Upstream (1):
curl 2018-10-30 (19667715)

Ivan Pozdeev (2):
FindOpenMP: Fix warnings with -Wstrict-prototypes
FindOpenMP: Log error output

Jakub Benda (2):
FindBLAS: Correct symbol searched in BLAS95 wrapper
FindLAPACK: Correct library name and symbol searched in LAPACK95 wrapper

Maikel van den Hurk (1):
QNX: Update qcc depfile flags to be compliant with ccache

Marc Chevrier (2):
Help: clarify "LINKER:" prefix usage
UseSWIG: multiple input files must be supported in version 2

Martin Quinson (1):
FindBoost: Add support for stacktrace components

Robert Maynard (1):
CUDA: Filter out non-static libraries during device linking

Sylvain Joubert (3):
UseSWIG: Typo, add missing letter
UseSWIG: Add target language and input file in command description
FindPostgreSQL: Search for version 11

Vladimir Penev (1):
server: Fix assertion failure on directory paths in file monitor
--
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
Oleh Kravchenko
2018-11-20 14:19:29 UTC
Permalink
Hello CMake Developers,

My use case is to use UNIX timestamp from git history to setup
SOURCE_DATE_EPOCH and get the same binary.
I would like to set SOURCE_DATE_EPOCH environment variable from CMake
during configuration step.

How I can do it?

-- Best regards, Oleh Kravchenko
Sergei Nikulov
2018-11-20 15:13:47 UTC
Permalink
Post by Oleh Kravchenko
Hello CMake Developers,
My use case is to use UNIX timestamp from git history to setup
SOURCE_DATE_EPOCH and get the same binary.
I would like to set SOURCE_DATE_EPOCH environment variable from CMake
during configuration step.
How I can do it?
As per manual https://cmake.org/cmake/help/latest/command/set.html
set(ENV{SOURCE_DATE_EPOCH} <value>...)
should work during configuration step.

Should not work during build step when you invoke make or ninja.
Post by Oleh Kravchenko
-- Best regards, Oleh Kravchenko
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
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
https://cmake.org/mailman/listinfo/cmake-developers
--
Best Regards,
Sergei Nikulov
--
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-de
Oleh Kravchenko
2018-11-20 15:51:25 UTC
Permalink
Thank you Sergei,
but this is not what I asked..

I would like to set this variable during configuration step and get the
same binary,
that's means CMake should pass this variable to build tool (GNU Make,
Ninja, ...).

From my point of view CMake should have such functionality.
I can create a patch, but will be acceptable for merging?
Post by Sergei Nikulov
Post by Oleh Kravchenko
Hello CMake Developers,
My use case is to use UNIX timestamp from git history to setup
SOURCE_DATE_EPOCH and get the same binary.
I would like to set SOURCE_DATE_EPOCH environment variable from CMake
during configuration step.
How I can do it?
As per manual https://cmake.org/cmake/help/latest/command/set.html
set(ENV{SOURCE_DATE_EPOCH} <value>...)
should work during configuration step.
Should not work during build step when you invoke make or ninja.
Post by Oleh Kravchenko
-- Best regards, Oleh Kravchenko
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
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
https://cmake.org/mailman/listinfo/cmake-developers
--
Best regards,
Oleh Kravchenko
--
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/mailm
Brad King
2018-11-20 19:44:09 UTC
Permalink
CMake should pass this variable to build tool (GNU Make, Ninja, ...).
CMake doesn't invoke the build tool to build the project.
The workflow is "run cmake, then run make".

With the Makefile and Ninja generators it is up to the user to
provide the environment for the toolchain to operate as desired.

-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-developers
Oleh Kravchenko
2018-11-20 20:26:40 UTC
Permalink
Hello Brad,

CFLAGS, CXXFLAGS and LDFLAGS is a part of toolchain,
but suddenly CMake handle it and pass to the build tools..

Double standards?
Post by Brad King
CMake should pass this variable to build tool (GNU Make, Ninja, ...).
CMake doesn't invoke the build tool to build the project.
The workflow is "run cmake, then run make".
With the Makefile and Ninja generators it is up to the user to
provide the environment for the toolchain to operate as desired.
-Brad
--
Best regards,
Oleh Kravchenko
--
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
Brad King
2018-11-20 20:59:57 UTC
Permalink
Post by Oleh Kravchenko
CFLAGS, CXXFLAGS and LDFLAGS is a part of toolchain,
but suddenly CMake handle it and pass to the build tools..
No, those are interpreted by the buildsystem and converted
into flags passed to the compiler. Running

env CFLAGS=-DFOO cc foo.c

does not use those flags to compile `foo.c`.

`SOURCE_DATE_EPOCH` is directly interpreted by the compiler.

-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-developers
Oleh Kravchenko
2018-11-20 21:13:56 UTC
Permalink
So what you will advice?

I don't like idea to cover "cmake && make" with special bash script,
just to export SOURCE_DATE_EPOCH.
Post by Brad King
Post by Oleh Kravchenko
CFLAGS, CXXFLAGS and LDFLAGS is a part of toolchain,
but suddenly CMake handle it and pass to the build tools..
No, those are interpreted by the buildsystem and converted
into flags passed to the compiler. Running
env CFLAGS=-DFOO cc foo.c
does not use those flags to compile `foo.c`.
`SOURCE_DATE_EPOCH` is directly interpreted by the compiler.
-Brad
--
Best regards,
Oleh Kravchenko
--
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
Brad King
2018-11-20 21:29:41 UTC
Permalink
Post by Oleh Kravchenko
I don't like idea to cover "cmake && make" with special bash script,
just to export SOURCE_DATE_EPOCH.
SOURCE_DATE_EPOCH was created for use by packagers where tools
already wrap the build. By making it an environment variable
packagers could jump through any number of build system layers
with no patching.

Build systems configure compilers with command-line flags, not
environment variables. If you want to do this from within the
build system then GCC could be taught a new option for that.

You could try hacking it with `CMAKE_<LANG>_COMPILER_LAUNCHER`:

https://cmake.org/cmake/help/v3.13/variable/CMAKE_LANG_COMPILER_LAUNCHER.html

e.g. -DCMAKE_C_COMPILER_LAUNCHER='env;SOURCE_DATE_EPOCH=1' or

```cmake
set(CMAKE_C_COMPILER_LAUNCHER env SOURCE_DATE_EPOCH=1)
```

-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-developers
Oleh Kravchenko
2018-11-20 21:40:24 UTC
Permalink
Post by Brad King
SOURCE_DATE_EPOCH was created for use by packagers where tools
already wrap the build. By making it an environment variable
packagers could jump through any number of build system layers
with no patching.
That's makes me confused, because CMake has CPack.
And with CPack process looks like:
- `cmake && make package`
So there are no any packagers tools, all work done with CMake.
Post by Brad King
Build systems configure compilers with command-line flags, not
environment variables. If you want to do this from within the
build system then GCC could be taught a new option for that.
https://cmake.org/cmake/help/v3.13/variable/CMAKE_LANG_COMPILER_LAUNCHER.html
e.g. -DCMAKE_C_COMPILER_LAUNCHER='env;SOURCE_DATE_EPOCH=1' or
```cmake
set(CMAKE_C_COMPILER_LAUNCHER env SOURCE_DATE_EPOCH=1)
```
Thank you, I will try that.
--
Best regards,
Oleh Kravchenko
--
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
Eric Noulard
2018-11-21 08:32:47 UTC
Permalink
Post by Oleh Kravchenko
Post by Brad King
SOURCE_DATE_EPOCH was created for use by packagers where tools
already wrap the build. By making it an environment variable
packagers could jump through any number of build system layers
with no patching.
That's makes me confused, because CMake has CPack.
- `cmake && make package`
So there are no any packagers tools, all work done with CMake.
The package tool here is CPack.
You consider CMake and CPack as monolithic software they were not designed
this way (and I personally find it nice to be so).

CMake and CPack (or CTest) may work together but they may well be used
independently.
Moreover they do not run at the same time, have a look at the figure here:
Loading Image...

And you may see that setting environment var at configure time is
relatively far away from packaging time.

All that saif you are right CPack may honor SOURCE_DATE_EPOCH, and CMake
"may" forward the usage
of SOURCE_DATE_EPOCH from configuration time down to CPack time.

At least one CPack generator (the DEB one) recently honor SOURCE_DATE_EPOCH
https://gitlab.kitware.com/cmake/cmake/commit/548ac51d8ea319c65abefa0a771636893c45014c


If you use a
https://cmake.org/cmake/help/v3.12/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE
for your project
you may easily set the SOURCE_DATE_EPOCH env var at CPack time, i.e. when
CPack runs.
Post by Oleh Kravchenko
Post by Brad King
Build systems configure compilers with command-line flags, not
environment variables. If you want to do this from within the
build system then GCC could be taught a new option for that.
Apparently gcc team decided to use env var for that:
https://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.html
see associated discussion (I did not read it all):
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02210.html

llvm/clang discussion on this does not seem to be closed:
https://reviews.llvm.org/D23934
Post by Oleh Kravchenko
https://cmake.org/cmake/help/v3.13/variable/CMAKE_LANG_COMPILER_LAUNCHER.html
Post by Brad King
e.g. -DCMAKE_C_COMPILER_LAUNCHER='env;SOURCE_DATE_EPOCH=1' or
```cmake
set(CMAKE_C_COMPILER_LAUNCHER env SOURCE_DATE_EPOCH=1)
```
Thank you, I will try that.
AFAIU this should already work with gcc.

I discovered https://reproducible-builds.org/, while reading your question.
The goal is nice, and I think CMake/CPack should support that for
compiler/[package] build tools that support it.

I won't have time to work on patches for that but I'll certainly take time
to read/test one if someone is working on it.
--
Eric
Loading...