This generator expression offers the capability, for the link step, to
decorate libraries with prefix/suffix flags and/or adding any specific flag for each
library.
Fixes: #22812, #18751, #20078, #22703
Move ProjectFileExtension handling logic to use ProjectType and remove
extraneous checks in .Net SDK style project generation. This change will
make introducing new project types relatively simpler.
In commit dff98aa9ca (VS: add missing label in C# project-build events,
2021-12-15) the condition for adding our own `VCEnd` label was based on
the project being managed or not. Since we support managed C++
projects, switch the condition to be based on whether the project is C#.
Issue: #21440
Store the main dependency as the first entry in the dependency list plus
a boolean member indicating its existence. Note that this slightly
changes existing behavior: the main dependency was previously the last
entry of the dependency list.
Revert commit b284a21fee (VS: Add missing label in C# project-build
events, 2021-09-03, v3.22.0-rc1~156^2). The change broke cases using
multiple successful custom commands. Revert it pending further
investigation into the interaction of the generated script code with
`Microsoft.Common.CurrentVersion.targets`, and whether this is needed
for all managed projects or just C# projects.
Also add a test covering the case that was broken.
Fixes: #22964
Issue: #21440
Most calls to `MaybeConvertToRelativePath` use one of our common work
directories (e.g. top of the build tree) as the local path. Add helpers
for each of the common cases to simplify and clarify call sites.
These were included when the Fortran flag table was first created by
commit 10c91ded4f (ENH: add support for Intel Fortran Visual studio IDE,
2008-04-30, v2.8.0~2227), but they map to fields not actually supported
by the IDE. Remove their table entries.
Instead use just `/debug:minimal` and `/debug:full` to control debug
information level in VS Intel Fortran. Let flags like `/Z7` pass
through as raw additional options because they have no corresponding IDE
property and can be used to complement the supported options.
Fixes: #21340
Do not attach a custom command to a target if it is already attached to one of
the target's dependencies. The command's output will be available by the time
the target needs it because the dependency containing the command will have
already been built.
The same change was already made by commit f59c33a763 (VS: Generate a
custom command only in the least dependent target, 2018-03-23,
v3.12.0-rc1~171^2) for VS 10+.
Move it up the hierarchy from `cmLocalVisualStudio10Generator`.
Propagate contents from a target's dependencies as part of the main
target iteration logic instead of as part of the generator-specific
target generation.
INTERFACE libraries were created with the intention of collecting usage
requirements for use by other targets via `target_link_libraries`.
Therefore they were not allowed to have SOURCES and were not included in
the generated buildsystem. In practice, this has become limiting:
* Header-only libraries do have sources, they just do not compile.
Developers should be able to edit those sources (the header files)
in their IDE.
* Header-only libraries may need to generate some of their header
files via custom commands.
Some projects work around these limitations by pairing each interface
library with an `add_custom_target` that makes the header files and
custom commands appear in the generated buildsystem and in IDEs.
Lift such limitations by allowing INTERFACE libraries to have SOURCES.
For those with sources, add a corresponding build target to the
generated buildsystem.
Fixes: #19145
