[Buildroot] [PATCH] toolchain/crosstool-NG: do not depend on the top-level Buildroot's .config

[Buildroot] [PATCH] toolchain/crosstool-NG: do not depend on the top-level Buildroot's .config

[Yann E. MORIN]

Previously, the crosstool-NG backend did depend on the top-level
Buildroot's .config to detect changes in the toolchain options,
using a tentatively-clever heuristic, which also included the full
Buildroot's version string to push down to set the components' versions
strings.

In doing so, any commit in the Buildroot tree would imply a complete
rebuild of the toolchain, even in the case the toolchain options did
not change, thus being a large annoyance (to say the least).

As Buildroot never guaranteed that toolchain options would be detected,
even less handled, and that the internal backend does neither detect nor
act on toolchain options changes, and delegate that to the user, there
is no point in individualising the crosstool-NG backend's behaviour.

So, just drop the not-so-clever heuristic, and just build the toolchain
once, leaving to the user the responsibility to explictly ask Buildroot
to rebuild it.

Reported-by: "Przemyslaw Wrzos" <przemyslaw.wrzos@calyptech.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: "Przemyslaw Wrzos" <przemyslaw.wrzos@calyptech.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 toolchain/toolchain-crosstool-ng/crosstool-ng.mk |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
index 6554982..9d503b0 100644
--- a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
+++ b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
@@ -362,16 +362,13 @@ endef
 $(CTNG_DIR)/.config: | host-crosstool-ng
 
 # Default configuration
-# Depends on top-level .config because it has options we have to shoe-horn
-# into crosstool-NG's .config
 # Only copy the original .config file if we don't have one already.
 # Check that given config file matches selected C library.
 # We need to call oldconfig twice in a row to ensure the options
 # are correctly set ( eg. if an option is new, then the initial sed
 # can't do anything about it ) Ideally, this should go in oldconfig
 # itself, but it's much easier to handle here.
-
-$(CTNG_DIR)/.config: $(CTNG_CONFIG_FILE) $(BUILDROOT_CONFIG)
+$(CTNG_DIR)/.config:
 	$(Q)if [ ! -f $@ ]; then                                                        \
 	        mkdir -p "$(CTNG_DIR)";                                                 \
 	        libc="$$(awk -F '"' '$$1=="CT_LIBC=" { print $$2; }' "$<")";            \
@@ -383,11 +380,8 @@ $(CTNG_DIR)/.config: $(CTNG_CONFIG_FILE) $(BUILDROOT_CONFIG)
 	        fi;                                                                     \
 	        cp -f $< $@;                                                            \
 	    fi
-	$(Q)cp -a $@ $@.timestamp
 	$(call ctng-oldconfig,$@)
 	$(call ctng-oldconfig,$@)
-	$(call ctng-check-config-changed,$@,$@.timestamp)
-	$(Q)rm -f $@.timestamp
 
 # Manual configuration
 ctng-menuconfig: $(CTNG_DIR)/.config
-- 
1.7.2.5

[Buildroot] [PATCH] toolchain/crosstool-NG: do not depend on the top-level Buildroot's .config

[Przemyslaw Wrzos]

Hello Yann,

On Fri, 15 Mar 2013 at 05:44:10, Yann E. MORIN wrote:

> Previously, the crosstool-NG backend did depend on the top-level
> Buildroot's .config to detect changes in the toolchain options, using
a
> tentatively-clever heuristic, which also included the full Buildroot's
> version string to push down to set the components' versions strings.
>
> (...)
>
> -
> -$(CTNG_DIR)/.config: $(CTNG_CONFIG_FILE) $(BUILDROOT_CONFIG)
> +$(CTNG_DIR)/.config:
>  	$(Q)if [ ! -f $@ ]; then
\
>  	        mkdir -p "$(CTNG_DIR)";
\
>  	        libc="$$(awk -F '"' '$$1=="CT_LIBC=" { print $$2; }'
"$<")";            \
> @@ -383,11 +380,8 @@ $(CTNG_DIR)/.config: $(CTNG_CONFIG_FILE)
> $(BUILDROOT_CONFIG)
>  	        fi;

>            \ 	        cp -f $< $@;

>                        \ 	    fi -	$(Q)cp -a $@
$@.timestamp 	$(call
>  ctng-oldconfig,$@) 	$(call ctng-oldconfig,$@)
> -	$(call ctng-check-config-changed,$@,$@.timestamp)
> -	$(Q)rm -f $@.timestamp
> 
>  # Manual configuration
>  ctng-menuconfig: $(CTNG_DIR)/.config

