In message 008f01c6c6f2$1b58fd80$8f4765d5@atmel.com you wrote:
The U-boot Makefile is quite large and growing. I have seen problem where a new patch breaks because another patch has been applied between the checkout of the source dir and the acceptance of the patch. ("avr32" board support breaks on "blackfin")
These are normal merge conflicts, and usually trivial to resolve.
I have support responsibility for about 200 AT91RM9200/SAM9 customers of which a large percentage are totally unexperienced with U-Boot and Linux when they start.
They would not be able to fix the failing patches and the fact that the patches fail will reflect bad on us.
The alternative is to ignore the main U-boot tree (which seems to be the main strategy Atmel is using) and deliver a complete u-boot package. This has the disadvantage that new functionality in the kernel is not available to the customers.
I believe that it is a significant advantage to following the main tree, but it is a 100% requirement for me that patches does not fail.
I don't want to cause trouble for others, but I do need a resolution to the failing patch problem. Is there anyway you can guide me to how this problem can be resolved?
The main function of the proposed patch is to add: "include board/*/board.mk" to the toplevel Makefile right before the mkconfig's start
Rejected. I really want to be able to see everythin in one place and file. This may become a long file, but then you know exactly where to search.
What if I add:
++++++++++++++++ board.mk: board/*/board.mk board/*/*/board.mk echo "Automatically generated file, do not edit" > board.mk cat board/*/board.mk >> board.mk cat board/*/*/board.mk >> board.mk ---- make mrproper should remove the toplevel "board.mk" ------------------------ to the Makefile
Furthermore, the board/*/{*/}board.mk patches should only be accepted if they are simple mkconfigs. Any complex stuff needs to go into the main Makefile (Since you are controlling the patches, you can reject any complex board.mk files)
This results in two files, Makefile and (Toplevel) board.mk so the problem is significantly smaller.
Not so long ago you could run "grep foo Documentation/Configure.help" in the Linux kernel tree to find out what config option "foo" was about. Try this in a current Linux kernel tree with it's zillions of scattered Kconfig files (including all the Kconfig.char, Kconfig.debug, Kconfig.i386, Kconfig.net, Kconfig.scsi, Kconfig.x86_64 and what else variants).
Please don't worry about such merge conflicts in the Makefile - I never complaint about such merge conflicts when adding patches.
This is the first patch I send, if I have made any glaring mistakes, I will try to improve based on feedback.
I reject this patch because it tries to fix a poroblem which does not exist, and instead it makes the code much harder to maintain.
diff -purN u-boot-1.1.4-0rig/board/template/board.mk > u-boot-1.1.4/board/template/board.mk --- u-boot-1.1.4-0rig/board/template/board.mk 1970-01-01 > 01:00:00.000000000 +0100 +++ u-boot-1.1.4/board/template/board.mk 2006-08-23 21:50:30.000000000 > +0200
Why don't you use git?
+include board/*/board.mk
BTW: this approach is broken. It does not handle the case of vendor directories like board/amcc/, board/esd/, etc.
Best regards,
Wolfgang Denk
Please do not send mails or "reply" to ulfs@dof.se, since it will be routed to my GSM phone. My email address is ulf@atmel.com
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
Technical support when I am not available: AT89 C51 Applications Group: mailto:micro.hotline@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net