Re: [U-Boot-Users] Makefile suggestion

Dear Ulf,

in message 007b01c6c752$c068d7e0$654765d5@atmel.com you wrote:

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.

Then you should not distribute poatches to these people in the first place.

I believe that it is a significant advantage to following the main tree,

Agreed.

but it is a 100% requirement for me that patches does not fail.

I guess you'd win some big prioce if you could find a method that would allow this. All the source code management systems are dealing with this problem, and no perfect solution exists yet. You can automatically merge so many patches, but no system is perfect.

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?

I think you will have to accept the fact that no such solution exists.

Using git will make it easier for you to deal with such problems, but you will have to have knowledge about the tools and what's going on. This is nothing that your "totally unexperienced" users will ever be able to do.

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

I will reject this. Using wildcards in such a place is bad.

Furthermore, the board/*/{*/}board.mk patches should only be accepted if they are simple mkconfigs.

If this is the case, then it's easier to keep this in the Makefile.

            Any complex stuff needs to go into the main Makefile
            (Since  you are controlling the patches, you can reject

any complex board.mk files)

Actually it's the complex stuff which bloats the Makefile.

This results in two files, Makefile and (Toplevel) board.mk so the problem is significantly smaller.

Not really, I think.

Best regards,

Wolfgang Denk