I think you'll need to replace $< with a direct reference to
$(CTNG_CONFIG_FILE) to make that work.

Cheers,
Przemyslaw Wrzos

[Buildroot] [PATCH] toolchain/crosstool-NG: do not depend on the top-level Buildroot's .config

[Yann E. MORIN]

Przemyslaw, All,

On Friday 15 March 2013 Przemyslaw Wrzos wrote:
> On Fri, 15 Mar 2013 at 05:44:10, Yann E. MORIN wrote:
[--SNIP--]
> $@.timestamp 	$(call
> >  ctng-oldconfig,$@) 	$(call ctng-oldconfig,$@)
> > -	$(call ctng-check-config-changed,$@,$@.timestamp)
> > -	$(Q)rm -f $@.timestamp
> > 
> >  # Manual configuration
> >  ctng-menuconfig: $(CTNG_DIR)/.config
> 
> I think you'll need to replace $< with a direct reference to
> $(CTNG_CONFIG_FILE) to make that work.

Indeed. That did not help testing the change with an already-built
toolchain present... :-(

Will resend, thank you!

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] toolchain/crosstool-NG: do not depend on the top-level Buildroot's .config

[Yann E. MORIN]

Previously, the crosstool-NG backend did depend on the top-level
Buildroot's .config to detect changes in the toolchain options,
using a tentatively-clever heuristic, which also included the full
Buildroot's version string to push down to set the components' versions
strings.

In doing so, any commit in the Buildroot tree would imply a complete
rebuild of the toolchain, even in the case the toolchain options did
not change, thus being a large annoyance (to say the least).

As Buildroot never guaranteed that toolchain options would be detected,
even less handled, and that the internal backend does neither detect nor
act on toolchain options changes, and delegate that to the user, there
is no point in individualising the crosstool-NG backend's behaviour.

This reasoning also applies to the depdency on the crosstool-NG's bundled
.config file, too.

So, just drop the not-so-clever heuristic, and just build the toolchain
once, leaving to the user the responsibility to explictly ask Buildroot
to rebuild the toolchain.

Reported-by: "Przemyslaw Wrzos" <przemyslaw.wrzos@calyptech.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: "Przemyslaw Wrzos" <przemyslaw.wrzos@calyptech.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

---
Changes v1 -> v2:
  - properly use $(CTNG_CONFIG_FILE)  (Przemyslaw)
---
 toolchain/toolchain-crosstool-ng/crosstool-ng.mk |   16 ++++++----------
 1 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
index 6554982..59f18c7 100644
--- a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
+++ b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
@@ -362,32 +362,28 @@ endef
 $(CTNG_DIR)/.config: | host-crosstool-ng
 
 # Default configuration
-# Depends on top-level .config because it has options we have to shoe-horn
-# into crosstool-NG's .config
 # Only copy the original .config file if we don't have one already.
 # Check that given config file matches selected C library.
 # We need to call oldconfig twice in a row to ensure the options
 # are correctly set ( eg. if an option is new, then the initial sed
 # can't do anything about it ) Ideally, this should go in oldconfig
 # itself, but it's much easier to handle here.
-
-$(CTNG_DIR)/.config: $(CTNG_CONFIG_FILE) $(BUILDROOT_CONFIG)
+$(CTNG_DIR)/.config:
 	$(Q)if [ ! -f $@ ]; then                                                        \
 	        mkdir -p "$(CTNG_DIR)";                                                 \
-	        libc="$$(awk -F '"' '$$1=="CT_LIBC=" { print $$2; }' "$<")";            \
+	        libc="$$(awk -F '"' '$$1=="CT_LIBC=" { print $$2; }'                    \
+	                        "$(CTNG_CONFIG_FILE)"                                   \
+	                )";                                                             \
 	        if [ "$${libc}" != "$(BR2_TOOLCHAIN_CTNG_LIBC)" ]; then                 \
-	            echo "* Inconsistency in crosstool-NG config file '$<'";            \
+	            echo "* Inconsistency in crosstool-NG config file '$(CTNG_CONFIG_FILE)'"; \
 	            echo "* - buildroot configured for '$(BR2_TOOLCHAIN_CTNG_LIBC)'";   \
 	            echo "* - given config file for '$${libc}'";                        \
 	            exit 1;                                                             \
 	        fi;                                                                     \
