[U-Boot-Users] RFC: Concise Build Output

Folks,
In the spirit of the Linux and Git build systems, I have a modified U-Boot build system that supports a much more concise output! One of the primary motivations for this style of output is that it will very readily highlight build issues and problems as your build progresses. The original, complete build output is obtainable by simply supplying "V=1" on the make invocation in exactly the same way as both Linux and Git do today.
I've not converted all 300 boards to this new scheme yet, but would like your feedback on the approach. I know there are a few rough edges; those are easily smoothed out. I'd like to hear your comments on the overall approach before I spend too much more time on it!
The ambitious amongst you can clone or inspect the repository with these modifications from here:
git://jdl.com/software/u-boot.cfg
Here is a sample build output for the MPC8641HPCN_config.
Enjoy, jdl
----------------------------------------------------------------
% make SUBDIR tools SYMLN environment.c SYMLN crc32.c SYMLN sha1.c make[1]: Nothing to be done for `_depend'. SUBDIR examples make[1]: Nothing to be done for `_depend'. Generating include/autoconf.mk SUBDIR tools HOSTCC img2srec.o HOSTCC img2srec HOSTSTRIP img2srec HOSTCC mkimage.o HOSTCC crc32.o HOSTCC mkimage HOSTSTRIP mkimage HOSTCC envcrc.o HOSTCC environment.o HOSTCC sha1.o HOSTCC envcrc HOSTCC ubsha1.o HOSTCC ubsha1 HOSTCC gen_eth_addr.o HOSTCC gen_eth_addr HOSTSTRIP gen_eth_addr HOSTCC bmp_logo.o HOSTCC bmp_logo HOSTSTRIP bmp_logo GEN /home/jdl/FSL/u-boot-cfg/include/bmp_logo.h SUBDIR examples CC hello_world.o CC sched.o CC ppc_longjmp.o CC ppc_setjmp.o CC stubs.o AR libstubs.a LINK hello_world OBJCOPY hello_world.srec LINK sched OBJCOPY sched.srec OBJCOPY hello_world.bin OBJCOPY sched.bin SUBDIR cpu/mpc86xx CC start.o SUBDIR lib_generic/ CC bzlib.o CC bzlib_crctable.o CC bzlib_decompress.o CC bzlib_randtable.o CC bzlib_huffman.o CC crc32.o CC ctype.o CC display_options.o CC div64.o CC ldiv.o CC sha1.o CC string.o CC vsprintf.o CC zlib.o AR libgeneric.a SUBDIR board/freescale/common/ CC sys_eeprom.o CC pixis.o AR libfreescale.a SUBDIR board/freescale/mpc8641hpcn/ CC init.o CC mpc8641hpcn.o AR libmpc8641hpcn.a SUBDIR cpu/mpc86xx/ CC cache.o CC traps.o CC cpu.o CC cpu_init.o CC speed.o CC interrupts.o CC spd_sdram.o AR libmpc86xx.a SUBDIR lib_ppc/ CC ppcstring.o CC ticks.o CC board.o CC bat_rw.o CC cache.o CC extable.o CC kgdb.o CC time.o CC interrupts.o AR libppc.a SUBDIR fs/cramfs/ CC cramfs.o CC uncompress.o AR libcramfs.a SUBDIR fs/fat/ CC fat.o CC file.o AR libfat.a SUBDIR fs/fdos/ CC fat.o CC vfat.o CC dev.o CC fdos.o CC fs.o CC subdir.o AR libfdos.a SUBDIR fs/jffs2/ CC jffs2_1pass.o CC compr_rtime.o CC compr_rubin.o CC compr_zlib.o CC mini_inflate.o CC compr_lzo.o CC compr_lzari.o AR libjffs2.a SUBDIR fs/reiserfs/ CC reiserfs.o CC dev.o CC mode_string.o AR libreiserfs.a SUBDIR fs/ext2/ CC ext2fs.o CC dev.o AR libext2fs.a SUBDIR net/ CC net.o CC tftp.o CC bootp.o CC rarp.o CC eth.o CC nfs.o CC sntp.o AR libnet.a SUBDIR disk/ CC part.o CC part_mac.o CC part_dos.o CC part_iso.o CC part_amiga.o AR libdisk.a SUBDIR drivers/bios_emulator/ CC atibios.o CC biosemu.o CC besys.o CC bios.o CC x86emu/decode.o CC x86emu/ops2.o CC x86emu/ops.o CC x86emu/prim_ops.o CC x86emu/sys.o CC x86emu/debug.o AR libatibiosemu.a SUBDIR drivers/block/ CC ahci.o CC ata_piix.o CC sil680.o CC sym53c8xx.o CC systemace.o AR libblock.a SUBDIR drivers/dma/ CC MCD_tasksInit.o CC MCD_dmaApi.o CC MCD_tasks.o /usr/powerpc/bin/powerpc-linux-ar cr libdma.a MCD_tasksInit.o MCD_dmaApi.o MCD_tasks.o SUBDIR drivers/hwmon/ CC adm1021.o CC ds1621.o CC ds1722.o CC ds1775.o CC lm75.o CC lm81.o AR libhwmon.a SUBDIR drivers/i2c/ CC fsl_i2c.o CC omap1510_i2c.o CC omap24xx_i2c.o CC tsi108_i2c.o AR libi2c.a SUBDIR drivers/input/ CC i8042.o CC keyboard.o CC pc_keyb.o CC ps2ser.o CC ps2mult.o AR libinput.a SUBDIR drivers/misc/ CC ali512x.o CC ns87308.o CC status_led.o AR libmisc.a SUBDIR drivers/mtd/ CC at45.o CC cfi_flash.o CC dataflash.o CC mw_eeprom.o AR libmtd.a SUBDIR drivers/mtd/nand/ CC nand.o CC nand_base.o CC nand_ids.o CC nand_ecc.o CC nand_bbt.o CC nand_util.o CC fsl_upm.o AR libnand.a SUBDIR drivers/mtd/nand_legacy/ AR libnand_legacy.a SUBDIR drivers/mtd/onenand/ CC onenand_uboot.o CC onenand_base.o CC onenand_bbt.o AR libonenand.a SUBDIR drivers/net/ CC 3c589.o CC bcm570x.o CC bcm570x_autoneg.o CC 5701rls.o CC cs8900.o CC dc2114x.o CC dm9000x.o CC e1000.o CC eepro100.o CC enc28j60.o CC fsl_mcdmafec.o CC inca-ip_sw.o CC ks8695eth.o CC lan91c96.o CC macb.o CC mcffec.o CC natsemi.o CC ne2000.o CC netarm_eth.o CC netconsole.o CC ns7520_eth.o CC ns8382x.o CC ns9750_eth.o CC pcnet.o CC plb2800_eth.o CC rtl8019.o CC rtl8139.o CC rtl8169.o CC s3c4510b_eth.o CC smc91111.o CC tigon3.o CC tsec.o CC tsi108_eth.o CC uli526x.o AR libnet.a SUBDIR drivers/net/sk98lin/ CC skge.o CC skaddr.o CC skgehwt.o CC skgeinit.o CC skgepnmi.o CC skgesirq.o CC ski2c.o CC sklm80.o CC skqueue.o CC skrlmt.o CC sktimer.o CC skvpd.o CC skxmac2.o CC skcsum.o CC uboot_skb.o CC uboot_drv.o AR libsk98lin.a SUBDIR drivers/pci/ CC fsl_pci_init.o CC pci.o CC pci_auto.o CC pci_indirect.o CC tsi108_pci.o CC w83c553f.o AR libpci.a SUBDIR drivers/pcmcia/ CC mpc8xx_pcmcia.o CC pxa_pcmcia.o CC rpx_pcmcia.o CC ti_pci1410a.o CC tqm8xx_pcmcia.o CC marubun_pcmcia.o AR libpcmcia.a SUBDIR drivers/spi/ CC mpc8xxx_spi.o /usr/powerpc/bin/powerpc-linux-ar cr libspi.a mpc8xxx_spi.o SUBDIR drivers/rtc/ CC date.o CC bf5xx_rtc.o CC ds12887.o CC ds1302.o CC ds1306.o CC ds1307.o CC ds1337.o CC ds1374.o CC ds1556.o CC ds164x.o CC ds174x.o CC ds3231.o CC m41t11.o CC m41t60.o CC max6900.o CC m48t35ax.o CC mc146818.o CC mk48t59.o CC mpc5xxx.o CC mpc8xx.o CC pcf8563.o CC s3c24x0_rtc.o CC rs5c372.o CC rx8025.o CC mcfrtc.o CC x1205.o AR librtc.a SUBDIR drivers/serial/ CC atmel_usart.o CC mcfuart.o CC ns9750_serial.o CC ns16550.o CC s3c4510b_uart.o CC serial.o CC serial_max3100.o CC serial_pl010.o CC serial_pl011.o CC serial_xuartlite.o CC serial_sh.o CC usbtty.o AR libserial.a SUBDIR drivers/usb/ CC isp116x-hcd.o CC sl811_usb.o CC usb_ohci.o CC usbdcore.o CC usbdcore_ep0.o CC usbdcore_mpc8xx.o CC usbdcore_omap1510.o AR libusb.a SUBDIR drivers/video/ CC ati_radeon_fb.o CC cfb_console.o CC ct69000.o CC mb862xx.o CC sed13806.o CC sed156x.o CC sm501.o CC smiLynxEM.o CC videomodes.o AR libvideo.a SUBDIR post/ CC post.o CC tests.o AR libpost.a SUBDIR post/drivers/ CC i2c.o CC memory.o CC rtc.o AR libpostdrivers.a SUBDIR post/lib_ppc/ CC asm.o CC cpu.o CC cmp.o CC cmpi.o CC two.o CC twox.o CC three.o CC threex.o CC threei.o CC andi.o CC srawi.o CC rlwnm.o CC rlwinm.o CC rlwimi.o CC store.o CC load.o CC cr.o CC b.o CC multi.o CC string.o CC complex.o AR libpostppc.a SUBDIR post/lib_ppc/fpu/ CC fpu.o CC 20001122-1.o CC 20010114-2.o CC 20010226-1.o CC 980619-1.o CC acc1.o CC compare-fp-1.o CC mul-subnormal-single-1.o AR libpostppcfpu.a SUBDIR common/ CC main.o CC ACEX1K.o CC altera.o CC bedbug.o CC circbuf.o CC cmd_autoscript.o CC cmd_bdinfo.o CC cmd_boot.o CC cmd_bootm.o CC cmd_console.o CC cmd_eeprom.o CC cmd_ext2.o CC cmd_fdc.o CC cmd_fdt.o CC fdt_support.o CC cmd_flash.o CC cmd_i2c.o CC cmd_itest.o CC cmd_load.o CC cmd_mem.o CC cmd_misc.o CC cmd_nand.o CC cmd_net.o CC cmd_nvedit.o CC cmd_onenand.o CC cmd_pci.o CC cmd_pcmcia.o CC cmd_sata.o CC cmd_scsi.o CC cmd_usb.o CC cmd_vfd.o CC command.o CC console.o CC cyclon2.o CC devices.o CC dlmalloc.o CC docecc.o CC environment.o CC env_common.o CC env_nand.o CC env_dataflash.o CC env_flash.o CC env_eeprom.o CC env_onenand.o CC env_nvram.o CC env_nowhere.o CC exports.o CC flash.o CC fpga.o CC ft_build.o CC hush.o CC kgdb.o CC lcd.o CC lists.o CC lynxkdi.o CC memsize.o CC miiphybb.o CC miiphyutil.o CC s_record.o CC serial.o CC soft_i2c.o CC soft_spi.o CC spartan2.o CC spartan3.o CC usb.o CC usb_kbd.o CC usb_storage.o CC virtex2.o CC xilinx.o CC crc16.o CC xyzModem.o CC cmd_mac.o AR libcommon.a SUBDIR libfdt/ CC fdt.o CC fdt_ro.o CC fdt_rw.o CC fdt_strerror.o CC fdt_sw.o CC fdt_wip.o AR libfdt.a FINALLINK u-boot OBJCOPY u-boot.srec OBJCOPY u-boot.bin

