GNOME Bugzilla – Bug 711773
To improve newcomers' experience, "build" command behaviour should change to what "buildone" currently does
Last modified: 2021-05-17 15:59:21 UTC
How many planet.gnome blog entries have to be written to stop clarifying how "jhbuild build" works (and how "buildone" is your friend) to switch to this behaviour by default? Last one was: http://blog.desmottes.be/post/2013/11/08/Building-a-single-module-using-jhbuild So, IMO, what should be done here: 1) Make "build" command behave like "buildone" behaves today. 2) Create new "buildall" command which behaves like "build" behaves today. 3) Ditch the "buildone" command (or just make it an alias of "build", announcing in the command line that it is deprecated). And last but not least: 4) If "jhbuild build foo" fails for some reason in a "configure" step, jhbuild should advice the use of `jhbuild build bar foo` ('bar' being the dependency that failed to be found) or `jhbuild buildall foo` as a last resource. If maintainers agree with this, I'll find the time to cook a patch. Thanks
s/to stop clarifying/to clarify/
I really disagree that 'buildone' as a default is at all useful. This is not going to get you very far with almost any module, and when the failure occurs (as it will, during ./configure, in a way that we are unable to detect) the user is going to be left confused. Even if buildone was a reasonable default (and I don't think it is), I would still oppose this change on the basis of how confusing it would be to existing users. It would also be monumentally confusing to newcomers who happened to find some existing documentation on the topic (which is scattered all across the net in many places that we do not control).
I agree with Ryan. Buildone is a special case, mostly to be used when one needs to rebuild a module with new autogenargs or flags. Besides, if all of the dependencies are already built and up-to-date, jhbuild will skip over them producing the same result.
How about deprecating "build", renaming it to "buildall", and when someone writes "jhbuild build foo" tell her to choose "buildall" or "buildone"?
(In reply to Andrés G. Aragoneses (IRC: knocte) from comment #4) > How about deprecating "build", renaming it to "buildall", and when someone > writes "jhbuild build foo" tell her to choose "buildall" or "buildone"? Why? What you and M. Desmottes are missing is that jhbuild's central purpose is to build a module and all of its dependencies for developers who are working on the whole Gnome stack or working in a non-Linux environment. Using jhbuild after apt-get builddeps is silly: Just clone the repo of the package you want to work on, configure it, and make it. If you're actually writing code for that package you're going to be typing "make" a lot (or doing equivalent in your IDE); touch a Makefile and you've got to reconfigure. Surely you don't go back to jhbuild every time you fix a typo in your work! BTW, the link is wrong, it's http://blog.desmottes.be/?post/2013/11/08/Building-a-single-module-using-jhbuild (note the '?' before post).
(In reply to John Ralls from comment #5) > (In reply to Andrés G. Aragoneses (IRC: knocte) from comment #4) > > How about deprecating "build", renaming it to "buildall", and when someone > > writes "jhbuild build foo" tell her to choose "buildall" or "buildone"? > > Why? > > What you and M. Desmottes are missing is that jhbuild's central purpose is > to build a module and all of its dependencies for developers who are working > on the whole Gnome stack or working in a non-Linux environment. Right. But I bring this up to improve the experience for newcomers. And this is something that is actually being talked to, in the desktop mailing list: https://mail.gnome.org/archives/desktop-devel-list/2015-July/thread.html#00012 When people mention jhbuild in this thread, they always come up with the fact that building all dependencies of a certain module, from master branch, is constantly giving build errors that are unrelated to the stability of the module. This is not a good newcomers experience. Certainly jhbuild is meant to allow you to work on certain module by being able to build all of its dependencies. That's the key: "by being able". But it should not make things more complex than they are, that is, if you already have a dependency installed on your system which is new enough for your module, it should just use it. It should not default to building unstable software. Maybe we need a new "build" behaviour here which is not covered yet in comment#0: build only the dependencies that are not new enough? I guess we can do this via pkg-config and the "version" attribute in the .modules XML file?
> if you already have a dependency installed on your system which is new enough for your module, it should just use it. Unfortunately there's no way to know that with our current build systems.
(In reply to Andrés G. Aragoneses (IRC: knocte) from comment #6) > Maybe we need a new "build" behaviour here which is not covered yet in > comment#0: build only the dependencies that are not new enough? I guess we > can do this via pkg-config and the "version" attribute in the .modules XML > file? No, we need to make clear that: * jhbuild is not the right tool for application developers unless they don't have another way to obtain the gnome development stack. * Master branches are inherently unstable. Even when an application developer does need to use jhbuild, he should be using release modulesets (e.g. either gnome-suites-core-deps-3.16.modules in jhbuild or the gnome-3-16 branch in gnome-modulesets). Sorry, the dissemination of bad advice in random mailing lists and blogs is not a jhbuild bug.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/jhbuild/-/issues/188.