-	        cp -f $< $@;                                                            \
+	        cp -f $(CTNG_CONFIG_FILE) $@;                                                            \
 	    fi
-	$(Q)cp -a $@ $@.timestamp
 	$(call ctng-oldconfig,$@)
 	$(call ctng-oldconfig,$@)
-	$(call ctng-check-config-changed,$@,$@.timestamp)
-	$(Q)rm -f $@.timestamp
 
 # Manual configuration
 ctng-menuconfig: $(CTNG_DIR)/.config
-- 
1.7.2.5

[Buildroot] [PATCH] toolchain/crosstool-NG: do not depend on the top-level Buildroot's .config

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 Yann> Previously, the crosstool-NG backend did depend on the top-level
 Yann> Buildroot's .config to detect changes in the toolchain options,
 Yann> using a tentatively-clever heuristic, which also included the full
 Yann> Buildroot's version string to push down to set the components' versions
 Yann> strings.

 Yann> In doing so, any commit in the Buildroot tree would imply a complete
 Yann> rebuild of the toolchain, even in the case the toolchain options did
 Yann> not change, thus being a large annoyance (to say the least).

 Yann> As Buildroot never guaranteed that toolchain options would be detected,
 Yann> even less handled, and that the internal backend does neither detect nor
 Yann> act on toolchain options changes, and delegate that to the user, there
 Yann> is no point in individualising the crosstool-NG backend's behaviour.

 Yann> This reasoning also applies to the depdency on the crosstool-NG's bundled
 Yann> .config file, too.

 Yann> So, just drop the not-so-clever heuristic, and just build the toolchain
 Yann> once, leaving to the user the responsibility to explictly ask Buildroot
 Yann> to rebuild the toolchain.

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] toolchain/crosstool-NG: do not depend on the top-level Buildroot's .config

[Jérôme Pouiller]

Hello Yann,

On Monday 18 March 2013 23:03:03 Yann E. MORIN wrote:
> Previously, the crosstool-NG backend did depend on the top-level
> Buildroot's .config to detect changes in the toolchain options,
> using a tentatively-clever heuristic, which also included the full
> Buildroot's version string to push down to set the components' versions
> strings.
> 
> In doing so, any commit in the Buildroot tree would imply a complete
> rebuild of the toolchain, even in the case the toolchain options did
> not change, thus being a large annoyance (to say the least).
> 
> As Buildroot never guaranteed that toolchain options would be detected,
> even less handled, and that the internal backend does neither detect nor
> act on toolchain options changes, and delegate that to the user, there
> is no point in individualising the crosstool-NG backend's behaviour.
> 
> This reasoning also applies to the depdency on the crosstool-NG's bundled
> .config file, too.
> 
> So, just drop the not-so-clever heuristic, and just build the toolchain
> once, leaving to the user the responsibility to explictly ask Buildroot
> to rebuild the toolchain.
Hmmm... I didn't followed all debate, and I am sorry if this suggestion has 
already been submitted but, why not depend on 
build/buildroot-config/br2/toolchain/ctng* ?

BR,

-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr

[Buildroot] [PATCH] toolchain/crosstool-NG: do not depend on the top-level Buildroot's .config

[Thomas Petazzoni]

Dear J?r?me Pouiller,

On Thu, 09 May 2013 00:32:43 +0200, J?r?me Pouiller wrote:

> > So, just drop the not-so-clever heuristic, and just build the toolchain
> > once, leaving to the user the responsibility to explictly ask Buildroot
> > to rebuild the toolchain.
> Hmmm... I didn't followed all debate, and I am sorry if this suggestion has 
> already been submitted but, why not depend on 
> build/buildroot-config/br2/toolchain/ctng* ?

There's a choice:

 1) Either we do detect changes in the configuration and automatically
    rebuild what needs to be rebuild. But if we decide to do that, we
    must do it *perfectly*. If we tell users "you can make changes in
    your configuration, run 'make' and it will automatically rebuild
    what's necessary", it should work perfectly, and not have some
    bizarre cases where it doesn't rebuild what's needed.

 2) Or we don't even try to detect changes, even in simple cases. This
    keeps Buildroot simple and we have a simple thing to explain to our
    users: "Buildroot doesn't try to detect which configuration changes
    you made, it's up to you to rebuild what's necessary, or restart a
    full build".

Until now, all the Buildroot developers agreed that (2) was the way to
go. (1) is complicated to achieve correctly, and would add a
significant complexity to Buildroot, which is something we absolutely
want to avoid.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com