refactor: drop property_tree dependency

[Becheler]

Before submitting

• This PR targets the develop branch.
• I searched for an existing PR or issue covering the same change.
• My contribution is licensed under the Boost Software License 1.0.

Type of change

• Bug fix
• New feature or API addition
• Refactor (no behavior change)
• Documentation
• Build, CI, or tooling
• Other (specify below)

Does this PR introduce a breaking change?

• Yes (describe migration impact below)
• No

What this PR does

• Remove dependency to Boost.PropertyTree and its 58 transitive dependencies
• Vendor the core BGL uses (rapidxml header) with no behavioral change
• Performance on local benchmark against develop:
  • x3.5 faster
  • x3.7 less memory

@jeremy-murphy : "It's not a refactor because of the change to the exception type. That's not a blocker, it just means we need to treat this change appropriately such as in the release notes make it clear about what the breaking change is."

Motivation

• GraphML was originally written in 2007 by Tiago de Paula Peixoto using expat, an external C XML library with a handmanaged SAX callback parser.
• In 2009, Jeremiah Willcock rewrote it onto Boost.PropertyTree (commit e5aebbc, "fixes #3300"), which removed the external expat dependency and cut the parser from ~357 lines to ~97 by replacing the SAX state machine with a simple tree walk.
• But in 2026 property_tree becomes the heavy dependency worth dropping.
• Rapidxml.hpp is the only real dependency. There is no need to bring property_tree itself, on the contrary: it copies the whole tree again and is largely inefficient.

property_tree's value is a uniform generic tree with a string-path query API, the same interface we would use for JSON or INI. But GraphML never needs that generality: it only ever asks "tag name? this attribute? this text?", which a rapidxml node answers directly.

Under the hood, property_tree already parses XML with rapidxml (nodes are non owning, pointers to buffer), then copies the entire parse result into its generic ptree so the uniform API works (pure overhead with many allocations as nodes are recursive pairs string/ptree).

This PR keeps the exact same rapidxml parser but walks its DOM directly, deleting the ptree copy (and with it the property_tree dependency).

Testing

The legacy tests properly exercise the round trip and code path to guarantee no regression. The only legacy behavior we can't match is the exception type being raised. Malformed XML now throws boost::parse_error instead of property_tree's xml_parser_error/ptree_bad_path

Benchmark script to compile and run on develop then on the PR branch:

#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/graphml.hpp>
#include <boost/graph/random.hpp>
#include <boost/random/mersenne_twister.hpp>

#include <algorithm>
#include <chrono>
#include <iostream>
#include <sstream>
#include <string>
#include <vector>

#include <sys/resource.h>

constexpr std::size_t NVERTICES = 100000;
constexpr std::size_t NEDGES = 1000000;
constexpr int REPS = 5;

using graph_t = boost::adjacency_list< boost::vecS, boost::vecS,
    boost::directedS,
    boost::property< boost::vertex_name_t, std::string,
        boost::property< boost::vertex_color_t, int > >,
    boost::property< boost::edge_weight_t, double > >;

static std::string make_graphml()
{
    graph_t g;
    boost::mt19937 rng(42);
    boost::generate_random_graph(g, NVERTICES, NEDGES, rng, false, false);

    std::size_t i = 0;
    graph_t::vertex_iterator vi, ve;
    for (boost::tie(vi, ve) = vertices(g); vi != ve; ++vi, ++i)
    {
        boost::put(boost::vertex_name_t(), g, *vi, "node <" + std::to_string(i) + "> & \"x\"");
        boost::put(boost::vertex_color_t(), g, *vi, int(i % 255));
    }
    double w = 0.5;
    graph_t::edge_iterator ei, ee;
    for (boost::tie(ei, ee) = edges(g); ei != ee; ++ei)
        boost::put(boost::edge_weight_t(), g, *ei, w += 0.001);

    boost::dynamic_properties dp;
    dp.property("name", boost::get(boost::vertex_name_t(), g));
    dp.property("color", boost::get(boost::vertex_color_t(), g));
    dp.property("weight", boost::get(boost::edge_weight_t(), g));
    std::ostringstream out;
    boost::write_graphml(out, g, dp, true);
    return out.str();
}

