[U-Boot-Users] [PATCH] 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...
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.
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
On Thu, 30 Jun 2005 12:17:44 +0200, Wolfgang Denk writes:
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.
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.
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.
CHANGELOG entry missing, too.
Sorry, I didn't know one was needed.
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@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.
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.
make targets placed in the board specific Makefile can't be called from the top level directory.
Do you reallyneed your own private make targets?
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...
CHANGELOG entry missing, too.
Sorry, I didn't know one was needed.
See the README.
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.
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").
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.
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
On Thu, 30 Jun 2005 15:35:41 +0200, Wolfgang Denk writes:
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.
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?
make targets placed in the board specific Makefile can'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.
Then make sure that an appropriate note about the patch being copyrighted by you and available under GPL is included with your patch.
...
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@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.
In message 9571.1120141144@huldra you wrote:
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
On Thu, 30 Jun 2005 17:11:43 +0200, Wolfgang Denk writes:
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.
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...
participants (2)
-
Murray.Jensen＠csiro.au -
Wolfgang Denk