sinclude board specific make fragment
PATCH 1/1 sinclude board specific make fragment
This patch "sinclude"s (i.e. it is allowed not to exist) a make fragment from the board specific subdirectory, to allow a port to have board or platform specific targets (which may or may not be added to ALL var - see previous patch). for example - install, or in the case of my 8560 based board, I build a separate file image of the "boot page". Cheers!
Murray...
Signature · 20 lines
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen at csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: BOARD-EX.PAT Type: text/x-patch Size: 549 bytes Desc: board-extras-mk.patch Url : http://lists.denx.de/pipermail/u-boot/attachments/20050630/26ce6633/attachment.bin
PATCH 1/1 sinclude board specific make fragment
Quoted 6 lines · In message <29127.1120109947@gerd> you wrote:
This patch "sinclude"s (i.e. it is allowed not to exist) a make fragment from the board specific subdirectory, to allow a port to have board or platform specific targets (which may or may not be added to ALL var - see previous patch). for example - install, or in the case of my 8560 based board, I build a separate file image of the "boot page". Cheers!
Which problem is this supposed to fix, i. e. why do you need this? I think it is much more straightfoirward to add the neceessary build rules to your board specific Makefile. This also avoids a slow-down of the standard build procedure.
CHANGELOG entry missing, too.
Quoted 3 lines
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on
I'm sorry, but I don't think I can include such stuff into the public source tree anyway.
Best regards,
Wolfgang Denk
Signature · 5 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Ja, mach' nur einen Plan, sei nur ein grosses Licht
und mach' dann noch 'nen zweiten Plan, geh'n tun sie beide nicht."
-- Bert Brecht, DreigroschenoperPATCH 1/1 sinclude board specific make fragment
Quoted 8 lines · Wolfgang Denk
Quoted 5 lines · In message <29127.1120109947@gerd> you wrote:
This patch "sinclude"s (i.e. it is allowed not to exist) a make fragment from the board specific subdirectory, to allow a port to have board or platform specific targets (which may or may not be added to ALL var - see previous patch). for example - install, or in the case of my 8560 based board, I build a separate file image of the "boot page". Cheers!
Which problem is this supposed to fix, i. e. why do you need this?
As I said in the description, this allows board specific make targets such as "install", or other board specific targets that might need to be included in the $(ALL) make variable.
If make targets are placed in the board specific "config.mk", the first such target becomes the default make target, instead of "all", which is declared later in the main Makefile.
Quoted 2 lines
I think it is much more straightfoirward to add the neceessary build rules to your board specific
Makefile.
make targets placed in the board specific Makefile can't be called from the top level directory.
Quoted 2 lines
This also avoids a slow-down
of the standard build procedure.
One stat and a bit of text parsing is hardly going to slow things down much.
Quoted 1 line
CHANGELOG entry missing, too.
Sorry, I didn't know one was needed.
Quoted 6 lines
Quoted 3 lines
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on
I'm sorry, but I don't think I can include such stuff into the public source tree anyway.
Sigh, we have been over this before, many moons ago. I cannot send email publically without including the standard disclaimer required by CSIRO, my employer.
I have been contributing to ppcboot/u-boot for many years now - a lot of my code is already in there. Since u-boot is GPL code, I am obliged to make my changes available, and I choose to do this by posting it to this mailing list.
Whether you accept it into the main u-boot cvs repository or not is irrelevant. As long as people can access the archives of this mailing list, they can access my changes and therefore I have complied with the spirit of the GPL.
In any case, even though I'd hate to think I was defending these stupid email disclaimers, by my reading of it, it only says that the information in the email *may* be "confidential or privileged" - and if so, CSIRO retains all rights to it. Since this is all GPL code, I can't see how the disclaimer applies. Cheers!
Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: Murray.Jensen at csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
PATCH 1/1 sinclude board specific make fragment
Quoted 8 lines · In message <7884.1120136983@huldra> you wrote:
As I said in the description, this allows board specific make targets such as "install", or other board specific targets that might need to be included in the $(ALL) make variable.
If make targets are placed in the board specific "config.mk", the first such target becomes the default make target, instead of "all", which is declared later in the main
Makefile.
This is something I don't like. "config.mk" is intended to hold configration information needd for the make, nothing else. Definitely no make targets or rules or things like that.
Actually the board specific "config.mk" files might be romved one day.
Quoted 2 lines
make targets placed in the board specific
Makefilecan't be called from the top level directory.
Do you reallyneed your own private make targets?
Quoted 1 line
One stat and a bit of text parsing is hardly going to slow things down much.
Not much, but a bit here and a bit there and all for a feature that nearly nobody ever uses...
Quoted 3 lines
Quoted 1 line
CHANGELOG entry missing, too.
Sorry, I didn't know one was needed.
See the README.
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on
I'm sorry, but I don't think I can include such stuff into the public source tree anyway.
Sigh, we have been over this before, many moons ago. I cannot send email publically without including the standard disclaimer required by CSIRO, my employer.
Then make sure that an appropriate note about the patch being copyrighted by you and available under GPL is included with your patch.
Quoted 1 line
Whether you accept it into the main u-boot cvs repository or not is irrelevant.
Indeed. Actually nobody should dare to use your patches given that in their current form they are released in violation of the GPL (by placing unaccetable restrictions on the content: "confidential or privileged ... unauthorised use or disclosure is prohibited").
Quoted 2 lines
As long as people can access the archives of this mailing list, they can access my changes and therefore I have complied with the spirit of the GPL.
They can access the patches, but they cannot use these without
risking of being sued for "unauthorised use" of "privileged"
information.
Quoted 3 lines
disclaimers, by my reading of it, it only says that the information in the email *may* be "confidential or privileged" - and if so, CSIRO retains all rights to it. Since this is all GPL code, I can't see how the disclaimer
And who says that you released your patches under GPL? Your company lawyer might stand ready to sue us all telling us that the "may"
means: yes, this *is* "confidential or privileged".
If you cannot avoid the trailer, then make clear that it does not apply, please.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "The algorithm to do that is extremely nasty. You might want to mug someone with it." - M. Devine, Computer Science 340
PATCH 1/1 sinclude board specific make fragment
Quoted 11 lines · Wolfgang Denk
Quoted 7 lines
As I said in the description, this allows board specific make targets such as "install", or other board specific targets that might need to be included in the $(ALL) make variable.
If make targets are placed in the board specific "config.mk", the first such target becomes the default make target, instead of "all", which is declared later in the main
Makefile.This is something I don't like. "config.mk" is intended to hold configration information needd for the make, nothing else. Definitely no make targets or rules or things like that.
Precisely - that is what I was saying. You cannot include targets or rules in the board specific "config.mk" file.
Quoted 2 lines
Actually the board specific "config.mk" files might be romved one day.
Umm.. this would be very bad. Why would you want to do that?
Quoted 4 lines
Quoted 2 lines
make targets placed in the board specific
Makefilecan't be called from the top level directory.Do you reallyneed your own private make targets?
I gave two examples - "install", and a target for an image of the "boot page" for our MPC8560 board (which I want to be added to the $(ALL) list). I have others, but they are more trivial.
Quoted 3 lines
Then make sure that an appropriate note about the patch being copyrighted by you and available under GPL is included with your patch.
...
Quoted 2 lines
If you cannot avoid the trailer, then make clear that it does not apply, please.
Fair enough. I will do that in future. Cheers!
Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: Murray.Jensen at csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
PATCH 1/1 sinclude board specific make fragment
Quoted 5 lines · In message <9571.1120141144@huldra> you wrote:
Quoted 3 lines
Actually the board specific "config.mk" files might be romved one day.
Umm.. this would be very bad. Why would you want to do that?
Why not? All we use it for is to define TEXT_BASE in a way that "make" can conveniently pick it up. There may be other ways to do the same without needing a separate file for it - logically this information belongs to the board config file.
Best regards,
Wolfgang Denk
Signature · 5 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.
PATCH 1/1 sinclude board specific make fragment
Quoted 9 lines · Wolfgang Denk
Quoted 4 lines
Quoted 2 lines
Actually the board specific "config.mk" files might be romved one day.
Umm.. this would be very bad. Why would you want to do that?
Why not? All we use it for is to define
TEXT_BASEin a way that "make" can conveniently pick it up. There may be other ways to do the same without needing a separate file for it - logically this information belongs to the board config file.
TEXT_BASE is not the only thing being defined in the board specific config.mk file (at least for me) ... other things I do in there are:
1. append to PLATFORM_CPPFLAGS to add a -I options for the compiler;
2. set OBJCFLAGS so I can remove sections from the ELF => BIN copy;
3. set LDSCRIPT based on the board revision;
4. set CROSS_COMPILE based on board revision;
5. add to the ALL variable so other binary images are built, not just the u-boot.bin image - i.e. a binary image of the boot page required for the MPC8560 processor.
I think removing the board specific "config.mk" file would be a serious mistake. Cheers!
Murray...
Signature · 12 lines
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen at csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.