[U-Boot-Users] [PATCH] sinclude board specific make fragment

[U-Boot-Users] [PATCH] sinclude board specific make fragment

[Murray.Jensen at csiro.au]

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...
-- 
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 

[U-Boot-Users] [PATCH] sinclude board specific make fragment

[Wolfgang Denk]

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

-- 
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, Dreigroschenoper

[U-Boot-Users] [PATCH] sinclude board specific make fragment

[Murray.Jensen at csiro.au]

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 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.

[U-Boot-Users] [PATCH] sinclude board specific make fragment

[Wolfgang Denk]

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

-- 
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

[U-Boot-Users] [PATCH] sinclude board specific make fragment

[Murray.Jensen at csiro.au]

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 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.

[U-Boot-Users] [PATCH] sinclude board specific make fragment

[Wolfgang Denk]

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

-- 
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.

[U-Boot-Users] [PATCH] sinclude board specific make fragment

[Murray.Jensen at csiro.au]

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...
-- 
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.