Convert all usages of target_link_libraries to use PUBLIC/PRIVATE specifiers

[jkoritzinsky]

CMake requires all usages to be consistent, and we're going to add these specifiers as part of the sanitizer work, so make them consistently used across the repo (excluding external sources) here.

Split out of #74623

[ghost]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

CMake requires all usages to be consistent, and we're going to add these specifiers as part of the sanitizer work, so make them consistently used across the repo (excluding external sources) here.

Split out of #74623

Author:	jkoritzinsky
Assignees:	-
Labels:	area-Infrastructure
Milestone:	-

[lambdageek]

Mono LGTM, except I think component_base should be PRIVATE

[mdh1418]

Do we also need one for

runtime/src/tests/Interop/UnmanagedCallConv/CMakeLists.txt

Line 7 in 8cb3cfc

target_link_libraries(${PROJECT_NAME} ${LINK_LIBRARIES_ADDITIONAL})

?

When new CMakeLists.txt files are added, what would be the best way to notify the contributor that a target_link_libraries is missing the PUBLIC|PRIVATE|INTERFACE scope specifiers?

[jkoritzinsky]

Do we also need one for

runtime/src/tests/Interop/UnmanagedCallConv/CMakeLists.txt

Line 7 in 8cb3cfc

target_link_libraries(${PROJECT_NAME} ${LINK_LIBRARIES_ADDITIONAL})

?

Yes, I missed that one.

When new CMakeLists.txt files are added, what would be the best way to notify the contributor that a target_link_libraries is missing the PUBLIC|PRIVATE|INTERFACE scope specifiers?

We don't have automated tooling for this today, but when the work to enable AddressSanitizer gets in, the requirement will likely be enforced by CMake (as we'll add a linker flag with a specifier to many of the projects, which will cause CMake to error when someone adds a linker flag/library link without the scope specifier)

[lambdageek]

@jkoritzinsky FYI I'm going to merge #82182 shortly which might create some conflicts with this PR. I'm adding some object libraries to mono - and they will already be using PRIVATE/PUBLIC

[mdh1418]

There are a few more in the AndroidAppBuilder and AppleAppBuilder Tasks which have a slight modification of CMakeLists.txt name

runtime/src/tasks/AndroidAppBuilder/Templates/CMakeLists-android.txt

Line 24 in f9ebd42

target_link_libraries(

runtime/src/tasks/AppleAppBuilder/Templates/CMakeLists.txt.template

Lines 69 to 85 in f9ebd42

	target_link_libraries(
	%ProjectName%
	"-framework Foundation"
	"-framework Security"
	"-framework UIKit"
	%FrameworksToLink%
	"-lz"
	"-lc++"
	"-liconv"
	%NativeLibrariesToLink%
	)
	if(%UseNativeAOTRuntime%)
	target_link_libraries(
	%ProjectName%
	"-Wl,-u,_NativeAOT_StaticInitialization"
	)

Besides those, and double checking that we can ignore src/native/external/zlib, then if the CI failures are unrelated (Could something like The type or namespace name 'ProducedBy' could not be found be a result of a PRIVATE scope instead of PUBLIC?), then I think this is in good shape.

[jkoritzinsky]

The CI failures are unrelated. There was a regression that made it into main that there are already PRs out to fix. I'll go update the AppBuilder templates.

[lambdageek]

Do the templates actually matter? They're meant to be like examples of "user code". They're not consuming any of the cmake fragments that we have in the runtime repo.

Update well ok, Jeremy updated the templates already. That's ok. it doesn't hurt to clean them up a bit

[jkoritzinsky]

Do the templates actually matter? They're meant to be like examples of "user code". They're not consuming any of the cmake fragments that we have in the runtime repo.

Update well ok, Jeremy updated the templates already. That's ok. it doesn't hurt to clean them up a bit

Yeah we don't really need to update them, but I figured it was worthwhile for consistency since it was brought up.

[mdh1418]

Do the templates actually matter? They're meant to be like examples of "user code". They're not consuming any of the cmake fragments that we have in the runtime repo.
Update well ok, Jeremy updated the templates already. That's ok. it doesn't hurt to clean them up a bit

Yeah we don't really need to update them, but I figured it was worthwhile for consistency since it was brought up.

The templates are currently used to build custom CMakeLists.txt that will be used by the AppleAppBuilder and AndroidAppBuilder for library tests, runtime tests, and mono samples, so in that sense its more than just examples. I think the consistency would be good especially if the AddressSanitizer ends up being extended for Mono (not sure if that possible or planned). Moreover, if there are more tasks brought up in the future that look to those (AppleAppBuilder and AndroidAppBuilder) for inspiration (like the LibraryBuilder PR), then theres a better chance a PUBLIC/PRIVATE scope will be added to target_link_libraries the task as well.

[mdh1418]

Looks good to me, thanks!

[jkoritzinsky]

All failures are known issues.