[U-Boot-Users] Makefile suggestion

[Ulf Samuelsson]

> In message <008f01c6c6f2$1b58fd80$8f4765d5 at 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 at dof.se, 
since it will be routed to my GSM phone.
My email address is ulf at atmel.com

Best Regards
Ulf Samuelsson                ulf at 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 at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com
Best AVR  link: www.avrfreaks.net