Similar to ECLIPSE_EXTRA_NATURES which can be used to add a third party
nature to the .project, this property offers the possibility to inject
third party contents into the .cproject.
An example of where this is useful is MCUXpresso. This is an IDE based
on Eclipse. Compiling through CMake generated Eclipse projects works
fine by using a custom toolchain. However, in order to be able to debug
using such a project, an extra storageModule specific to the target
board is needed in the cproject.
I have been hitting the Windows command-line limit when cross-compiling
static library (POCO) and having more than 8000 characters in the call
to "ar". Calculating exact limits here are tricky, since this particular
limit will only take into account object file strings, which is correct
for response files, but not for the archive rules (link.txt files),
since they also contain the call to "ar" and its arguments.
Also, there can be other additional arguments if "ar" tool is wrapped
into something else, so it is a good idea to leave more space than
trying to exactly fit the limit.
Since response files use half of the limit as a heuristic, we reproduce
it here for consistency.
Previously the command did not allow naming targets on the LHS that
were not created in the calling directory. Lift this restriction to
enable more flexible use by projects.
Fixes: #17943
Our custom command generation logic assumes that all command lines have
at least `argv0`. In `add_custom_{command,target}` we already check
that at least a `COMMAND` was given, but using `COMMAND_EXPAND_LISTS` in
combination with a generator expression that expands to an empty string
may produce an empty command line. In this case simply add an empty
string as a command to maintain our internal invariant.
Fixes: #17993
Create a CPack generator that uses `nuget.exe` to create packages:
https://docs.microsoft.com/en-us/nuget/what-is-nuget
NuGet packages could be easily produced from a `*.nuspec` file (running
`nuget pack` in the directory w/ the spec file). The spec filename does
not affect the result `*.nupkg` name -- only `id` and `version` elements
of the spec are used (by NuGet).
Some implementation details:
* Minimize C++ code -- use CMake script do to the job. It just let the
base class (`cmCPackGenerator`) to preinstall everything to a temp
directory, render the spec file and run `nuget pack` in it, harvesting
`*.nupkg` files...;
* Ignore package name (and use default paths) prepared by the base class
(only `CPACK_TEMPORARY_DIRECTORY` is important) -- final package
filename is a responsibility of NuGet, so after generation just scan the
temp directory for the result `*.nupkg` file(s) and update
`packageFileNames` data-member of the generator;
* The generator supports _all-in-one_ (default), _one-group-per-package_
and _one-component-per-package_ modes.
According to https://docs.nvidia.com/cuda/nvrtc/index.html there are
some cases where a CUDA binary "...must be linked against the CUDA
device runtime (cudadevrt) library". When `nvcc` drives linking it
automatically links to runtime libraries as follows:
* -cudart=none: None
* -cudart=shared: -lcudadevrt -lcudart
* -cudart=static: -lcudadevrt -lcudart_static
The `cudadevrt` library is the cuda device runtime library. It is
always static so passing it to the linker when not necessary does
not hurt anything.
With Ninja and Makefile generators, we detect `cudadevrt` and either
`cudart` or `cudart_static` libraries implied by `nvcc` and then add
them to link lines driven by a host compiler. However, this does not
work with the VS generator because the CUDA Toolkit Visual Studio
integration does not use `nvcc` to link binaries and instead uses
`link.exe` directly.
Visual Studio project files (`.vcxproj`) for CUDA are expected to
explicitly list the needed runtime libraries. Our VS generator already
adds `cudart.lib` or `cudart_static.lib` based on the `-cudart=` flag.
Update it to also add `cudadevrt.lib` as nvcc does.
Fixes: #17988
