All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH 2/2] Renamed prefix_native, bindir_native, etc using camelCaps
Date: Thu, 18 Mar 2010 21:19:28 +0000	[thread overview]
Message-ID: <1268947168.8697.77.camel@rex> (raw)
In-Reply-To: <4BA293E5.9030705@tait.co.nz>

On Fri, 2010-03-19 at 09:58 +1300, Douglas Royds wrote:
> Richard Purdie wrote:
> > On Thu, 2010-03-18 at 04:37 +0100, Holger Hans Peter Freyther wrote:
> >   
> >> On Thursday 18 March 2010 02:31:11 Douglas Royds wrote:
> >>     
> >>>     - Avoids clashing with the machine override when MACHINE=native
> >>>     - bindir_cross similarly renamed for consistency
> >>>       
> >> Thank you for that much work. I think we established the usage of '-' instead 
> >> of '_' to avoid clashes with the override detection though.
> >>     
> >
> > I just noticed this problem. It makes me very very nervous to introduce
> > yet another variable naming convention, particularly one we don't use
> > anywhere else :/.
> >
> > Might it be simpler to rename the native machine? Using "native" in the
> > override namespace is asking for trouble :(.
> 
> I have no objection to renaming the native machine, but I think we 
> should also ensure that we never use _thing variable names (in lower 
> case). We have a weak distinction between overrides and underscored 
> variable names. By convention, BitBake variables are entirely in 
> uppercase, and overrides in lower case, but this convention fails when 
> the variable names are externally imposed (by the Autotools), 
> exec_prefix being a case in point.
> 
> I propose that we rename prefix_native and friends to avoid any risk of 
> clashing with the overrides.

I think the better way to fix this long term is to change the override
character in bitbake itself. We've been around in circles on this issue
and its the only sane way as _ does make a logical separator in variable
names, rightly or wrongly.

> Separately, if we wish, we can rename the native machine. I suggest 
> "buildhost". This would also help to clarify that the following two 
> builds have quite different intentions, though the result is similar:
> 
>     bitbake thing-native
>     MACHINE=native bitbake thing

Agreed.

Cheers,

Richard




      reply	other threads:[~2010-03-18 21:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-18  1:31 [PATCH 2/2] Renamed prefix_native, bindir_native, etc using camelCaps Douglas Royds
2010-03-18  3:37 ` Holger Hans Peter Freyther
2010-03-18 17:29   ` Richard Purdie
2010-03-18 17:49     ` Koen Kooi
2010-03-18 19:42       ` Richard Purdie
2010-03-18 19:55         ` Khem Raj
2010-03-18 20:58     ` Douglas Royds
2010-03-18 21:19       ` Richard Purdie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1268947168.8697.77.camel@rex \
    --to=rpurdie@rpsys.net \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.