Re: [PATCH] Add gnu/packages/u-boot.scm with all the boards that u-boot supports right now

[Danny Milosavljevic]

> This note should go to the top of the .patch file, along with one or two
> sentences explaining what it does and why we need it.

OK, will do that.

> It seems to me that a lot of stuff is Debian-specific and not needed
> (the debian/ directory is definitely not needed.)

I agree. However, I figured it would be better for ... maintenance... if we 
didn't fiddle around with other people's distributed patches.

Mainstream dtc work is kinda... stalled and so lots of people made custom 
patches to make basic functionality work. For example there is no fdtget 
support in the normal device-tree-compiler. Also, the documentation actually 
doesn't build otherwise.

One can search for "patches/" in the patch which yields:
+++ device-tree-compiler-1.4.0+dfsg/debian/patches/01_build_doc.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/02_remove-unused-check-variable.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/03_Remove-unused-variable-in-flat_read_mem_reserve.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/04_Split-out-is_printable_string-into-util.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/05_Add-missing-tests-to-gitignore.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/06_Refactor-character-literal-parsing-code.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/07_Remove-gcc-4.6-set-but-not-used-warnings.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/08_Support-character-literals-in-cell-lists.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/09_Create-Makefile_utils-and-move-ftdump-into-it.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/10_Add-fdt-read_write-utility-functions.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/11_Make-testutils-use-utilfdt.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/12_use-utilfdt-to-read-blob.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/13_Add-fdt16_to_cpu-utility-function.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/14_Add-data_append_integer-function.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/15_Add-support-for-variable-sized-elements.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/16_fdtdump-rename-from-ftdump.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/17_libfdt-Add-support-for-appending-the-values-to-a-exi.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/18_libfdt-Activate-testcase-for-appending-properties.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/19_dtc-Implement-d-option-to-write-out-a-dependency-fil.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/20_Add-fdtget-utility-to-read-property-values-from-a-de.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/21_Add-fdtput-utility-to-write-property-values-to-a-dev.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/22_Introduce-TESTS_BIN-in-Makefiles-to-identify-tested-.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/23-libfdt-Add-missing-functions-to-shared-library.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/24_libfdt-Add-some-missing-symbols-to-version.lds.patch
+++ 
device-tree-compiler-1.4.0+dfsg/debian/patches/local-add-missing-header-706137.patch

Should we carry those? If so, should we split them into extra files and put 
them into our "patches" directory?

> This leads to packages with different names but that are otherwise
> completely identical.  I suppose the configure flags must also be
> changed as a function of the board?

Yeah, something like that. That's what the part below is supposed to do:

+(define u-boot
...
+       #:phases (modify-phases %standard-phases
+                  (replace
+                   'configure
...
+                       (zero? (system* "make" "HOSTCC=gcc" configname))
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It's like in the Linux kernel. One does 

  $ make foobar_defconfig

in order to load the default config.

Then

  $ make

in order to compile. The result is incompatible with other boards.

> In that case, I’d suggest writing a procedure like:
> 
>   (define (make-u-boot-package board)
>     (package
>       (inherit u-boot)
>       (name (string-append "u-boot-" (string-downcase board)))
>       (arguments
>         ;; … pass the right configure flags etc.
>         )))
> 
> Then it’s probably enough to export ‘u-boot’ and ‘make-u-boot’—having a
> zillion variables doesn’t seem very helpful.  People can explicitly call
> ‘make-u-boot’ with the right board name

Yeah, sounds much nicer. 

How do I test this? How can I call it?

Is it also possible to have a function which finds out which defconfig files 
are in the source tarball and tells about them? Maybe have some nice error 
message if someone guesses the wrong board name?

> Could 

Yeah, I will send an updated patch :D