CMake: Remove Glue libraries?

[dnakamura]

Problem:

Currently the way we handle the glue (having the consumer define an interface library and passing us its name), has some issues

• No way to declare PUBLIC/PRIVATE on include directories, or linked libraries. (We assume include dirs are public and linked libraries are private).

• We have to do some ugliness on the omr side to prevent the glue source propagating as interface sources, but still publicly propagate the include directories.

• Can only inject glue into a fixed set of libraries (although im not sure why you would want to inject glue elsewhere)

Proposal:

Eliminate OMR_X_GLUE_TARGET variables, have consumers manually inject glue code into libraries.

Example:

(only the gc glue is shown for brevity):

Current method :

...
add_library(my_gc_glue INTERFACE)
target_add_sources(my_gc_glue 
    INTERFACE
        ${CMAKE_CURRENT_SOURCE_DIR}/foo_1.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/foo_2.cpp
        ...
)
target_include_directories(my_gc_glue
    INTERFACE
        ${CMAKE_CURRENT_SOURCE_DIR}/glue_public_includes
        ${CMAKE_CURRENT_SOURCE_DIR}/glue_private_includes
)

set(OMR_GC_GLUE_TARGET my_gc_glue)
add_subdirectory(omr)
...

New method:

...
add_subdirectory(omr)

target_sources(omrgc
    PRIVATE
        foo_1.cpp
        foo_2.cpp
)

target_include_directories(omrgc
    PRIVATE
        glue_private_includes
    PUBLIC
        glue_public_includes
)
...

Pros:

• Greatly increased flexibility for specifying PUBLIC/PRIVATE/INTERFACE on elements
• Simpler syntax.
• Simpler overall architecture, more inline with cmake philosophy

Cons:

• Since there is no longer cache variables to define the glue targets, its less clear that you need to be injecting code to make things work properly
• Becomes sensitive to ordering; requires glue be defined after add_subdirectory(omr).

[dnakamura]

Thoughts? @rwy0717 @mgaudet @charliegracie

[mgaudet]

I mean, the 'new method' example seems pretty compelling to me. The ordering dependence doesn't seem particularly convincing argument against, so... LGTM?

[rwy7]

This looks good to me, it makes OMR's build system less complicated/"frameworky", by pushing more code out to the consumers.

[charliegracie]

@dnakamura is this something we still want to do or something that has been completed?

[dnakamura]

Yes I would still like to do this. However we probably need the openJ9 cmake stuff to go live so we can see if it actually makes sense / works the way I think it should