Fix Interface Library Installation and Begin to Separate Target Concerns

[zachcran]

Description

Interface libraries (of type INTERFACE) do not generate an associated compiled library. However, CMaize will still generate the installed <package>Config.cmake file as if a library was created. Additionally, INTERFACE_LINK_LIBRARIES were not being properly set on INTERFACE targets, which are required for a dependent target to properly compile.

To resolve these issues, I first needed a method to determine what type of library (see add_library docs) was being installed. The library target type appears to be language agnostic as types like SHARED, STATIC, and INTERFACE are applicable to multiple languages. Therefore, I began by partially decoupling the CMaize-specific library target functionality and language-specific library target functionality into separate target classes. In this way, general, CMake-level interface library-related concerns can be made independent of programming language of the target. This allows us to easily inject a "library type" attribute into all library targets by adding it to the CMaizeInterfaceLibrary class. Additionally, it allows future language targets to be more easily added with default behaviors.

The following image summarizes the change in the class hierarchy described above, with the current state described as well as the intended, fully decoupled class hierarchy that is beyond the scope of this PR for future reference:

The CMakePackageManager class was then updated to fix the aforementioned issues for installed config files, which was fairly trivial after the work above.

During the development and debugging process, I also attempted to improve CMaize messages output during the build process to be more useful and informative. Messages were primarily added at the VERBOSE or DEBUG levels so they did not run counter to the desire to reduce some output in #151.

TODOs

• Complete the function and class documentation.
• Fix failing tests.
• What documentation website updates does this require?

[zachcran]

@ryanmrichard r2g. The tests also all pass on my system with CMake 4.1.1. It is the topic of another quick PR, but I think we should update the unit testing to include CMake 4.x.

[zachcran]

@ryanmrichard Do you agree with the patch version increment I tagged? My reasoning is that it doesn't change or add any functionality to the user API and just fixes our support for interface libraries. However, I think it does technically add new classes to the public API (if cmaize/targets is considered part of the public API), so I can see an argument for a minor version update as well.

[ryanmrichard]

@zachcran I'm fine with either patch or minor. Even though there's a lot of code here, I think it's more along the lines of a bug fix vs. a new feature. Point being, I think patch is probably the more applicable.

[github-actions]

🚀 [bumpr] Bumped!
New version:v1.1.9
Changes:v1.1.8...v1.1.9