<div dir="auto">For some of us, our processors aren't too strong to build unneeded files 😅 Also, I had figured Meson's disablers would handle this nicely from an impl standpoint. <div dir="auto"> </div><div dir="auto">That being said, I totally understand why you wouldn't want to throw on a ton conflicting options that may not be used that often. <div data-smartmail="gmail_signature" dir="auto">-- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else <a href="https://refi64.com/">https://refi64.com/</a></div></div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 22, 2019, 6:49 AM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Do, 21.03.19 20:19, Ryan Gonzalez (<a href="mailto:rymg19@gmail.com" target="_blank" rel="noreferrer">rymg19@gmail.com</a>) wrote: > Hello! > > I've come to really love using the sd-bus and sd-event APIs for lightweight > D-Bus access and event loops, and I'm sure I'm not the only one. The amount > of bindings to other languages for stuff like sd-bus. However, this > unfortunately doesn't work in a Flatpak environment, and building the > entirety of systemd for some libsystemd stuff just...isn't that > great. Why not? What's the problem? I mean, sure you waste a bit of CPU time, but if you build a minimal build and just throw away everything you are not interested in, what's the problem with that? > My idea was to add a Meson config option that would just build the systemd > libraries, e.g. -Donly-public-libraries. > > That being said, I know that not all the libraries would be buildable this > way. At minimum, udev requires the library version to match the host: > <a href="https://lists.freedesktop.org/archives/systemd-devel/2014-October/024539.html" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/archives/systemd-devel/2014-October/024539.html</a> While there hasn't been a compat breakage in this for a while we generally do not guarantee api stability between libudev and udev's database, so yes, you are are not supposed to mix&match libudev with arbitrary host udev versions. > So I guess this comes down to: > > - Would libsystemd work standalone? What features *wouldn't* work? (I'm > guessing the device and journal APIs.) Depends. sd-bus and sd-event should be fine. sd-device sd-login otoh probably not so much. > - Would a flag like this be considered for addition to the build scripts? Hmm, people request something like this all the time, but I am a bit conservative on these things, I really don#t want to drown our build system in too many options that all conflict with each other... In particular I am not convinced at all that suddenly introducing negative options (i.e. options that do not disable/enable a specific component, but disable/enable all but some) is really a great idea, in particuar, because such logic of "everything else but me" creates all kinds of conflicts if you combine them with similar options. (i mean, what is that even supposed to mean then?) Lennart -- Lennart Poettering, Berlin </blockquote></div>