All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Royds <douglas.royds@tait.co.nz>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH 4/4] Renamed prefix_native, bindir_native, etc using 	hyphens
Date: Fri, 19 Mar 2010 09:48:59 +1300	[thread overview]
Message-ID: <4BA291BB.7040106@tait.co.nz> (raw)
In-Reply-To: <ac9c93b11003180018u761e78f6l67b3f76869a95612@mail.gmail.com>

Frans Meulenbroeks wrote:
> 2010/3/18 Douglas Royds <douglas.royds@tait.co.nz>:
>   
>>   - Avoids clashing with the machine override when MACHINE=native
>>   - bindir_cross similarly renamed for consistency
>>
>>     
> [...]
>   
>>  # Path prefixes
>>  base_prefix = "${STAGING_DIR_NATIVE}"
>> -prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
>> -exec_prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
>> +prefix = "${STAGING_DIR_NATIVE}${prefix-native}"
>> +exec_prefix = "${STAGING_DIR_NATIVE}${prefix-native}"
>>     
>
> [...]
>
> Shouldn't we then for consistent naming also go to exex-prefix etc ?

In the spirit of keeping a single patch for a single purpose, I have not 
modified anything that is not required to fix the problem at hand (um, 
except for bindir_cross). I have only modified the variable names that 
were modified in Richard's commit "Start removal of layout_* variables 
and replace these with new mechanisms to allow nextgen SDK generation 
(from Poky)":

    http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=bea72c2fecde175add169bb55df1922b048030c8

Any renaming of base_prefix, exec_prefix, base_bindir, target_datadir, 
&c is a separate matter. Note that some of these names are imposed on us 
by Autotools convention. This is why these variables are in lower case 
in the first place:

    http://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables

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




  parent reply	other threads:[~2010-03-18 20:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-18  4:56 [PATCH 4/4] Renamed prefix_native, bindir_native, etc using hyphens Douglas Royds
2010-03-18  7:18 ` Frans Meulenbroeks
2010-03-18 10:38   ` Phil Blundell
2010-03-18 20:48   ` Douglas Royds [this message]
2010-03-18 21:13     ` Richard Purdie

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=4BA291BB.7040106@tait.co.nz \
    --to=douglas.royds@tait.co.nz \
    --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.