Build helper functions for legate projects, legate-hello example

[jjwilke]

With this set of helper functions, the CMakeLists.txt for a downstream project like cunumeric would now look like:

src/CMakeLists.txt:

add_library(hello
  hello_world.cc
  hello_world.h)
target_link_libraries(hello PRIVATE legate::core)
....

CMakeLists.txt:

cmake_minimum_required(VERSION 3.24.0 FATAL_ERROR)

project(hello VERSION 1.0 LANGUAGES C CXX)

find_package(legate_core REQUIRED)
legate_add_cpp_subdirectory(src hello EXPORT hello-export)
legate_add_cffi(${CMAKE_SOURCE_DIR}/src/hello_world.h)
legate_default_python_install(hello EXPORT hello-export)

[jjwilke]

Hello world example being developed here:

https://github.com/jjwilke/legate-hello-world

[trxcllnt]

@robertmaynard I'd also appreciate your thoughts on this PR.

[trxcllnt]

@jjwilke can we also add the LANGUAGES ${ENABLED_LANGUAGES} option to the rapids_export() calls in legate_core_{cpp,python}.cmake?

[robertmaynard]

I would use something like ${CMAKE_SOURCE_DIR}/legate_${${target}}_build instead of ${CMAKE_SOURCE_DIR}/build.

The build directory could already be used by a target named that, or a user might want to call legate_add_cpp_subdirectory multiple time and this wouldn't work

[trxcllnt]

@robertmaynard that's actually the point of this line, since this is only executed when running via scikit-build

1. If the user configures C++ independently, they can do it into ./build
2. If the user lets scikit-build configure the C++ lib as a side-effect of building the Python lib, the C++ libs still end up in ./build (where normally they'd be under something like _skbuild/<arch>/cmake-build)

This stability helps with the runtime library loading we do when dev'ing locally w/ pip install --editable .

[jjwilke]

I split the difference since it's a valid point that this only supports a single source directory. I put everything in:
${CMAKE_SOURCE_DIR}/build/legate_${target} - which I think is okay? @robertmaynard

This still makes the libraries easy to find.

[trxcllnt]

@jjwilke that assumes users configuring the C++ library themselves know to build in that dir? my guess is they won't know to do this:

cmake -S . -B build/legate_hello_world && cmake --build build/legate_hello_world

CMAKE_ARGS="-Dhello_world_ROOT=$PWD/build/legate_hello_world" \
pip install --editable .

[trxcllnt]

Maybe we should make it configurable, or do something like build/${cmake_build_type}? So that way at least it's build/Debug and build/Release?

[robertmaynard]

When using add_subdirectory(${dir} ${CMAKE_SOURCE_DIR}/build) you are stating that CMake should parse the CMakeLists.txt in ${dir} and place any build information in ${CMAKE_SOURCE_DIR}/build. This has the following issues:

1. You are placing build artifacts in the soure tree. The path should start with CMAKE_BUILD_DIR.
   Since legate_add_cpp_subdirectory is executed by the users project we have no idea what source tree layout they have and shouldn't try to write to CMAKE_SOURCE_DIR.
2. The second argument must be unique across a CMake project. So ${CMAKE_BUILD_DIR}/legate_${target} would be sufficient. So the following logic doesn't work currently:

legate_add_cpp_subdirectory(legate_plugin1 hello EXPORT hello-export)
legate_add_cpp_subdirectory(legate_plugin2 world EXPORT world-export)

[jjwilke]

Thanks all for the suggestions. Silly mistakes on my part. I believe the latest version correctly puts things into CMAKE_BINARY_DIR into unique folders.

PTAL. @robertmaynard @trxcllnt

[robertmaynard]

Updated version looks good to me

[jjwilke]

@trxcllnt @manopapad Sorry everybody... PTAL. With the recent breakage due to PR #581 I decided the hello-world examples should really be maintained in the legate-core repo with build testing in CI to make sure things don't get broken.

The current setup abuses find_package to "find" Legate in its own build tree when legate_core_EXAMPLE_BUILD_TESTS is ON.