Break cyclic dependencies of CMake targets

[ingomueller-net]

There seem to be several cycles in the dependency graph of CMake targets. This isn't a problem for compiling static libraries, but if I build with cmake -DBUILD_SHARED_LIBS=ON ..., I get the following error (uninteresting parts omitted):

CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
  "substrait_io" of type STATIC_LIBRARY
    depends on "substrait_textplan_converter" (weak)
    depends on "symbol_table" (weak)
    depends on "substrait_textplan_loader" (weak)
    depends on "substrait_textplan_converter" (strong)
    depends on "substrait_textplan_loader" (strong)
  "symbol_table" of type SHARED_LIBRARY
    depends on "substrait_textplan_converter" (weak)
    depends on "substrait_io" (weak)
    depends on "substrait_textplan_loader" (weak)
  "substrait_textplan_converter" of type SHARED_LIBRARY
    depends on "substrait_io" (weak)
    depends on "substrait_textplan_loader" (weak)
    depends on "symbol_table" (weak)
  "substrait_textplan_loader" of type SHARED_LIBRARY
    depends on "symbol_table" (weak)
    depends on "substrait_textplan_converter" (weak)
    depends on "substrait_io" (weak)
At least one of these targets is not a STATIC_LIBRARY.  Cyclic dependencies are allowed only among static libraries.

I understand that there are reasons not to build shared libraries, but I argue that there are situations where it is useful. (I am working on a project with many top-level binaries that share 99% of the code and compilation and disk usage is a lot better with shared libs, so I hugely prefer that for developing and CI.)

I am currently trying to consume substrait-cpp as a dependency using add_subdirectory. Since I build my top-level project with BUILD_SHARED_LIBS, substrait-cpp is built with the same configuration. For any scenario where that flag is desired or required for the top-level project, support that flag would be great.

Finally, I believe that cyclic dependencies are often an indication for sloppy design or code organization and therefor a good idea to clean up. However, I haven't looked into the cycles yet, so I don't know yet whether there are good reasons to have them or things have just grown this way...

[ingomueller-net]

OK, one cycle can be broken very easily:

diff --git a/src/substrait/textplan/converter/CMakeLists.txt b/src/substrait/textplan/converter/CMakeLists.txt
index 5ee2753..f328f81 100644
--- a/src/substrait/textplan/converter/CMakeLists.txt
+++ b/src/substrait/textplan/converter/CMakeLists.txt
@@ -24,7 +24,6 @@ target_link_libraries(
   substrait_textplan_converter
   substrait_common
   substrait_expression
-  substrait_io
   substrait_proto
   symbol_table
   error_listener

[ingomueller-net]

The other cycle is due to the two functions typeToText and relationToText in SymbolTablePrinter.cpp. Without those, symbol_table does not need to depend on substrait_textplan_converter anymore. The solution is probably to move these functions into that target.

I'm calling it a day now but I'll probably try that out and create a PR tomorrow if nobody beats me to it.

[ingomueller-net]

Resolved by #100.