GNOME Bugzilla – Bug 656818
make bootstrap all or nothing
Last modified: 2012-04-19 12:12:15 UTC
Remove the bootstrap command and moduleset completely. JHBuild should provide assistance if the user's distro autotools aren't recent enough. Or autotools not the correct version (autotools can be fussy with version, but this has settled down recently). Bootstrap modules are: gettext m4 autoconf libtool automake-1.10 automake pkg-config python gmp guile xz gmp & guile can be moved into the modulesets and modules depend on them directly. python is detailed in bug 656790.
I've thought about this some more. I propose: - Remove bootstrap command, bootstrap documentation and don't suggest run bootstrap. - Keep a should-be-provided-by-your-distro moduleset around. For developers who aren't on the latest distro, I can guide them to: jhbuild -m should-be-provided-by-your-distro build autotools Documentation will make it clear that only developers with old distros should run the command. The moduleset should not be called should-be-provided-by-your-distro, I was just using that as an example.
I like this idea more. Anyway I still not very sure that we have to support very old distributions to develop GNOME.
So...in the big picture, I have two concerns: * We need to do a better job explicitly separating runtime dependencies from build dependencies * I'd like to make the jhbuild moduleset more complete; we should make it easier to subset what's built. Concretely for example, I'd like to add libX11 as a <tarball> - in reality, a lot of things depend on X, we just omit it from jhbuild's world. The sysdeps with pkg-config is a strong answer to avoid having to build this if you don't want to. Of bootstrap, guile ships a guile-1.8.pc file, so we could just add it right now as a <tarball>. xz and gmp don't (but we could complain to the library authors). As far as *build* dependencies like python and auto* go...I think we could pretty easily just special case these in a custom jhbuild setup script. Bottom line: Yes, let's remove bootstrap. But you should add xz, gmp, and guile to the external deps moduleset.
External deps are something else; let's not reuse terminology for different things. Months ago, I wrote that someday we could have a <branch/> tag that references a package only, without the tarball part; <repository type="packagekit" name="packagekit"/> <module id="x11"> <pkg-config>x11.pc</pkg-config> <branch repo="packagekit"/> </module> Something like this could be done for modules we do not want to be build by jhbuild, *never*. (for various reasons, for example because it really needs to be installed system wide, like udisks). xz, autotools, git, svn, etc. could be kept in the bootstrap modules (no point in changing its name for the sake of it); and be defined like above.
(In reply to comment #3) > So...in the big picture, I have two concerns: > * I'd like to make the jhbuild moduleset more complete; we should make it > easier to subset what's built. What do you think about including optional deps if they are checked out. Optional deps are basically configurable features, right? So, if there would be an additional subcommand that can easily check out optional deps of a specified module, a user could just add the configuration switches and check out what's necessary for it.
(In reply to comment #4) > External deps are something else; let's not reuse terminology for different > things. True...maybe we could rename the bootstrap moduleset to "builddeps"? > Months ago, I wrote that someday we could have a <branch/> tag that references > a package only, without the tarball part; > > <repository type="packagekit" name="packagekit"/> > > <module id="x11"> > <pkg-config>x11.pc</pkg-config> > <branch repo="packagekit"/> > </module> > > Something like this could be done for modules we do not want to be build by > jhbuild, *never*. Never? I could pretty easily imagine someone hacking on GNOME wanting > (for various reasons, for example because it really needs to > be installed system wide, like udisks). Well we know my opinion of how well our total lack of story for how to hack on system modules worked out for networking in the 3.0 release...but that's indeed a different issue. > xz, autotools, git, svn, etc. could be kept in the bootstrap modules (no point > in changing its name for the sake of it); and be defined like above. Keep it named bootstrap? Ok I guess. xz is a runtime dependency though...I don't like mixing that in with the autotools and git.
(In reply to comment #4) > Months ago, I wrote that someday we could have a <branch/> tag that references > a package only, without the tarball part; > <repository type="packagekit" name="packagekit"/> > <module id="x11"> > <pkg-config>x11.pc</pkg-config> > <branch repo="packagekit"/> > </module> > Something like this could be done for modules we do not want to be build by > jhbuild, *never*. (for various reasons, for example because it really needs to > be installed system wide, like udisks). I like it. > xz, autotools, git, svn, etc. could be kept in the bootstrap modules (no point > in changing its name for the sake of it); and be defined like above. Good idea, but I propse a slight change - autotools is a tarball module, but uses sysdep. If on a new distro JHBuild will never build autotools, but if your distro is older, JHBuild will build autotools. Autotools doesn't provide a .pc, so we'd have to extend the sysdep to support detection of autotool's versions.
*** Bug 668992 has been marked as a duplicate of this bug. ***
Created attachment 206566 [details] [review] Add systemmodule tag, check deps on build, add --nodeps Add a systemmodule modtype. systemmodules are modules that must be provided by your system. 'jhbuild build' will raise an error if the systemmodule is not provided. systemmodules aim to remove the need for 'sudo yum install libcurl-devel perl-XML-Simple ...' pre-setup. I want the often out-of-date http://live.gnome.org/JhbuildDependencies to go away. Here is an example on how to use. In a .modules file: <repository type="tarball" name="system" href="None"/> <systemmodule id="zlib" > <pkg-config>zlib.pc</pkg-config> <branch repo="system" version="1.2"/> </systemmodule> Then to libxml2 package, add: <dep package="zlib"/> Use the 'jhbuild sysdeps' command to learn how your system meets the required dependencies. To turn off systemmodules, use --nodeps or set in ~/.jhbuildrc: check_sysdeps = True Documentation needs updating. Documentation updates not included in patch. This patch needs bug 668434 attachment 205807 [details] [review] to be applied first.
Some comments, without fully understanding what has been proposed just because bug 668992 got marked as a dup here. There are three kinds of software that we want to be able to install with jhbuild: 1) The software we find interesting. GNOME. We want to build this from git always because that's the point of jhbuilding. 2) Software that we depend on and find uninteresting but need a particular version of *and* is always unharmful to install a newer version of. Things like sqlite or pixman. 3) Software that we depend on a particular version of but is potentially harmful to install a new version of. Things like automake and dbus. Installing automake in a non-/usr prefix on a system that already has a bunch of aclocal macros installed in /usr is a great way to prevent things from building. Ditto dbus when it's looking for the system bus socket somewhere in your home directory. At the same time, we need to be able to install these if people want to jhbuild on Mac OS, for example... It's my opinion that we should have something like the current sysdeps mechanism to deal with things in #2 (to save time to the user) and keep an explicit bootstrap process for installing things in #3 only if absolutely necessary. Also: the bootstrap phase should be all-or-nothing with no checking for "already installed". There's a bug with the current bootstrap, for example: if you have pkg-config already on your system but not automake, then automake gets installed but pkg-config doesn't. This means that you have an automake looking in a new aclocal directory and no pkgconfig macros there -- you don't get very far in this situation.
(In reply to comment #10) > and keep an > explicit bootstrap process for installing things in #3 only if absolutely > necessary. Good idea. Even though this bug report is called 'remove bootstrap' the consensus is leave a bootstrap.module, and people needing it are told to 'jhbuild -m bootstrap build meta-bootstrap'. Everything else related to bootstrap will be removed. I didn't know about the all-or-nothing requirement. Handy to know. Thanks.
Craig, could you create another enhancement request for systemmodule (but I don't think it should be done that way, as relying on pkg-config won't work for the modules that are currently listed in bootstrap) This bug report could host patches to 1) update documentating according to recommended bootstrap usage, 2) change the bootstrap command to be all or nothing.
(In reply to comment #12) > Craig, could you create another enhancement request for systemmodule Sure, bug 669554.
Created attachment 206972 [details] [review] move guile, python out of meta-bootstrap Move guile out of bootstrap. bootstrap is bootstrapping a build system, guile doesn't belong here. Move python out of meta-bootstrap. If someone is desperate to build python, they can 'jhbuild -m bootstrap buildone python'. Now bootstrap is all-or-nothing. No sysdeps used. bootstrap is now lean. Yet to do: - Update documentation, don't tell the user to run bootstrap. Well, only in extreme circumstances like MacOS. - Get rid of message 'bootstrap moduleset has been updated since the last time you used it, perhaps you should run jhbuild bootstrap' - Get rid of message 'some bootstrap modules have been updated, perhaps you should update them'
You need to change some code too, there is some custom version checking in bootstrap.py.
Comment on attachment 206972 [details] [review] move guile, python out of meta-bootstrap Committed with additional 3.6 moduleset. http://git.gnome.org/browse/jhbuild/commit/?id=3b8843eeb3dd0757e70eeaff64a5e87c0cd0034f
Created attachment 211368 [details] [review] doc: Don't recommend running bootstrap Actually recommend against running bootstrap.
Created attachment 211369 [details] [review] Remove warnings to run bootstrap
Created attachment 211370 [details] [review] Make bootstrap build modules unconditionally Revert of c896c9340755
Comment on attachment 211368 [details] [review] doc: Don't recommend running bootstrap Committed. http://git.gnome.org/browse/jhbuild/commit/?id=dc264b9f3a1eaaf41c5d977d0b056e12773cc148
Comment on attachment 211369 [details] [review] Remove warnings to run bootstrap Committed. http://git.gnome.org/browse/jhbuild/commit/?id=20d7a75d32b25b4a8908ef697aa987d8f5edec6a
Comment on attachment 211370 [details] [review] Make bootstrap build modules unconditionally Committed. http://git.gnome.org/browse/jhbuild/commit/?id=092cd1feaee112dba11dd3b3b1a27ec3a0f06cb7