On 16:11 Wed 23 Jan , Jon Loeliger wrote:
Folks,
In the spirit of the Linux and Git build systems, I have a modified U-Boot build system that supports a much more concise output! One of the primary motivations for this style of output is that it will very readily highlight build issues and problems as your build progresses. The original, complete build output is obtainable by simply supplying "V=1" on the make invocation in exactly the same way as both Linux and Git do today.
I've not converted all 300 boards to this new scheme yet, but would like your feedback on the approach. I know there are a few rough edges; those are easily smoothed out. I'd like to hear your comments on the overall approach before I spend too much more time on it!
The ambitious amongst you can clone or inspect the repository with these modifications from here:
git://jdl.com/software/u-boot.cfg
Here is a sample build output for the MPC8641HPCN_config.
Enjoy, jdl
% make SUBDIR tools SYMLN environment.c SYMLN crc32.c
I'm actually working on a same function with the kconfig integration, I will sumbit it soon.
Best Regards, J.

Dear Jon,
in message E1JHnoD-0004we-IN@jdl.com you wrote:
In the spirit of the Linux and Git build systems, I have a modified U-Boot build system that supports a much more concise output! One of the primary motivations for this style of output is that it will very readily highlight build issues and problems as your build progresses. The original, complete build output is obtainable by simply supplying "V=1" on the make invocation in exactly the same way as both Linux and Git do today.
Thanks for your efforts. I will not object against adding such changes, but - speaking strictly for myself only - I don't see much of improvement from it. It doesn't help me in my daily work.
Usually I find myself in one of two situations: either I just want to build U-Boot for a board and don't want to see any messages from the build process except error messages - then I use "make -s"; or I'm debugging the make process itself, and I want to see all commands in full detail, then I run plain "make".
Well, to be honest, usually I'm doing none of these. In 95% of all cases I just run "MAKEALL boardname" as this gives me the best of both solutions: a silent build process with only warnings and errors printed, and if something goes wrong and needs further investigation I still have the full build lon in the LOG/ directory, i. e. I don't have to re-run the make.
So my question is: which problem are you trying to solve that is not already solved by "make -s" or "MAKEALL"? I don't really see the need for a solution between no output and full output. YMMV, of course.
Hope I didn't frustrate you - I still appreciate the effort.
Best regards,
Wolfgang Denk

