Each component can now be built and installed separately

What is the new feature

The implementation allowed for separate building and installation of all the components, enhancing efficiency and modularity

How is it implemented

Created separate target files for individual components; also added new CMake options to enable the building of individual components.

Fixed an issue with the 'libiconmath' package not being found in another program when it is installed in a custom prefix directory.

Additionally, two more major changes were made:

• In this commit, I used different directories to install the mod files of different components of iconmath. The motivation behind the change was that I found a code that uses a module from iconmath::horizontal compiles fine even though that component is not linked using target_link_libraries.
• In this commit, I changed the way target files of individual components are included when a new project tries to find iconmath. Before, the inclusions of components interpolation and horizontal were done depending on their presence in the proper place. But, because of this, it was possible to use target_link_libraries(new-project PRIVATE iconmath::horizontal) successfully even when iconmath was found using find_package(iconmath CONFIG REQUIRED COMPONENTS interpolation). This should always give an error, which was not the case before these changes were made.

Mandatory steps before review

• Gitlab CI passes (Hint: use make format for linting)
• New feature is covered by additional unit tests
• Mark the merge request as ready by removing Draft:

Mandatory steps before merge

• Reviewed by a maintainer
• Incorporate review suggestions
• Prior to merging, please remove any boilerplate from the MR description, retaining only the Please describe your feature in a couple of words and describe important implementation details of the feature section to maintain

You are not supposed to merge this request by yourself, the maintainers of libiconmath take care of this action!

cmake/config.cmake.in

@@ -11,7 +11,21 @@
 
 @PACKAGE_INIT@
 
-include("${CMAKE_CURRENT_LIST_DIR}/@PROJECT_NAME@-targets.cmake")
+# Include the target for iconmath::support
+include("${CMAKE_CURRENT_LIST_DIR}/@PROJECT_NAME@-support-targets.cmake")
+message(STATUS "Including iconmath::support")
+
+# Include the targets for interpolation if the interpolation or horizontal component is requested
+if(NOT iconmath_FIND_COMPONENTS OR "interpolation" IN_LIST iconmath_FIND_COMPONENTS OR "horizontal" IN_LIST iconmath_FIND_COMPONENTS)
+    message(STATUS "Including iconmath::interpolation")
+    include("${CMAKE_CURRENT_LIST_DIR}/@PROJECT_NAME@-interpolation-targets.cmake")
+endif()
+
+# Include the target for horizontal if the horizontal component is requested
+if(NOT iconmath_FIND_COMPONENTS OR "horizontal" IN_LIST iconmath_FIND_COMPONENTS)
+    message(STATUS "Including iconmath::horizontal")
+    include("${CMAKE_CURRENT_LIST_DIR}/@PROJECT_NAME@-horizontal-targets.cmake")
+endif()
 
 include(FindPackageHandleStandardArgs)
 find_package_handle_standard_args(@PROJECT_NAME@ REQUIRED_VARS @PROJECT_NAME@_DIR)

[Sergey Kosukhin]

Why do we need separate targets files for the components?

[Pradipta Samanta]

I thought that each component must have its own target file. That's why I started to make these changes. It makes sense to me, as it helps all the components be managed independently. Although it is a small project now, it has the possibility to grow, and then having smaller target files for each component will also scale well. I am not sure what the benefits of having just one target file for all components are other than that it will be simpler.

[Sergey Kosukhin]

Yes, it will be simpler. What are the benefits of having multiple target files?

[Pradipta Samanta]

Each component has its own directory, 'cmake' configuration, and binary file. I do not see how having its target file breaks the deal. For me, it is still part of the modular structure upon which the library is built, and enough reason to have it this way.

But still, I would like to discuss a problem which could be solved by having three targets. I already mentioned a CMakeLists.txt file in one of my earlier comments in this MR. It is:

cmake_minimum_required(VERSION 3.18)
project(TestIconMathProject Fortran)

# Find the iconmath package, requiring the interpolation component
find_package(iconmath CONFIG REQUIRED COMPONENTS interpolation)

# Create an executable from your test source file
add_executable(test_interpolation src/main.f90)

# Link the iconmath::interpolation target to your executable
target_link_libraries(test_interpolation PRIVATE iconmath::support)
target_link_libraries(test_interpolation PRIVATE iconmath::interpolation)
target_link_libraries(test_interpolation PRIVATE iconmath::horizontal)

I think you will agree that this should produce an error during the configuration, mainly because it only asks for the component interpolation and its dependencies at the find_package step. Still, later, it is trying to link the horizontal component (one should not be just lucky about it). But, with one target file and assuming iconmath with all of its components being already installed, this does configure without any error. Actually, it was still possible to configure it without failing, even with three target files, till I corrected it in (this)[!5 (e4dfd148)] commit. Do you see that as a benefit? I can not think of an alternative but elegant solution for this, which could be my lack of understanding of CMake.

[Sergey Kosukhin]

For me, it is still part of the modular structure upon which the library is built, and enough reason to have it this way.

The "modular structure" is not an absolute good but a tradeoff with the usual benefit of improved maintainability. Changes in this particular file do not look like they make the code more maintainable. Simply because a single target file does not need any extra code to maintain.

I think you will agree that this should produce an error during the configuration, mainly because it only asks for the component interpolation and its dependencies at the find_package step. Still, later, it is trying to link the horizontal component (one should not be just lucky about it).

I am sorry but you are starting with a wrong assumption. The users are free to do whatever they want in their scripts (believe it or not, sometimes the reason for that is that they know better). We are only supposed to deliver the interface: the user requests a component - we define the respective target (or fail if the target is not available but REQUIRED). We are free to define more targets, functions and variables but those are implementation details. If the users rely on horizontal being available when only interpolation is requested, it's their problem. This might break at some point and will need a fix, which will be to explicitly request horizontal as well.