Bruno Haible writes: Hi!
> Janneke Nieuwenhuizen wrote: >> Are are we creating a problem for >> bootstrapping (or even a dependency cycle) when introducing this new >> dependency into a certain package. > > I think you answered this question with "no", when writing in [1]: > > "Even more recently (2018), the GNU C Library glibc-2.28 adds Python > as a build requirement" How so? In 2013, the GCC folks decided that their gcc-4.8 would no longer be a directly bootstrappable compiler by introducing a (casual?) dependency on c++. That's pretty bad for bootstrapping, and it would be amazing if someone could revet that mistake. With glibc-2.28, a similar bootstrappable mistake was made. Making an essential GNU package such as GCC or Glibc non-bootstrappable has severe consequences. As an example, we have been working on the RISC-V bootstrap for about a year with three people. One of the problems here is that RISC-V was only added to a non-bootstrappable version of GCC: 7.5.0, while the GCC team failed to maintain their last bootstrappable version: 4.7.4. In other words, the RISC-V backend needed to backported and someone else now needs to maintain a bootstrappable version of GCC. When something else like this changes in the future, that isn't as "easily" backported, what do we do? Terrible! > So, how do you avoid Python when building glibc? Do you use musl libc as > a first stage, and only build glibc once a python built with musl exists? Currently we aren't directly hit by this because we build glibc-2.2.5 and glibc-2.16 first. We added these earlier Glibc's because we allowed ourcelves to cut some corners and there earlier versions were more easy to bootstrap. On the roadmap is to remove as many ancient versions as we can, as they are potential time-bombs. In fact, glibc-2.2.5 is problematic for the ARM and the RISC-V bootstrap, so we'll get rid of that. We won't be able to get rid of advancing beyond glibc-2.27 without adding a yet another non-GNU package such as musl libc. Possibly a nice hack for now, but what to do when we want to port the bootstrap to the Hurd? Again, terrible! > Also, from the diagrams in [1][2][3] it looks like the full-source bootstrap > uses tarballs frozen in time (make-3.80, gcc-2.95.3, gcc 4.7.3, etc.). So, > even if newer versions of 'make' or 'gcc' will use a Python-based gnulib-tool, > there won't be a problem, because the bootstrap of these old tarballs will > be unaffected. indeed. For the current situtation (that's less than great and are working on to resolve), making essential GNU packages less bootstrappable is of no consequence. Cleaning-up the full-source bootstrap and making it more or less future-proof, might be challenged by such a new dependency. Greetings, Janneke -- Janneke Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