int main()
{
    std::string xml = make_graphml();
    const double mb = xml.size() / (1024.0 * 1024.0);

    std::vector< double > ms;
    for (int r = 0; r < REPS; ++r)
    {
        graph_t g;
        boost::dynamic_properties dp(boost::ignore_other_properties);
        dp.property("name", boost::get(boost::vertex_name_t(), g));
        dp.property("color", boost::get(boost::vertex_color_t(), g));
        dp.property("weight", boost::get(boost::edge_weight_t(), g));
        std::istringstream in(xml);
        auto t0 = std::chrono::steady_clock::now();
        boost::read_graphml(in, g, dp);
        auto t1 = std::chrono::steady_clock::now();
        ms.push_back( td::chrono::duration< double, std::milli >(t1 - t0).count());
    }
    std::sort(ms.begin(), ms.end());

    rusage ru{};
    getrusage(RUSAGE_SELF, &ru);
#ifdef __APPLE__
    double peak_mb = ru.ru_maxrss / (1024.0 * 1024.0);
#else
    double peak_mb = ru.ru_maxrss / 1024.0;
#endif

    std::cout << "size=" << mb << "MB  read median=" << ms[ms.size() / 2]  << "ms  peakRSS=" << peak_mb << "MB\n";
    return 0;
}

On develop:

size=113.66MB  read median=6382.51ms  peakRSS=5388.23MB

On PR:

size=113.66MB  read median=1825.4ms  peakRSS=1463.05MB

Checklist

• Existing tests pass (b2 in the test/ directory).
• New behavior is covered by a test, or this is a docs / build / refactor change.
• Documentation was updated if user-facing behavior changed.
• No new compiler warnings on the platforms I built against.

[github-actions]

Boost dependency footprint vs develop (auto-generated).
PR run 33872820738 vs develop run 33724349044 (720c137eff).

Header-inclusion weights (graph files pulling each direct dependency in):

Dependency	develop	PR	Δ
property_tree	2	0	-2
optional	7	6	-1
assert	31	32	+1
config	93	94	+1

Transitive Boost modules: 65 → 49 (-16)

• removed: align, atomic, chrono, date_time, endian, numeric~conversion, phoenix, pool, property_tree, proto, ratio, serialization, spirit, thread, tokenizer, variant

[github-actions]

Compiler-warning counts vs develop (auto-generated).
PR run 33872820760 vs develop run 33724349100 (720c137eff).

Job	Baseline	After	Delta
macos (clang, 14)	438	439	+1
macos (clang, 17)	401	402	+1
macos (clang, 20)	401	402	+1
ubuntu (clang-19, 14)	438	439	+1
ubuntu (clang-19, 17)	401	402	+1
ubuntu (clang-19, 20)	401	402	+1
ubuntu (clang-19, 23)	401	402	+1
ubuntu (gcc-14, 14)	371	373	+2
ubuntu (gcc-14, 17)	367	369	+2
ubuntu (gcc-14, 20)	367	369	+2
ubuntu (gcc-14, 23)	367	369	+2
windows_msvc_14_3 (msvc-14.3)	961	961	0

[codecov]

Codecov Report

❌ Patch coverage is 98.66667% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/graphml.cpp	98.30%	0 Missing and 1 partial ⚠️

❌ Your patch check has failed because the patch coverage (98.66%) is below the target coverage (100.00%). You can increase the patch coverage or adjust the target coverage.

📢 Thoughts on this report? Let us know!

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jeremy-murphy]

It's not a refactor because of the change to the exception type. That's not a blocker, it just means we need to treat this change appropriately such as in the release notes make it clear about what the breaking change is.

[jeremy-murphy]

Anyway, looks like you've got your work cut out to get the coverage back up. :)

[Becheler]

@jeremy-murphy thank you for the feedback !

Code coverage was actually never 100% so any PR touching uncovered code must cover it, it's cumbersome albeit necessary ahah 😆 Coverage is now up, with a single missing line partially covered, I suggest to leave it as is.

1. Do you think this specific API breaking requires a deprecation cycle or release note + a warning in the documentation will be enough ?
2. Also what is your favored way to accumulate release notes during in between releases ? A pinned discussion on the Github discussion maybe ?