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
In commit v3.11.0-rc1~433^2~1 (Add support for IMPORTED GLOBAL targets
to be aliased, 2017-09-14) we accidentally dropped the error on calling
`add_library` to alias an imported target that is not globally visible.
The `add_executable` command's equivalent check was properly updated.
Restore the check in `add_library` with the same update. Also fix the
test case accordingly.
Fixes: #17982
This change reworks ctest_start() so that simply calling
ctest_start(APPEND) will read all the information from the TAG file.
On top of that, it relaxes the argument parsing for ctest_start() to
allow greater flexibility in the argument ordering, and the documentation
for ctest_start() has been cleaned up.
When generating a `ProjectReference` with `ReferenceOutputAssembly` set
to `false`, also set `CopyToOutputDirectory` to `Never`. Otherwise
MSBuild might report a diagnostic like
Project '<name>' is not up to date.
CopyLocal reference '...\ZERO_CHECK' is missing from output location.
and rebuild the referencing project unnecessarily.
Brad King