Ninja,Makefile: Restore Fortran module scanning in static library cycle

Since

* commit eed295fd8a (cmGlobalNinjaGenerator: require that dependency info
                     files work, 2023-02-01, v3.26.0-rc1~1^2~1), and
* commit 13810dee17 (cmDependsFortran: require that dependency info files
                     work, 2023-02-01, v3.26.0-rc1~1^2),

the Ninja and Makefile generators' module dependency scanning requires
that scanning results from from linked targets is available before
scanning the current target.  In the case of a static library cycle,
we cannot expect this information from other static libraries in the
cycle.  Previously we supported cyclic cases at the cost of silently
ignoring missing information.

We already compute a global order of targets that respects all
`add_dependencies`, but may break `target_link_libraries` dependencies
that occur in a static library cycle.  Use this order to filter the
linked targets so we only expect scanning results to be available from
those targets that build before the current target.

This approach is sufficient to support module dependency scanning in
static library cycles as long as module dependencies do not cross
between two libraries in the same cycle.

Fixes: #24631

Source/cmCommonTargetGenerator.cxx

@@ -164,6 +164,7 @@ std::vector<std::string> cmCommonTargetGenerator::GetLinkedTargetDirectories(
 {
   std::vector<std::string> dirs;
   std::set<cmGeneratorTarget const*> emitted;
+  cmGlobalCommonGenerator* const gg = this->GlobalCommonGenerator;
   if (cmComputeLinkInformation* cli =
         this->GeneratorTarget->GetLinkInformation(config)) {
     cmComputeLinkInformation::ItemVector const& items = cli->GetItems();
@@ -171,6 +172,8 @@ std::vector<std::string> cmCommonTargetGenerator::GetLinkedTargetDirectories(
       cmGeneratorTarget const* linkee = item.Target;
       if (linkee &&
           !linkee->IsImported()
+          // Skip targets that build after this one in a static lib cycle.
+          && gg->TargetOrderIndexLess(linkee, this->GeneratorTarget)
           // We can ignore the INTERFACE_LIBRARY items because
           // Target->GetLinkInformation already processed their
           // link interface and they don't have any output themselves.

Tests/FortranModules/Executable/CMakeLists.txt

@@ -6,3 +6,4 @@ add_executable(subdir_exe2 main.f90)
 target_link_libraries(subdir_exe2 subdir_mods subdir_mods2)
 add_dependencies(subdir_exe2 ExternalTarget)
 target_link_libraries(subdir_exe2 myext)
+target_link_libraries(subdir_exe2 cycleA)

Tests/FortranModules/Executable/main.f90

@@ -3,5 +3,9 @@ PROGRAM MAINF90
   USE libraryModuleB
   USE subdirModuleA
   USE externalMod
+  USE libraryCycleA
+  USE libraryCycleB
   CALL printExtModGreeting
+  CALL libraryCycleA2
+  CALL libraryCycleB2
 END PROGRAM MAINF90

Tests/FortranModules/Library/CMakeLists.txt

@@ -3,9 +3,14 @@ add_library(subdir_mods a.f90 b.f90)
 add_executable(subdir_exe main.f90)
 target_link_libraries(subdir_exe subdir_mods)
 
+add_library(cycleA STATIC cycleA1.f90 cycleA2.f90)
+add_library(cycleB STATIC cycleB1.f90 cycleB2.f90)
+target_link_libraries(cycleA PRIVATE cycleB)
+target_link_libraries(cycleB PRIVATE cycleA)
+
 # Test module output directory if available.
 if(CMAKE_Fortran_MODDIR_FLAG)
-  set_target_properties(subdir_mods PROPERTIES
+  set_target_properties(subdir_mods cycleA cycleB PROPERTIES
     Fortran_MODULE_DIRECTORY modules
     )
 endif()

Tests/FortranModules/Library/cycleA1.f90

@@ -0,0 +1,3 @@
+subroutine cycleA1
+use libraryCycleA
+end subroutine

Tests/FortranModules/Library/cycleA2.f90

@@ -0,0 +1,5 @@
+module libraryCycleA
+contains
+  subroutine libraryCycleA2
+  end subroutine
+end module

Tests/FortranModules/Library/cycleB1.f90

@@ -0,0 +1,3 @@
+subroutine cycleB1
+use libraryCycleB
+end subroutine

Tests/FortranModules/Library/cycleB2.f90

@@ -0,0 +1,5 @@
+module libraryCycleB
+contains
+  subroutine libraryCycleB2
+  end subroutine
+end module