On Wed, 13 May 2020 18:24:28 +0200 Daniel Kiper <dki...@net-space.pl> wrote:
> On Fri, May 08, 2020 at 06:50:48AM +0200, Hans Ulrich Niedermann > wrote: > > The example kernel has assembly language boot code for both > > i386 and mips, but the mips assembly code used to be built > > unconditionally, even if the build is using non-mips build > > tools such as for x86_64 or i386. > > > > This makes the example kernel build at least for i386, both > > on i386 and on x86_64 hosts. > > > > * renames the i386 boot code from boot.S to boot_i386.S > > to go along with the mips boot code in boot_mips.S > > > > * adds AC_CANONICAL_HOST to select the proper boot code: > > > > * i386 if building on x86_64 (adds -m32) or on i[3456]86 > > * mips if building for mips* > > * do not build the kernel if building for another system > > > > * adds m4 quoting and uses AS_HELP_STRING use in configure.ac > > > > * fixes the name of the constants used in boot_i386.S > > to use the actual constant names from multiboot2.h > > > > * documents both boot_i386.S and boot_mips.S in the > > multiboot.texi page > > May I ask you to split this patch into logical parts? Being a little slow on the uptake, I only just figured out why I ended up with that big of a patch. When given a building and working source tree, I usually make my commits such that they are small, self-contained and keep the source tree in a building and working state. That is why I usually add changes until it finally builds/works. However, that is a useless argument here, as the state of the source tree *before* my change is non-building maybe-working, so if the source tree does not build *after* my small, self-contained change, my change has not made it worse and can thusly still be considered good. Changing my normal modus operandi accordingly; considering failing builds as normal for now. Expect a good dozen patches in a day or two. Uli _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel