[PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Ross Burton]

If the user accidently tries building u-boot on a machine doesn't use u-boot
(such as qemuarm) the error message doesn't make it clear why u-boot was
skipped.  To help, state the machine that was being built for again.

[ YOCTO #4945 ]

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/recipes-bsp/u-boot/u-boot.inc |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot.inc b/meta/recipes-bsp/u-boot/u-boot.inc
index 6bbe457..6ec63df 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -13,7 +13,7 @@ python () {
 		FILE = os.path.basename(d.getVar("FILE", True))
 		bb.debug(1, "To build %s, see %s for instructions on \
 			     setting up your machine config" % (PN, FILE))
-		raise bb.parse.SkipPackage("because UBOOT_MACHINE is not set")
+		raise bb.parse.SkipPackage("UBOOT_MACHINE is not set in the %s machine configuration." % d.getVar("MACHINE", True))
 }
 
 # Allow setting an additional version string that will be picked up by the
-- 
1.7.10.4

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

Speaking of gerrit terms: I would prefer that you didn't submit this.

I would like it to be more specific. If it cannot be more specific, it
should provide further information to get more specific information. Note,
machine configuration can be the command line as well, so this would still
be vague.

On Thu, Aug 1, 2013 at 11:07 AM, Ross Burton <ross.burton@intel.com> wrote:

> If the user accidently tries building u-boot on a machine doesn't use
> u-boot
> (such as qemuarm) the error message doesn't make it clear why u-boot was
> skipped.  To help, state the machine that was being built for again.
>
> [ YOCTO #4945 ]
>
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
>  meta/recipes-bsp/u-boot/u-boot.inc |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
> b/meta/recipes-bsp/u-boot/u-boot.inc
> index 6bbe457..6ec63df 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -13,7 +13,7 @@ python () {
>                 FILE = os.path.basename(d.getVar("FILE", True))
>                 bb.debug(1, "To build %s, see %s for instructions on \
>                              setting up your machine config" % (PN, FILE))
> -               raise bb.parse.SkipPackage("because UBOOT_MACHINE is not
> set")
> +               raise bb.parse.SkipPackage("UBOOT_MACHINE is not set in
> the %s machine configuration." % d.getVar("MACHINE", True))
>  }
>
>  # Allow setting an additional version string that will be picked up by the
> --
> 1.7.10.4
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2693 bytes --]

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Burton, Ross]

On 1 August 2013 11:50, Laszlo Papp <lpapp@kde.org> wrote:
> Speaking of gerrit terms: I would prefer that you didn't submit this.
>
> I would like it to be more specific. If it cannot be more specific, it
> should provide further information to get more specific information. Note,
> machine configuration can be the command line as well, so this would still
> be vague.

It cannot be more specific without dumping the entire machine
configuration, which won't help because a variable is *not* set.

By "machine configuration can be in the command line" do you mean
MACHINE=foo?  And if so, why does that mean the statement is vague?

Ross

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Burton, Ross]

On 1 August 2013 11:56, Burton, Ross <ross.burton@intel.com> wrote:
> On 1 August 2013 11:50, Laszlo Papp <lpapp@kde.org> wrote:
>> Speaking of gerrit terms: I would prefer that you didn't submit this.
>>
>> I would like it to be more specific. If it cannot be more specific, it
>> should provide further information to get more specific information. Note,
>> machine configuration can be the command line as well, so this would still
>> be vague.
>
> It cannot be more specific without dumping the entire machine
> configuration, which won't help because a variable is *not* set.

Alternatively, let's approach it the other way.  When the user does
"MACHINE=qemux86 bitbake u-boot" what do you think the error message
should be?

Ross

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

On Thu, Aug 1, 2013 at 11:56 AM, Burton, Ross <ross.burton@intel.com> wrote:

> On 1 August 2013 11:50, Laszlo Papp <lpapp@kde.org> wrote:
> > Speaking of gerrit terms: I would prefer that you didn't submit this.
> >
> > I would like it to be more specific. If it cannot be more specific, it
> > should provide further information to get more specific information.
> Note,
> > machine configuration can be the command line as well, so this would
> still
> > be vague.
>
> It cannot be more specific without dumping the entire machine
> configuration, which won't help because a variable is *not* set.
>

No no, it could print out the concrete file to look up, not just a name.
Besides, I would probably even print a warning about the entry point and
load address not set.


> By "machine configuration can be in the command line" do you mean
> MACHINE=foo?  And if so, why does that mean the statement is vague?
>

Well, you could place a warning for instance when it is set to the same as
in the config file. That is probably not what the user intended.

[-- Attachment #2: Type: text/html, Size: 1652 bytes --]

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Burton, Ross]

On 1 August 2013 12:18, Laszlo Papp <lpapp@kde.org> wrote:
>> It cannot be more specific without dumping the entire machine
>> configuration, which won't help because a variable is *not* set.
>
> No no, it could print out the concrete file to look up, not just a name.
> Besides, I would probably even print a warning about the entry point and
> load address not set.

This is a simple "can I even build?" check, and UBOOT_MACHINE is sufficient.

Our users are not totally useless, I think they can find their own
machine configuration files.

>> By "machine configuration can be in the command line" do you mean
>> MACHINE=foo?  And if so, why does that mean the statement is vague?
>
> Well, you could place a warning for instance when it is set to the same as
> in the config file. That is probably not what the user intended.

I'm not sure what you meant here.  Do you mean a situation where the
local.conf says MACHINE=foo and the user also sets MACHINE=foo in the
environment?

Ross

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

On Thu, Aug 1, 2013 at 1:58 PM, Burton, Ross <ross.burton@intel.com> wrote:

> On 1 August 2013 12:18, Laszlo Papp <lpapp@kde.org> wrote:
> >> It cannot be more specific without dumping the entire machine
> >> configuration, which won't help because a variable is *not* set.
> >
> > No no, it could print out the concrete file to look up, not just a name.
> > Besides, I would probably even print a warning about the entry point and
> > load address not set.
>
> This is a simple "can I even build?" check, and UBOOT_MACHINE is
> sufficient.
>
> Our users are not totally useless, I think they can find their own
> machine configuration files.
>

It is not about users being useful or "useless" as you claim. It is about
getting the output I can pass to the editor right away as that would be the
most common action anyway. Why would they need to find on their own when it
can be returned right away? You do not like working more than needed,
surely?


> >> By "machine configuration can be in the command line" do you mean
> >> MACHINE=foo?  And if so, why does that mean the statement is vague?
> >
> > Well, you could place a warning for instance when it is set to the same
> as
> > in the config file. That is probably not what the user intended.
>
> I'm not sure what you meant here.  Do you mean a situation where the
> local.conf says MACHINE=foo and the user also sets MACHINE=foo in the
> environment?
>

Yes.

[-- Attachment #2: Type: text/html, Size: 2124 bytes --]

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Burton, Ross]

On 1 August 2013 17:33, Laszlo Papp <lpapp@kde.org> wrote:
>> I'm not sure what you meant here.  Do you mean a situation where the
>> local.conf says MACHINE=foo and the user also sets MACHINE=foo in the
>> environment?
>
> Yes.

But there's nothing wrong with the user doing that at all.

Ross

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Thu, Aug 1, 2013 at 5:35 PM, Burton, Ross <ross.burton@intel.com> wrote:

> On 1 August 2013 17:33, Laszlo Papp <lpapp@kde.org> wrote:
> >> I'm not sure what you meant here.  Do you mean a situation where the
> >> local.conf says MACHINE=foo and the user also sets MACHINE=foo in the
> >> environment?
> >
> > Yes.
>
> But there's nothing wrong with the user doing that at all.


Why do you think compilers warn in such use cases? Because they cannot know
if you are doing something silly, or something unintentional. It might just
well be that the user wanted to type something else, but got confused in
which case he might get a hard to debug issue later, or even if not hard,
it is additional issue due to his.

[-- Attachment #2: Type: text/html, Size: 1150 bytes --]

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Otavio Salvador]

On Thu, Aug 1, 2013 at 1:38 PM, Laszlo Papp <lpapp@kde.org> wrote:
> On Thu, Aug 1, 2013 at 5:35 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 1 August 2013 17:33, Laszlo Papp <lpapp@kde.org> wrote:
>> >> I'm not sure what you meant here.  Do you mean a situation where the
>> >> local.conf says MACHINE=foo and the user also sets MACHINE=foo in the
>> >> environment?
>> >
>> > Yes.
>>
>> But there's nothing wrong with the user doing that at all.
>
>
> Why do you think compilers warn in such use cases? Because they cannot know
> if you are doing something silly, or something unintentional. It might just
> well be that the user wanted to type something else, but got confused in
> which case he might get a hard to debug issue later, or even if not hard, it
> is additional issue due to his.

Please provide the message you preferred so it can be seen and
discussed. An example might make it easier to get what you really
mean.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

On Thu, Aug 1, 2013 at 5:50 PM, Otavio Salvador <otavio@ossystems.com.br>wrote:

> On Thu, Aug 1, 2013 at 1:38 PM, Laszlo Papp <lpapp@kde.org> wrote:
> > On Thu, Aug 1, 2013 at 5:35 PM, Burton, Ross <ross.burton@intel.com>
> wrote:
> >>
> >> On 1 August 2013 17:33, Laszlo Papp <lpapp@kde.org> wrote:
> >> >> I'm not sure what you meant here.  Do you mean a situation where the
> >> >> local.conf says MACHINE=foo and the user also sets MACHINE=foo in the
> >> >> environment?
> >> >
> >> > Yes.
> >>
> >> But there's nothing wrong with the user doing that at all.
> >
> >
> > Why do you think compilers warn in such use cases? Because they cannot
> know
> > if you are doing something silly, or something unintentional. It might
> just
> > well be that the user wanted to type something else, but got confused in
> > which case he might get a hard to debug issue later, or even if not
> hard, it
> > is additional issue due to his.
>
> Please provide the message you preferred so it can be seen and
> discussed. An example might make it easier to get what you really
> mean.
>

"Warning: "foo", specified manually on the command line, is the same as in
the /path/to/the/relevant/background/file.stuff file"

Please do not hang on the grammar as I am a non-native speakers.

[-- Attachment #2: Type: text/html, Size: 1997 bytes --]

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Paul Eggleton]

On Thursday 01 August 2013 17:52:13 Laszlo Papp wrote:
> On Thu, Aug 1, 2013 at 5:50 PM, Otavio Salvador 
<otavio@ossystems.com.br>wrote:
> > On Thu, Aug 1, 2013 at 1:38 PM, Laszlo Papp <lpapp@kde.org> wrote:
> > > On Thu, Aug 1, 2013 at 5:35 PM, Burton, Ross <ross.burton@intel.com>
> > 
> > wrote:
> > >> On 1 August 2013 17:33, Laszlo Papp <lpapp@kde.org> wrote:
> > >> >> I'm not sure what you meant here.  Do you mean a situation where the
> > >> >> local.conf says MACHINE=foo and the user also sets MACHINE=foo in
> > >> >> the
> > >> >> environment?
> > >> > 
> > >> > Yes.
> > >> 
> > >> But there's nothing wrong with the user doing that at all.
> > > 
> > > Why do you think compilers warn in such use cases? Because they cannot
> > 
> > know
> > 
> > > if you are doing something silly, or something unintentional. It might
> > 
> > just
> > 
> > > well be that the user wanted to type something else, but got confused in
> > > which case he might get a hard to debug issue later, or even if not
> > 
> > hard, it
> > 
> > > is additional issue due to his.
> > 
> > Please provide the message you preferred so it can be seen and
> > discussed. An example might make it easier to get what you really
> > mean.
> 
> "Warning: "foo", specified manually on the command line, is the same as in
> the /path/to/the/relevant/background/file.stuff file"
> 
> Please do not hang on the grammar as I am a non-native speakers.

I'm afraid this is not practical. The ability to specify the value for MACHINE 
and other variables from the external environment is not just there for folks 
running bitbake manually from the command line, but also external scripts as 
well, and they could quite legitimately set it to the same value that has been 
specified in the configuration file and showing a warning in that case would be 
undesirable.

I'm not sure I understand the value of showing this warning in any case. The 
system is not going to do anything that the user won't expect - the user 
specified the value of MACHINE on the command line and that's the value that is 
being used. The fact that it is the same as what's in the configuration file is 
incidental.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]