Wolfgang Denk wrote:
So my question is: which problem are you trying to solve that is not already solved by "make -s" or "MAKEALL"? I don't really see the need for a solution between no output and full output. YMMV, of course.
It's nice to have a progress meter of what's currently being compiled, without so much noise that warnings are missed.
-Scott

In message 47990C67.1010104@freescale.com you wrote:
Wolfgang Denk wrote:
So my question is: which problem are you trying to solve that is not already solved by "make -s" or "MAKEALL"? I don't really see the need for a solution between no output and full output. YMMV, of course.
It's nice to have a progress meter of what's currently being compiled, without so much noise that warnings are missed.
Hm... you don't need a progress meter, you need a faster machine ;-)
Best regards,
Wolfgang Denk

Wolfgang Denk wrote:
In message 47990C67.1010104@freescale.com you wrote:
Wolfgang Denk wrote:
So my question is: which problem are you trying to solve that is not already solved by "make -s" or "MAKEALL"? I don't really see the need for a solution between no output and full output. YMMV, of course.
It's nice to have a progress meter of what's currently being compiled, without so much noise that warnings are missed.
Hm... you don't need a progress meter, you need a faster machine ;-)
Either that or Ritalin. :-)
-Scott

On 1/23/08, Wolfgang Denk wd@denx.de wrote:
Dear Jon,
in message E1JHnoD-0004we-IN@jdl.com you wrote:
In the spirit of the Linux and Git build systems, I have a modified U-Boot build system that supports a much more concise output! One of the primary motivations for this style of output is that it will very readily highlight build issues and problems as your build progresses. The original, complete build output is obtainable by simply supplying "V=1" on the make invocation in exactly the same way as both Linux and Git do today.
<snip>
So my question is: which problem are you trying to solve that is not already solved by "make -s" or "MAKEALL"? I don't really see the need for a solution between no output and full output. YMMV, of course.
Hope I didn't frustrate you - I still appreciate the effort.
Hey Jon, Wolfgang;
I think this is a good change myself. The biggest reason is that it makes the default output terse instead of verbose. I'd hazard to wager that most developers don't use 'make -s', MAKEALL, or anything else to trim the output (I certainly don't). By making the default output terse, with errors and warning visually distinct from progress indication, in increases the likelyhood that warnings will actually get seen and fixed (because more people will notice it).
I say make this change.
Cheers, g.

Grant Likely wrote:
On 1/23/08, Wolfgang Denk wd@denx.de wrote:
Dear Jon,
in message E1JHnoD-0004we-IN@jdl.com you wrote:
In the spirit of the Linux and Git build systems, I have a modified U-Boot build system that supports a much more concise output! One of the primary motivations for this style of output is that it will very readily highlight build issues and problems as your build progresses. The original, complete build output is obtainable by simply supplying "V=1" on the make invocation in exactly the same way as both Linux and Git do today.
<snip> > So my question is: which problem are you trying to solve that is not > already solved by "make -s" or "MAKEALL"? I don't really see the need > for a solution between no output and full output. YMMV, of course. > > Hope I didn't frustrate you - I still appreciate the effort.
Hey Jon, Wolfgang;
I think this is a good change myself. The biggest reason is that it makes the default output terse instead of verbose. I'd hazard to wager that most developers don't use 'make -s', MAKEALL, or anything else to trim the output (I certainly don't). By making the default output terse, with errors and warning visually distinct from progress indication, in increases the likelyhood that warnings will actually get seen and fixed (because more people will notice it).
I say make this change.
Cheers, g.
Plus my 2 cents if this is a voting matter.
gvb

On Friday 25 January 2008, gvb.uboot wrote:
I think this is a good change myself. The biggest reason is that it makes the default output terse instead of verbose. I'd hazard to wager that most developers don't use 'make -s', MAKEALL, or anything else to trim the output (I certainly don't). By making the default output terse, with errors and warning visually distinct from progress indication, in increases the likelyhood that warnings will actually get seen and fixed (because more people will notice it).
I say make this change.
Cheers, g.
Plus my 2 cents if this is a voting matter.
Add my 2 cents too. :)
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

Grant Likely wrote:
Hey Jon, Wolfgang;
I think this is a good change myself. The biggest reason is that it makes the default output terse instead of verbose. I'd hazard to wager that most developers don't use 'make -s', MAKEALL, or anything else to trim the output (I certainly don't). By making the default output terse, with errors and warning visually distinct from progress indication, in increases the likelyhood that warnings will actually get seen and fixed (because more people will notice it).
Heh. In fact, if you were all paying really close attention, I submitted a compiler warning cleanup patch in the middle of this effort due to finally _seeing_ it! :-)
I say make this change.
Thanks for the support here! So, OK, I'll continue to fixup the remaining board Makefiles, make it all available, and post the patches here as well!
Thanks, jdl
participants (8)
-
Grant Likely
-
gvb.uboot
-
Jean-Christophe PLAGNIOL-VILLARD
-
Jon Loeliger
-
Jon Loeliger
-
Scott Wood
-
Stefan Roese
-
Wolfgang Denk