Skip to content

Support add_subdirectory and ExternalProject_Add in third-party projects, improve CI - #565

Merged
adamant-pwn merged 107 commits into
masterfrom
api-header-example
Nov 17, 2025
Merged

adamant-pwn merged 107 commits into
masterfrom
api-header-example

Conversation

@adamant-pwn

@adamant-pwn adamant-pwn commented Nov 13, 2025 •

Copy link
Copy Markdown
Member

Makes MetaGraph easy to integrate into external projects using CMake's add_subdirectory() or ExternalProject_Add.

  • Added metagraph/api/metagraph.hpp convenience header
  • Removed obsolete sdsl-lite manual installation steps (now handled by CMake)
  • Added CI workflow to test https://github.com/ratschlab/metagraph-examples on Ubuntu and MacOS
  • Split CI workflow into multiple parts for better GitHub runner utilization
  • Use ccache for faster builds

Use CMAKE_CURRENT_SOURCE_DIR instead of CMAKE_SOURCE_DIR to correctly
locate package.json when metagraph is used as a submodule via add_subdirectory()
…include propagation

- Moved metagraph-core target definition early (before includes)
- Converted all include_directories() to target_include_directories(metagraph-core PUBLIC ...)
- Used GLOB_RECURSE for cleaner file globbing
- Moved findFolly() section to after target definition for better organization
- macOS system includes now added to metagraph-core target
- All includes now properly propagate to dependent targets
…or folly-config.h generation

This fixes the issue where folly-config.h was generated in the wrong location when metagraph is used as a submodule.
…lobal add_definitions with METAGRAPH_ALPHABET_DEF variable\n- Apply target_compile_definitions(metagraph-core PUBLIC )\n- Ensures external dependents (examples) receive the macro
…d_definitions with target_compile_definitions; propagate alphabet define via METAGRAPH_PUBLIC_DEFS; remove global link_directories; fix folly config include path for submodule builds
When metagraph is used as a subdirectory, CMAKE_CXX_FLAGS changes don't
propagate. Add OpenMP_CXX_FLAGS directly to metagraph-core target with
PUBLIC visibility so consumers inherit -fopenmp and get automatic OpenMP
library linking from GCC.
GCC requires -fopenmp during linking to automatically add -lgomp.
Previously only added it to compile options, but link stage also needs it.
SDSL is now built automatically via CMake ExternalProject, so manual
installation with install.sh is no longer needed.

Changes:
- Removed 'install sdsl-lite' step from Linux CI workflow
- Removed 'install sdsl-lite' step from MacOS CI workflow
- Removed sdsl-lite installation instructions from documentation
Tests that the examples repository builds and runs correctly:
- Checks out ratschlab/metagraph-examples with submodules
- Builds the examples using CMake
- Runs basic_query example with test data

This ensures the examples stay compatible with MetaGraph changes.
- Fetches and checks out current metagraph commit in the examples submodule
- Tests examples against the PR/push being evaluated
- Removed custom path to use default checkout location
Test metagraph-examples on both Ubuntu and MacOS:
- Ubuntu 22.04 with g++-13
- MacOS latest (Apple Silicon)
- Platform-specific dependency installation
@adamant-pwn adamant-pwn changed the title Make MetaGraph usable with add_subdirectory in external projects, add CI workflow for it Support add_subdirectory and ExternalProject_Add in third-party projects, improve CI Nov 17, 2025
@adamant-pwn
adamant-pwn merged commit 00945af into master Nov 17, 2025
@adamant-pwn
adamant-pwn deleted the api-header-example branch November 17, 2025 19:41
#include <optional>
#include <vector>

#include "common/config.hpp"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need this here?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use some compile definitions, in this particular file MODE_TI, which are used by sdsl. If Metagraph is added via ExternalProject_Add, the parent project must also provide them as defines (which is done by generating them into common/config.hpp), otherwise there will be linking errors.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the parent project doesn't have to define those flags? But how can we be sure not to miss these flags in some files? Or, are we going to add this common/config.hpp into every file in the project?

@adamant-pwn adamant-pwn Nov 19, 2025 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, parent projects need to provide them when using ExternalProject_Add or make install.

When using add_subdirectory, parent project inherits them automatically, but with ExternalProject_Add or system-wide install via make install, it's tricky, and could be argued that parent project shouldn't be responsible for matching all of them when using library. For example, it wouldn't be sufficient to define CMAKE_DBG_ALPHABET like it's done in add_subdirectory, as one would also need to provide internal definitions like _DNA_GRAPH.

When choosing places to add common/config.hpp, I added it anywhere the file or its external header dependency relies on these definitions. As it's now in CI, we'll be notified if missing a definition straight up leads to compilation or linking error, or if it prevents even basic usage of Metagraph.

In any case, it will not affect directly building Metagraph from sources or using it via add_subdirectory because we still keep compile definitions in this case. If we're not satisfied it covers all use-cases for ExternalProject, we can also recommend parent projects to use -include common/config.hpp compilation flag when in doubt, to force-include it? But I'm not sure there's much more we can do on our end to ensure proper propagation, short of adding it to all files, which I don't think we want to do.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine to leave this to the user, if we specify which flags need to be set. Similar how we add MODE_TI when we use sdsl.
IMO The more config.hpp files we add, the more potential freedom for bugs we create

@adamant-pwn adamant-pwn Nov 19, 2025 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose another option for us would be to remove include "commom/config.hpp" from our files and to tell external projects that they need to include it before any other of our headers? Not sure what would be the best practice here.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// Core graph and annotation structures
#include "graph/annotated_dbg.hpp"

// Configuration management

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment could be more informative. As now, it's not helpful at all

Comment on lines +4 to +6
// Auto-generated compile definitions for MetaGraph
// This file is auto-generated by CMake and should not be edited manually
// Note: These definitions complement (not replace) CMake compile definitions

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How should this be edited if not manually?

@adamant-pwn adamant-pwn Nov 19, 2025 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The config.hpp.in should be edited manually. The comment refers to the config.hpp file that CMake generates based on it, as .in file is a template for it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not ideal. First, because unclear what the comment refers to. Second, because there is another config.hpp in the project (cli/config/config.hpp). Last, the things we discussed in DM

@adamant-pwn adamant-pwn Nov 19, 2025 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will clarify. Can also rename file to compile_definitions.hpp or similar.

#include <sdsl/uint128_t.hpp>
#include <sdsl/uint256_t.hpp>

#include "common/config.hpp"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it go before <sdsl/uint128_t.hpp>? That uses MODE_TI

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants