On Mon, Sep 8, 2014 at 6:32 PM, Frederic Peters <[email protected]> wrote: > Sriram Ramkrishna wrote: >> On Mon, Sep 8, 2014 at 9:55 AM, Zeeshan Ali (Khattak) >> <[email protected]> wrote: >> > >> > Unless someone has plans on fixing this (somehow) soon, I would >> > suggest we either kick out all system services from jhbuild all >> > together or at least remove them from dependency list of other >> > modules. >> > >> +1 for me, It should try to use what is already on the system. > > It does (basically it sets PKG_CONFIG_PATH to also look into the > system directories, so if you have networkmanager development files > installed, it will find them), and it even automatically skip modules > that are installed with a proper version (but it has to know the > required minimum version, and we used to maintain that appropriately > with "external deps", less so thosedays).
1. Many users won't have the development packages installed for these system services and thus this won't be any solution for them. What sri meant (correct me if I'm wrong) is to simply leave system services to system. 2. Not all services provide a library (e.g geoclue currently doesn't) so deps are setup for runtime-only. In that case, build of such services is almost always redundant. > Also, while it's not possible to run system services, it may still be > useful to have them in jhbuild, as they provide libraries that will be > used by other modules. For example it is required to have > accountsservice libraries to build and run gnome-control-center, but > most panels will be fine if the service itself is not running. If control-center would need latest of accountsservice, its likely going to be because of new D-Bus API rather than just some convenience API provided by the library, wouldn't it? If control-center (built in jhbuild) can use the service from system at runtime, it can also use the library from system? >> Besides, what is the end goal of jhbuild? Is it to write code against >> the latest GNOME or is it to build a complete desktop environment? I >> would argue that we already have gnome-continuous for the latter. >> Reducing jhbuild's scope would help make it an easier tool to manage >> and actually work. > > It would certainly be easier but I don't foresee the double goal of > jhbuild changing much, because it still has to fulfil both in some > ways (as it's made to run in a VM, I don't feel like gnome-continuous > provides an appropriate testing/working environment). > > Still, we may envision changes; for example it's now possible to have > conditional modules, so perhaps we could work to have it both ways, > with a default set without the system services, and a flag to enable > them, a la "jhbuild --conditions=+system-services build". Although I can totally agree with going for this approach, I still wonder what would user really achieve with this? Why build things that in the end will be useless? -- Regards, Zeeshan Ali (Khattak) ________________________________________ Befriend GNOME: http://www.gnome.org/friends/ _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