On Thu, Aug 1, 2013 at 6:02 PM, Paul Eggleton <paul.eggleton@linux.intel.com
> wrote:

> I'm afraid this is not practical. The ability to specify the value for
> MACHINE
> and other variables from the external environment is not just there for
> folks
> running bitbake manually from the command line, but also external scripts
> as
> well, and they could quite legitimately set it to the same value that has
> been
> specified in the configuration file and showing a warning in that case
> would be
> undesirable.
>

Oh yeah, it cannot happen with compiler outputs the same way? Answer is: it
can.

You can add another feature later though if you wish to suppress warnings.
That makes sense to me.


> I'm not sure I understand the value of showing this warning in any case.
> The
> system is not going to do anything that the user won't expect - the user
> specified the value of MACHINE on the command line and that's the value
> that is
> being used. The fact that it is the same as what's in the configuration
> file is
> incidental.
>

Have you used gcc, clang, etc? Do you have experience with warnings in
general? They are there in certain cases because the programmer may have or
probably made a mistake. It is a lot easier to figure out at that time than
debugging very hard later...

Actually, it is even getting more serious in your "script" case where it
would be totally hidden by the script if it is not logging properly, and
you would only realize an issue later.

Surely, we all copy paste wrong on a daily basis, and we also write "foo"
instead "fow" and "bar" at times. So, I do not follow your comment. Nothing
to reinvent the wheel here, just follow the general practice that other
software developers have figured out along the decades.

