GNOME Bugzilla – Bug 653050
"jhbuild make" command
Last modified: 2011-10-04 13:07:54 UTC
This is a zero-configuration developer convenience wrapper for "make" that basically should works out of the box on all GNOME modules. A later patch will convert the autotools jhbuild modtype to consume metabuild-raw (or possibly metabuild). What do I mean my zero-configuration? Basically that you can type: jhbuild shell # sets the JHBUILD_PREFIX environment variable etc. cd /path/to/module metabuild install In contrast, "jhbuild buildone" will e.g. attempt to access the network by default, and you have to type the module name (even if you're in that directory right now). In particular jhbuild running "git stash" is probably right for people not actively hacking on a module, but I really hate it for ones I am hacking on =) Also, one of the goals of metabuild is to push some metadata into the module itself (such as whether it supports parallel make, srcdir != builddir), etc. The chain of control for a future patch will likely be: jhbuild -> metabuild-raw metabuild -> metabuild-raw However I'd like to add some of the metabuild features (like logging) to jhbuild.
Created attachment 190315 [details] [review] metabuild: New script
I am really not a fan of this, as a feature of jhbuild as a development tool is to display the commands that are used, which gives the aspiring developer to learn those standard commands. If there are problems with buildone, if you don't like the default behaviour, options are possible.
Frederic, can we have some discussion before something is closed WONTFIX please?
(In reply to comment #2) > I am really not a fan of this, as a feature of jhbuild as a development tool is > to display the commands that are used, which gives the aspiring developer to > learn those standard commands. Ah...what?? Like someone would learn about g++ from seeing it scroll by a lot in the build output? That seems really bizarre to me. Or are you concerned about the bootstrap behavior, like knowing how to run ./autogen.sh? In that case, that's the purpose of: http://people.gnome.org/~walters/docs/build-api.txt > If there are problems with buildone, if you don't like the default behaviour, > options are possible. I guess I could make buildone, if no arguments are given, use the current directory (and don't do a network update?) Or maybe just typing "jhbuild" does that?
(In reply to comment #2) > I am really not a fan of this, as a feature of jhbuild as a development tool is > to display the commands that are used, which gives the aspiring developer to > learn those standard commands. And of course, as a massive bonus, the full compilation log is avaliable in /run/user/walters/metabuild/$pkgname.log. I don't know about you, but over and over on IRC I have to tell people to run "make V=1" so I can debug problems, and then they have to pastebin it manually. With this model, I can just tell someone pastebin /run/user/walters/metabuild/$pkgname.log.
Colin, of course things can be discussed, and it could even happen before patches are written. It looks like different issues are mixed here, like the "git stash" behaviour or the possibility of log files, intertwined with the perspective of cleaning the autotools modtype because all modules would conform to a single API.
(In reply to comment #6) > Colin, of course things can be discussed, and it could even happen before > patches are written. This script started out before I even thought of adding it to jhbuild. > It looks like different issues are mixed here, like the "git stash" behaviour > or the possibility of log files, intertwined with the perspective of cleaning > the autotools modtype because all modules would conform to a single API. Absolutely true. So can we reopen the bug and have a discussion about how this could be integrated nicely, and what features could go where?
(In reply to comment #7) > Absolutely true. So can we reopen the bug and have a discussion about how this > could be integrated nicely, and what features could go where? I'd favour different bug reports for different issues.
(In reply to comment #8) > (In reply to comment #7) > > Absolutely true. So can we reopen the bug and have a discussion about how this > > could be integrated nicely, and what features could go where? > > I'd favour different bug reports for different issues. Ok, let's make this bug a meta-bug then. I'll list the features here: * Automatically use "chrt --idle 0 ionice -c 3 make" * Build logging * Filter make output for terminal (like AM_SILENT_RULES, except you can still get the full log) * Single, simple command to wrap "./autogen.sh + make" for the current module * Implementation of BUILD API and draining metadata from moduleset into module itself - Use srcdir != builddir by default (if module says we can) - Use parallel make by default (unless module says we can't)
So before I do any more on this, we need some high level decision on naming and architecture. Ultimately what I'd like to have is: jhbuild -> metabuild -> jhbuild-autotools Where "metabuild" is something roughly resembling the metabuild script (does build output filtering, chrt --idle etc.), and jhbuild drives any policy like -j arguments down into it. jhbuild-autotools would be a separate process that contains the current logic in modtypes/autotools.py; it would take arguments for any policy. For example: jhbuild-autotools --builddir=_build --makeflag="-j 12" Likewise, there would be jhbuild-distutils, jhbuild-cmake. Why separate processes? Two reasons. First, it makes it trivial to plug in to metabuild which needs to be a standalone executable. Second, at a high level I'd like to move jhbuild to be event-driven rather than synchronous. Look at the hideous, horrible hacks frontends/gtk.py has to do to not block on running "make". I like the name "metabuild" a lot personally, since it's both descriptive, and conceptually independent of (but benefits from) jhbuild. I could be convinced to call it "jhmake" or something though.
Reopening so I can use as a tracker.
Created attachment 191958 [details] [review] "jhbuild make": New command This is a developer convenience command for: jhbuild buildone -nf $(basename $(pwd))
This patch still applies to master and is ready for review.
Created attachment 197823 [details] [review] "jhbuild make": New command Fix to initialize moduleset
Could you move it in its own module (jhbuild/commands/make.py), this should just be a matter of copying the code, no change needed. Then go ahead and push.
Attachment 197823 [details] pushed as a0032d1 - "jhbuild make": New command