Add header-only components via INTERFACE, add_component_set, automatic <name>::<name> aliases, docs revamp

[an-dr]

No description provided.

[Copilot]

Pull request overview

This PR introduces three major enhancements to abcmake: support for header-only (INTERFACE) components, a new add_component_set function for bulk component registration, and automatic <name>::<name> target aliases for improved interoperability. The changes also include comprehensive documentation additions and version bump to 6.3.0.

Key Changes:

• Added INTERFACE library support for header-only components with proper visibility handling
• Introduced add_component_set function for registering components without building them locally
• Automatic creation of namespaced aliases (<name>::<name>) for all library components to simplify linking from parent projects

Reviewed changes

Copilot reviewed 41 out of 41 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
tests/test_project_build.py	Added four new test cases for INTERFACE components, component sets, interface linking, and alias linking
tests/test_interface/	Test case for basic header-only INTERFACE library
tests/test_interface_link/	Test case for INTERFACE library linking to regular components
tests/test_component_set/	Test case for component set registration and name-based linking
tests/test_alias_link/	Test case verifying parent project can link via <name>::<name> alias
src/abcmake/add_component.cmake	Core changes: added _abcmake_add_namespace_alias, add_component_set, INTERFACE parameter support in add_component
src/abcmake/target_link_components.cmake	Added _abcmake_get_link_visibility helper to handle INTERFACE vs PRIVATE linking correctly
src/version.cmake	Version bump from 6.2.0 to 6.3.0
src/abcmakeConfig.cmake	Pre-generated package config file (replaces template-based generation)
src/abcmakeConfigVersion.cmake	Pre-generated version config with custom compatibility logic
cmake/abcmakeConfig.cmake.in	Removed (replaced by pre-generated file)
scripts/build_package.ps1	Added PowerShell script for building installation package
docs/quick-start.md	Comprehensive quick start guide with examples
docs/installation.md	Detailed installation instructions for multiple scenarios
docs/examples.md	Extensive collection of usage examples and patterns
docs/concepts.md	In-depth explanation of abcmake concepts and best practices
docs/api.md	API reference documentation for all public functions
README.md	Major overhaul with better structure, examples, and navigation
CONTRIBUTING.md	Added comprehensive contributing guidelines
CMakeLists.txt	Simplified installation to use pre-generated config files
CHANGELOG.md	Updated with new features for unreleased and 6.3.0 versions
.gitattributes	Added linguist rules for examples and scripts directories

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The documentation states that "All component links use PUBLIC visibility by default", but the implementation in target_link_components.cmake uses PRIVATE visibility for non-interface libraries (line 10) and INTERFACE visibility for interface libraries (line 8). The documentation should be updated to accurately reflect that the visibility is PRIVATE by default for regular libraries, not PUBLIC.

Suggested change

	All component links use `PUBLIC` visibility by default:
	- Component dependencies propagate to consumers
	- Transitive dependencies handled automatically
	- Include paths propagate through link chain
	By default, component links use `PRIVATE` visibility for regular libraries and `INTERFACE` visibility for interface libraries:
	- For regular libraries, dependencies and include paths do **not** propagate to consumers unless explicitly set to `PUBLIC`
	- For interface libraries, dependencies propagate via `INTERFACE` visibility
	- Transitive dependencies are handled automatically according to the link visibility
	- Include paths propagate only if the visibility is `PUBLIC` or `INTERFACE`