[-- Attachment #2: Type: text/html, Size: 2589 bytes --]

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Otavio Salvador]

On Thu, Aug 1, 2013 at 2:09 PM, Laszlo Papp <lpapp@kde.org> wrote:
> On Thu, Aug 1, 2013 at 6:02 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
>>
>> I'm afraid this is not practical. The ability to specify the value for
>> MACHINE
>> and other variables from the external environment is not just there for
>> folks
>> running bitbake manually from the command line, but also external scripts
>> as
>> well, and they could quite legitimately set it to the same value that has
>> been
>> specified in the configuration file and showing a warning in that case
>> would be
>> undesirable.
>
>
> Oh yeah, it cannot happen with compiler outputs the same way? Answer is: it
> can.
>
> You can add another feature later though if you wish to suppress warnings.
> That makes sense to me.

It makes sense to not add the warning. Too many warnings just confuse
users and does not provide anything useful as users just ignore them
in the end.

>> I'm not sure I understand the value of showing this warning in any case.
>> The
>> system is not going to do anything that the user won't expect - the user
>> specified the value of MACHINE on the command line and that's the value
>> that is
>> being used. The fact that it is the same as what's in the configuration
>> file is
>> incidental.
>
>
> Have you used gcc, clang, etc? Do you have experience with warnings in
> general? They are there in certain cases because the programmer may have or
> probably made a mistake. It is a lot easier to figure out at that time than
> debugging very hard later...

