Ah, is this for the vcpkg port? If so thank you for taking a stab at it.

I agree with Dewey's suggestion of prefixing the options, otherwise this makes sense. And we should add a CI config to test it (I can follow up with that)

Thanks for all the suggestions. Yes, it is for vcpkg, I am also working on nanoarrow and fmt ports, see microsoft/vcpkg#43721

It might be helpful to specify a version (I think >= 0.5.0 would do it but nanoarrow is pre-1.0).

If 0.5.0 is the correct version, I can add it.

I also wonder if there's a way to use a pre-built driver (e.g., Python, R, a pre-built .so) in the project you are working on?

There's also a python port which could/shoule be used eventually. R is not bundled in the project I'm working on so I'll leave this exercise for someone else.

And we should add a CI config to test it (I can follow up with that)

CI tests would be great, what are your plans, building on top of the vcpkg dependencies or something else?

CI tests would be great, what are your plans, building on top of the vcpkg dependencies or something else?

I think having one pipeline that enables vcpkg and tries to build with all deps from vcpkg would be the starting point. Let's get this building first though

I can't explain the failing tests, in my opinion the libraries built by the pipelines should be completely equal to before (as the default is still to build with vendored dependencies). Does someone have a hint where to start looking?

Does someone have a hint where to start looking?

Again, the CMake here isn't something I'm familiar with, but you could try flipping the default (i.e., make building against system opt-in) in case there are some builds that for some reason don't see the default options). Something like ADBC_NANOARROW_SOURCE=SYSTEM would be consistent with how Arrow C++ handles this kind of thing.

I kicked all the jobs just to see.

Something seems off in that it appears SQLite tests are failing in odd ways...

Like this - I wonder if something else in the build environment changed?

[ RUN      ] SqliteReaderTest.InferTypedParams
/home/runner/work/arrow-adbc/arrow-adbc/c/driver/sqlite/sqlite_test.cc:446: Failure
Expected equality of these values:
  0
  sqlite3_prepare_v2(db, query.c_str(), query.size(), &stmt, nullptr)
    Which is: 1

/home/runner/work/arrow-adbc/arrow-adbc/c/driver/sqlite/sqlite_test.cc:801: Failure
Expected: Exec(R"(INSERT INTO foo VALUES (0, "foo"), (1, NULL), (2, 4), (3, 1E2))") doesn't generate new fatal failures in the current thread.
  Actual: it does.

Last successful build here: https://github.com/apache/arrow-adbc/actions/runs/13381287796/job/37370182406#step:8:53

-- Found SQLite3: /home/runner/miniconda3/envs/test/include (found version "3.48.0")

vs this one
https://github.com/apache/arrow-adbc/actions/runs/13493324155/job/37705363691?pr=2546#step:8:53

-- Found SQLite3: /home/runner/miniconda3/envs/test/include (found version "3.49.1")

Note to self: the nanoarrow target is linked to various drivers in an unnamespaced version, this should probably be done once in the common target next to nanoarrow::nanoarrow, this might reduce the overall footprint of this dependency in variou CMakeList.txt files.

I'll continue with this cleanup effort once the tests are restored.

P.S. it might be as easy as renaming the target here to unify this with the namespaced version

I see this is breaking elsewhere so let me investigate, thanks

Appears to be #2555

Alright, hopefully if you rebase these problems should be fixed!

Filed #2557 to track adding the CI config

@lidavidm any idea for the last failing test?
Please don't merge yet, I have some last adjustments to make

The last failing test is known flaky (I need to go in and disable ASAN for Meson or otherwise figure out how to replicate it...)

The last failing test is known flaky (I need to go in and disable ASAN for Meson or otherwise figure out how to replicate it...)

For the record, LD_PRELOAD of libSegFault might help to give a stacktrace

I believe the ASAN issue is an upstream bug, at least according to:

llvm/llvm-project#87324

It is confirmed to be flaky, so not sure how much luck we will have with a reproducer.

Does it just affect Dremio? I wonder if we should have the ASAN test run exclude that driver for now. I'd personally hate to disable the entire ASAN suite if the scope of the issue can be limited to one driver

Looks like this is green again - is this OK to re-review/merge?

Yes , good from my side