From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16576 invoked by alias); 29 Jul 2014 20:16:05 -0000 Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org Received: (qmail 16554 invoked by uid 89); 29 Jul 2014 20:16:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qg0-f49.google.com Received: from mail-qg0-f49.google.com (HELO mail-qg0-f49.google.com) (209.85.192.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 29 Jul 2014 20:16:01 +0000 Received: by mail-qg0-f49.google.com with SMTP id j107so254709qga.22 for ; Tue, 29 Jul 2014 13:15:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.137.193 with SMTP id x1mr7751589qat.0.1406664957222; Tue, 29 Jul 2014 13:15:57 -0700 (PDT) Received: by 10.140.20.103 with HTTP; Tue, 29 Jul 2014 13:15:57 -0700 (PDT) In-Reply-To: References: <5b1330e7264a72b0b502.1318994645@crucis> <4E9F7932.8030401@linaro.org> <201110210002.24332.yann.morin.1998@anciens.enib.fr> Date: Tue, 29 Jul 2014 20:16:00 -0000 Message-ID: Subject: Re: [PATCH] scripts: support an empty vendor string From: Bryan Hundven To: "Yann E. MORIN" Cc: crossgcc maillist , Trevor Woerner Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00041.txt.bz2 Yann, Trevor, On Mon, Jul 28, 2014 at 12:47 AM, Bryan Hundven wrote: > Yann, Michael, list Ugh, I sent this to Yann's old email address, and Michael doesn't work for linaro anymore. I now have updated Yann's email address, and added Trevor to the email. > On Thu, Oct 20, 2011 at 3:02 PM, Yann E. MORIN > wrote: >> Michael, Bryan, All, >> >> On Thursday 20 October 2011 03:28:18 Michael Hope wrote: >>> scripts: support an empty vendor string >> >> That will have to wait for after the release. >> >>> diff --git a/config/toolchain.in b/config/toolchain.in >>> index d034315..94755fd 100644 >>> --- a/config/toolchain.in >>> +++ b/config/toolchain.in >>> @@ -111,6 +111,18 @@ >>> >>> Keep the default (unknown) if you don't know better. >>> >>> +config ALLOW_NO_VENDOR >>> + bool >>> + prompt "Allow tuples with no vendor" >>> + default n >>> + help >>> + Set this and set the vendor string to an empty string to allow >>> + tuples with no vendor component such as 'arm-linux-gnueabi' >>> + instead of the default 'arm-unknown-linux-gnueabi'. >>> + >>> + This is a backwards compatibility option for earlier >>> + configurations that used an empty string to mean 'unknown'. >>> + >> >> I'd rather have the other way around: >> >> config PROVIDE_VENDOR_STRING >> bool >> prompt "set 'vendor' part of the tuple" >> default y # Or not, I don't really care >> help >> The 'vendor' part of the tuple is the second word between dashes >> in the tuple. It's mostly informative, except in a very few cases >> where it has meaning (eg. MIPS SDE tuple must have the 'vendor' >> part set to 'sde'). >> >> If you say 'y' here, you'll be able to set the 'vendor' part >> of the tuple in the next option, below. >> If you say 'n', then the 'vendor' part will be omitted in the >> tuple, giving a shortened tuple. >> >> config TARGET_VENDOR >> depends on PROVIDE_VENDOR_STRING >> ... >> >>> config TARGET_ALIAS_SED_EXPR >>> string >>> prompt "Tuple's sed transform" >>> diff --git a/scripts/functions b/scripts/functions >>> index 789b622..2ac4c50 100644 >>> --- a/scripts/functions >>> +++ b/scripts/functions >>> @@ -944,6 +944,20 @@ >>> fi >>> } >>> >>> +# Computes the target tuple from the configuration and the supplied >>> +# vendor string >>> +CT_BuildOneTargetTuple() { >>> + local vendor="${1}" >>> + local target >>> + >>> + target="${CT_TARGET_ARCH}" >>> + target="${target}${vendor:+-${vendor}}" >>> + target="${target}${CT_TARGET_KERNEL:+-${CT_TARGET_KERNEL}}" >>> + target="${target}${CT_TARGET_SYS:+-${CT_TARGET_SYS}}" >>> + >>> + echo "${target}" >>> +} >>> + >>> # Compute the target tuple from what is provided by the user >>> # Usage: CT_DoBuildTargetTuple >>> # In fact this function takes the environment variables to build the >>> target >>> @@ -993,10 +1007,7 @@ >>> CT_DoKernelTupleValues >>> >>> # Finish the target tuple construction >>> - CT_TARGET="${CT_TARGET_ARCH}" >>> - CT_TARGET="${CT_TARGET}${CT_TARGET_VENDOR:+-${CT_TARGET_VENDOR}}" >>> - CT_TARGET="${CT_TARGET}${CT_TARGET_KERNEL:+-${CT_TARGET_KERNEL}}" >>> - CT_TARGET="${CT_TARGET}${CT_TARGET_SYS:+-${CT_TARGET_SYS}}" >>> + CT_TARGET=$(CT_BuildOneTargetTuple "${CT_TARGET_VENDOR}") >>> >>> # Sanity checks >>> __sed_alias="" >>> @@ -1010,8 +1021,15 @@ >>> :*:*:*" "*:) CT_Abort "Don't use spaces in the target sed >>> transform, it breaks things.";; >>> esac >>> >>> - # Canonicalise it >>> - CT_TARGET=$(CT_DoConfigSub "${CT_TARGET}") >>> + if [ "${CT_ALLOW_NO_VENDOR}" = "y" -a -z "${CT_TARGET_VENDOR}" ]; then >>> + # Canonicalise with a fake vendor string then strip it out >>> + local target=$(CT_BuildOneTargetTuple "CT_INVALID") >>> + CT_TARGET=$(CT_DoConfigSub "${target}" |sed -r -s s:CT_INVALID-::) >>> + else >>> + # Canonicalise it >>> + CT_TARGET=$(CT_DoConfigSub "${CT_TARGET}") >>> + fi >>> + >> >> Hmmm. The code does not look nice. I can't say why, it just looks ugly to >> me. I believe there is a better way to do it. At least, the existing code >> deserves a bit of cleanup first... Let's revisit this after the release. >> >> Regards, >> Yann E. MORIN. >> >> -- >> .-----------------.--------------------.------------------.--------------------. >> | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | >> | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | >> | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | >> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | >> '------------------------------^-------^------------------^--------------------' > > Kicking an old horse... > > This one seems to have gotten dropped. Any chance we can revisit this patch? > > -Bryan ^^^ my question persists, now it's just being asked on the right email addresses ;) -Bryan -- For unsubscribe information see http://sourceware.org/lists.html#faq