diff mbox

[05,of,13] cc/gcc: Add CUSTOM version and CUSTOM_LOCATION config options and GetCustom

Message ID f2272ac0f37cedd0bb91.1349931194@localhost.localdomain
State Accepted
Commit 7f5a3382968f
Headers show

Commit Message

David Holsgrove Oct. 11, 2012, 4:53 a.m. UTC
# HG changeset patch
# User David Holsgrove <david.holsgrove@xilinx.com>
# Date 1349930381 -36000
# Node ID f2272ac0f37cedd0bb91346d57681599758ea988
# Parent  50674fe47431174aab80d6c01460aa2d6c901306
cc/gcc: Add CUSTOM version and CUSTOM_LOCATION config options and GetCustom

CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.

Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>


--
For unsubscribe information see http://sourceware.org/lists.html#faq

Comments

Yann E. MORIN Oct. 11, 2012, 8:24 p.m. UTC | #1
David, All,

On Thursday 11 October 2012 06:53:14 David Holsgrove wrote:
> # HG changeset patch
> # User David Holsgrove <david.holsgrove@xilinx.com>
> # Date 1349930381 -36000
> # Node ID f2272ac0f37cedd0bb91346d57681599758ea988
> # Parent  50674fe47431174aab80d6c01460aa2d6c901306
> cc/gcc: Add CUSTOM version and CUSTOM_LOCATION config options and GetCustom
[--SNIP--]
> diff -r 50674fe47431 -r f2272ac0f37c scripts/build/cc/gcc.sh
> --- a/scripts/build/cc/gcc.sh	Thu Oct 11 14:39:40 2012 +1000
> +++ b/scripts/build/cc/gcc.sh	Thu Oct 11 14:39:41 2012 +1000
[--SNIP--]
> @@ -59,7 +61,10 @@
>  
>  # Extract gcc
>  do_cc_extract() {
> -    CT_Extract "gcc-${CT_CC_VERSION}"
> +    if [ "${CT_CC_CUSTOM}" != "y" \
> +         -o ! -d "${CT_SRC_DIR}/gcc-${CT_CC_VERSION}" ]; then
> +        CT_Extract "gcc-${CT_CC_VERSION}"
> +    fi
>      CT_Patch "gcc" "${CT_CC_VERSION}"

That's not how it's done in kernel/linux, where the patching is *not* done
for the custom location.

I have nothing against trying to patch a component's custom location, but
is that really what you wanted?

I'd rather that all components behave the same: either all allow patching
their custom locations, or none does (I'd prefer the latter).

Regards,
Yann E. MORIN.
David Holsgrove Oct. 15, 2012, 1:31 a.m. UTC | #2
Hi Yann, All,

On 12 October 2012 06:24, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> David, All,
>
> On Thursday 11 October 2012 06:53:14 David Holsgrove wrote:
>> # HG changeset patch
>> # User David Holsgrove <david.holsgrove@xilinx.com>
>> # Date 1349930381 -36000
>> # Node ID f2272ac0f37cedd0bb91346d57681599758ea988
>> # Parent  50674fe47431174aab80d6c01460aa2d6c901306
>> cc/gcc: Add CUSTOM version and CUSTOM_LOCATION config options and GetCustom
> [--SNIP--]
>> diff -r 50674fe47431 -r f2272ac0f37c scripts/build/cc/gcc.sh
>> --- a/scripts/build/cc/gcc.sh Thu Oct 11 14:39:40 2012 +1000
>> +++ b/scripts/build/cc/gcc.sh Thu Oct 11 14:39:41 2012 +1000
> [--SNIP--]
>> @@ -59,7 +61,10 @@
>>
>>  # Extract gcc
>>  do_cc_extract() {
>> -    CT_Extract "gcc-${CT_CC_VERSION}"
>> +    if [ "${CT_CC_CUSTOM}" != "y" \
>> +         -o ! -d "${CT_SRC_DIR}/gcc-${CT_CC_VERSION}" ]; then
>> +        CT_Extract "gcc-${CT_CC_VERSION}"
>> +    fi
>>      CT_Patch "gcc" "${CT_CC_VERSION}"
>
> That's not how it's done in kernel/linux, where the patching is *not* done
> for the custom location.
>
> I have nothing against trying to patch a component's custom location, but
> is that really what you wanted?
>
> I'd rather that all components behave the same: either all allow patching
> their custom locations, or none does (I'd prefer the latter).
>

I had considered this, but the way the do_kernel_extract step
currently is setup, it will attempt to patch a linux-custom tarball,
after getting through the check that CT_KERNEL_LINUX_CUSTOM_LOCATION
is not a directory.

Personally, I dont think anyone would want, or reasonably expect, a
custom component to be patched, so I'm happy to skip CT_PATCH for
custom components altogether.

I guess the options are to;

match the kernel:

do_cc_extract() {
    # If *not* custom, or custom tarball only
    if [ "${CT_CC_CUSTOM}" != "y" \
         -o ! -d "${CT_SRC_DIR}/gcc-${CT_CC_VERSION}" ]; then
        CT_Extract "gcc-${CT_CC_VERSION}"
        CT_Patch "gcc" "${CT_CC_VERSION}"
    fi

or avoid CT_PATCH altogether for custom versions:

do_cc_extract() {
    if [ "${CT_CC_CUSTOM}" != "y" \
         -o ! -d "${CT_SRC_DIR}/gcc-${CT_CC_VERSION}" ]; then
        CT_Extract "gcc-${CT_CC_VERSION}"
    fi
    # Only attempt to patch non-custom components
    if [ "${CT_CC_CUSTOM}" != "y" ]; then
        CT_Patch "gcc" "${CT_CC_VERSION}"
    fi

Which would you prefer? Even though CT_PATCH is essentially a nop
unless a 'gcc-custom' directory exists, it would be cleaner to not
attempt the step at all.

Thanks again,
David


> 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.  |
> '------------------------------^-------^------------------^--------------------'
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN Oct. 16, 2012, 8:38 p.m. UTC | #3
David, All,

On Monday 15 October 2012 David Holsgrove wrote:
> On 12 October 2012 06:24, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > I'd rather that all components behave the same: either all allow patching
> > their custom locations, or none does (I'd prefer the latter).
> 
> I had considered this, but the way the do_kernel_extract step
> currently is setup, it will attempt to patch a linux-custom tarball,
> after getting through the check that CT_KERNEL_LINUX_CUSTOM_LOCATION
> is not a directory.

Gah, you are right. The code in kernel/linux is wrong. So, I've changed
the way the Linux kernel does its checks, with the following in mind:

Type                  | Extract | Patch
----------------------+---------+-------
Pre-installed headers |    N    |   N
custom directory      |    N    |   N
custom tarball        |    Y    |   N
mainstream tarball    |    Y    |   Y

> Personally, I dont think anyone would want, or reasonably expect, a
> custom component to be patched, so I'm happy to skip CT_PATCH for
> custom components altogether.

Yes, that's the reasoning.
I see that "custom location" thinggy as "I want to test my devel branch"
of sorts.

I will apply this to the other components:

Type                  | Extract | Patch
----------------------+---------+-------
custom directory      |    N    |   N
custom tarball        |    Y    |   N
mainstream tarball    |    Y    |   Y

Regards,
Yann E. MORIN.
David Holsgrove Oct. 17, 2012, 7:52 a.m. UTC | #4
Hi Yann, All,

On 17 October 2012 06:38, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> David, All,
>
> On Monday 15 October 2012 David Holsgrove wrote:
>> On 12 October 2012 06:24, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>> > I'd rather that all components behave the same: either all allow patching
>> > their custom locations, or none does (I'd prefer the latter).
>>
>> I had considered this, but the way the do_kernel_extract step
>> currently is setup, it will attempt to patch a linux-custom tarball,
>> after getting through the check that CT_KERNEL_LINUX_CUSTOM_LOCATION
>> is not a directory.
>
> Gah, you are right. The code in kernel/linux is wrong. So, I've changed
> the way the Linux kernel does its checks, with the following in mind:
>
> Type                  | Extract | Patch
> ----------------------+---------+-------
> Pre-installed headers |    N    |   N
> custom directory      |    N    |   N
> custom tarball        |    Y    |   N
> mainstream tarball    |    Y    |   Y
>
>> Personally, I dont think anyone would want, or reasonably expect, a
>> custom component to be patched, so I'm happy to skip CT_PATCH for
>> custom components altogether.
>
> Yes, that's the reasoning.
> I see that "custom location" thinggy as "I want to test my devel branch"
> of sorts.
>
> I will apply this to the other components:
>
> Type                  | Extract | Patch
> ----------------------+---------+-------
> custom directory      |    N    |   N
> custom tarball        |    Y    |   N
> mainstream tarball    |    Y    |   Y
>

Yes, I think thats the behaviour we want to see.

I've attached patches to the remaining components which follow this
table. I wasnt able to just return 0 from some of the extract steps,
as we continue on to carry out other tasks unrelated to extract /
patch the component (eg in gcc with the cp of ecj-latest.jar)

I also patched a little bug for the linux kernel with a missing 'then'
in your if statement.

Please let me know what you think?

thanks,
David

> 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.  |
> '------------------------------^-------^------------------^--------------------'
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>
--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN Oct. 29, 2012, 11:27 p.m. UTC | #5
David, All,

Your patch:
    cc/gcc: Add CUSTOM version and CUSTOM_LOCATION config options and GetCustom

has been applied as: #7f5a3382968f
    http://crosstool-ng.org/hg/crosstool-ng/rev/7f5a3382968f

Thank you!

Regards,
Yann E. MORIN.



--
For unsubscribe information see http://sourceware.org/lists.html#faq
diff mbox

Patch

diff -r 50674fe47431 -r f2272ac0f37c config/cc/gcc.in
--- a/config/cc/gcc.in	Thu Oct 11 14:39:40 2012 +1000
+++ b/config/cc/gcc.in	Thu Oct 11 14:39:41 2012 +1000
@@ -239,6 +239,12 @@ 
     prompt "3.4.6 (OBSOLETE)"
     depends on OBSOLETE
 
+config CC_CUSTOM
+    bool
+    prompt "Custom gcc"
+    depends on EXPERIMENTAL
+    select CC_GCC_latest
+
 endchoice
 
 if CC_V_SVN
@@ -297,6 +303,18 @@ 
 
 endif
 
+if CC_CUSTOM
+
+config CC_CUSTOM_LOCATION
+    string
+    prompt "Full path to custom gcc source"
+    default ""
+    help
+      Enter the path to the directory (or tarball) of your source for gcc,
+      or leave blank to use default CT_CUSTOM_LOCATION_ROOT_DIR/gcc
+
+endif #CC_CUSTOM
+
 config CC_GCC_4_2
     bool
     select CC_GCC_4_2_or_later
@@ -484,6 +502,7 @@ 
     default "4.1.2" if CC_V_4_1_2
     default "4.0.4" if CC_V_4_0_4
     default "3.4.6" if CC_V_3_4_6
+    default "custom" if CC_CUSTOM
 
 config CC_LANG_JAVA_USE_ECJ
     bool
diff -r 50674fe47431 -r f2272ac0f37c scripts/build/cc/gcc.sh
--- a/scripts/build/cc/gcc.sh	Thu Oct 11 14:39:40 2012 +1000
+++ b/scripts/build/cc/gcc.sh	Thu Oct 11 14:39:41 2012 +1000
@@ -4,7 +4,9 @@ 
 
 # Download gcc
 do_cc_get() {
-    if [ -n "${CT_CC_V_SVN}" ]; then
+    if [ "${CT_CC_CUSTOM}" = "y" ]; then
+        CT_GetCustom "gcc" "${CT_CC_VERSION}" "${CT_CC_CUSTOM_LOCATION}"
+    elif [ -n "${CT_CC_V_SVN}" ]; then
         # Get gcc from SVN!
         local svn_base
 
@@ -59,7 +61,10 @@ 
 
 # Extract gcc
 do_cc_extract() {
-    CT_Extract "gcc-${CT_CC_VERSION}"
+    if [ "${CT_CC_CUSTOM}" != "y" \
+         -o ! -d "${CT_SRC_DIR}/gcc-${CT_CC_VERSION}" ]; then
+        CT_Extract "gcc-${CT_CC_VERSION}"
+    fi
     CT_Patch "gcc" "${CT_CC_VERSION}"
 
     # Copy ecj-latest.jar to ecj.jar at the top of the GCC source tree