[oe] [PATCH 2/2] Renamed prefix_native, bindir_native, etc using camelCaps
Douglas Royds
douglas.royds at tait.co.nz
Thu Mar 18 20:58:13 UTC 2010
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.
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
Douglas
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
More information about the Openembedded-devel
mailing list