<sarcarsm>
I am sure we all in Yocto community NEVER used GCC/CLang...
</sarcarsm>

Did you EVER read your own messages? Please do.

> Actually, it is even getting more serious in your "script" case where it
> would be totally hidden by the script if it is not logging properly, and you
> would only realize an issue later.
>
> Surely, we all copy paste wrong on a daily basis, and we also write "foo"
> instead "fow" and "bar" at times. So, I do not follow your comment. Nothing
> to reinvent the wheel here, just follow the general practice that other
> software developers have figured out along the decades.

That's the point; we are folloing Yocto general practice and doing it
different here won't help. Just confuse.

Regards,

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH][V2] u-boot: state the MACHINE when skipping u-boot

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]

On Thu, Aug 1, 2013 at 6:17 PM, Otavio Salvador <otavio@ossystems.com.br>wrote:

> On Thu, Aug 1, 2013 at 2:09 PM, Laszlo Papp <lpapp@kde.org> wrote:
> > On Thu, Aug 1, 2013 at 6:02 PM, Paul Eggleton
> > <paul.eggleton@linux.intel.com> wrote:
> >>
> >> I'm afraid this is not practical. The ability to specify the value for
> >> MACHINE
> >> and other variables from the external environment is not just there for
> >> folks
> >> running bitbake manually from the command line, but also external
> scripts
> >> as
> >> well, and they could quite legitimately set it to the same value that
> has
> >> been
> >> specified in the configuration file and showing a warning in that case
> >> would be
> >> undesirable.
> >
> >
> > Oh yeah, it cannot happen with compiler outputs the same way? Answer is:
> it
> > can.
> >
> > You can add another feature later though if you wish to suppress
> warnings.
> > That makes sense to me.
>
> It makes sense to not add the warning. Too many warnings just confuse
> users and does not provide anything useful as users just ignore them
> in the end.
>

"Too many warnings confuse the users" -> Despite your claim below, you have
not talked much to the gcc/clang and so forth users. You are quite off the
reality in here.

If there are users ignoring warnings for no real reasons, it is their
mistake. That does not mean careful users should be limited by those users.
Such users ignoring the warnings have no harm anyway. They will just ignore
them.

 >> I'm not sure I understand the value of showing this warning in any case.

> >> The
> >> system is not going to do anything that the user won't expect - the user
> >> specified the value of MACHINE on the command line and that's the value
> >> that is
> >> being used. The fact that it is the same as what's in the configuration
> >> file is
> >> incidental.
> >
> >
> > Have you used gcc, clang, etc? Do you have experience with warnings in
> > general? They are there in certain cases because the programmer may have
> or
> > probably made a mistake. It is a lot easier to figure out at that time
> than
> > debugging very hard later...
>
> <sarcarsm>
> I am sure we all in Yocto community NEVER used GCC/CLang...
> </sarcarsm>
>
> Did you EVER read your own messages? Please do.
>

You are quite off here, too. It was questioned about the "warning " usage
of those in this context of course. Please get back on track.

 > Actually, it is even getting more serious in your "script" case where it

> > would be totally hidden by the script if it is not logging properly, and
> you
> > would only realize an issue later.
> >
> > Surely, we all copy paste wrong on a daily basis, and we also write "foo"
> > instead "fow" and "bar" at times. So, I do not follow your comment.
> Nothing
> > to reinvent the wheel here, just follow the general practice that other
> > software developers have figured out along the decades.
>
> That's the point; we are folloing Yocto general practice and doing it
> different here won't help. Just confuse.
>

Actually, I was getting a lot more warning than I expected already, so you
are speaking against the reality. In fact, those warnings I got I could
also suppress. I do not claim they are useless though just because I do not
like them.

[-- Attachment #2: Type: text/html, Size: 4625 bytes --]