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.
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. -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ On Fri, Mar 22, 2019, 6:49 AM Lennart Poettering <[email protected]> wrote: > On Do, 21.03.19 20:19, Ryan Gonzalez ([email protected]) 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: > > > https://lists.freedesktop.org/archives/systemd-devel/2014-October/024539.html > > 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 >
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
