Scylla: How to build with system (i.e. dynamically linked) c-ares on Debian?

[onlyjob]

How can one properly build _seastar_ with dynamically linked (system) _libc-ares-dev_ (using _pkg-config_ to query libcares.pc),
instead of statically linked sub-moduled _c-ares_ from git repository??

I'm investigating feasibility of packaging ScyllaDB for Debian but ScyllaDB's build system seems to be a mess...

[hakuch]

I'm in the process of finalizing a proposal for an alternative structure for Seastar's build system with CMake that will make this a piece of cake if a similar change is made to Scylla's build system. Until then, I'm not sure this is possible to do without a patch to the build scripts.

[onlyjob]

It is a good idea to use CMake. Please do it.

[avikivity]

@onlyjob please post a patch to make seastar's use of the bundled c-ares optional (I'd like to get rid of the bundled c-ares eventually and this is a good first step).

[onlyjob]

I won't be able to contribute, sorry. I also have no incentive in hacking on this unusual build system. I will wait for transition to CMake (https://github.com/scylladb/seastar/issues/313) which should solve this problem.
Hopefully one day this project will use less uncommon build system... :)

[onlyjob]

@avikivity, let's not close bugs without explanation please. I reckon you've closed this one in favour of https://github.com/scylladb/seastar/issues/313? Problem is not solved, you know, and closing just because I can't contribute a patch is inappropriate.

[avikivity]

@onlyjob, let's not tell other people what to do.

This is not a bug, so it shouldn't have been on the tracker in the first place. If you have questions, ask them on the mailing list.

[onlyjob]

It is a bug as long as you consider serious limitations in build system to be a problem.
This one is serious enough to block downstream integration - definitely a bug and not a question. Please don't be confused by my wording.

[nyh]

@onlyjob why is it a "serious limitation" that Scylla comes with its own version of c-ares instead of using the one already included in the system? What other downside is there besides a small waste of disk space, because Scylla now includes a copy of c-ares inside its executable?

All the discussion of cmake in this thread is a red herring, to not use harsher words. There's nothing in cmake which magically makes it easier to use system libraries, nor nothing in ninja which makes them hard to use. The decision to include a specific version of c-ares inside Seastar was a deliberate decision - that can be rethought (or at least made optional, as @avikivity suggested) - but has nothing to do with the limitations of the existing ninja / python build system. It seems some of the people on this thread have a personal preference of cmake. That's fine. I personally have a preference of the classic "make". But it doesn't mean that something different (in this case, ninja) is "a mess".

That being said, I agree with @onlyjob that this issue should not have been closed. It's still a legitimate request to allow Scylla to be built with the system's c-ares, or more generally - against the system's existing libraries rather than specific versions included (in the good case) with Scylla or (in the bad case) demanded by Scylla.

[onlyjob]

I don't know enough about Ninja build system but here I read it is pretty much confirmed that using current state of ScyllaDB build system it is difficult to dynamically link with system c-ares due to lack of such option...

CMake is much more common than Ninja and that's an advantage even if it is just as easy to implement dynamic linking with Ninja as it is with CMake.

As for "serious limitation", static linking is a terrible idea and a bad practice: https://wiki.debian.org/StaticLinking. It is not about small waste of space of course but about best practice...

[nyh]

@onlyjob c-ares is just one tiny library, and statically linking it does not make the entire project "statically linked". Invariably, in a huge project such as Scylla, thousands of design decisions are involved and not all of them are the "best practice", what you would consider "best practice". So instead of being pedantic about not using the project before your least-favorite decision is reversed, how about trying to use it anyway, as-is? I don't see how the fact that Scylla is built with one small library statically linked truly prevents its acceptance into Debian.

[onlyjob]

Policy compliance is a big thing in Debian and perhaps exception could be made for a _good_ reason. I'm not sure if lack of build system option to use system library is good enough excuse... Besides, size of the library doesn't matter. It dfoesn't make it OK to statically link the library just because it is small. Moreover it is not just _c-ares_... All dependency chain would have to be packaged separately and linked dynamically - _seastar_, _c-ares_, _dpdk_ and _fmt_ (if I didn't miss anything). Unusual build system makes it harder to produce proof of concept and requires significant effort to do so in compliance with policy.