[Buildroot] Crosstool-NG unnecessary rebuilds [BUG]

[Buildroot] Crosstool-NG unnecessary rebuilds [BUG]

[Przemyslaw Wrzos]

Hi,

I'm finding that when using Crosstool-NG, the toolchain often seems to
rebuild unnecessarily.

The condition seems to trigger if any change is made to the main
buildroot configuration file (even though the change is unrelated to the
toolchain) and a new git commit is made (or uncommitted changes are
introduced into the build tree). As far as I can tell this is caused by
one of the CTNG_FIX_BUILDROOT_CONFIG_SED rules used to modify the
crosstool-NG configuration (found in
toolchain/toolchain-crosstool-ng/crosstool-ng.mk).

The rule is:
    CTNG_FIX_BUILDROOT_CONFIG_SED +=
s:^(CT_TOOLCHAIN_PKGVERSION)="(.*)":\1="buildroot $(BR2_VERSION_FULL)":;

The problem is its dependence on BR2_VERSION_FULL which changes every
time a git commit is made.

I'm not sure what the best way to tackle this is. Perhaps allowing the
user to specify a fixed TOOLCHAIN_PKGVERSION in the ctng-menuconfig, the
above rule would then become something like:
        CTNG_FIX_BUILDROOT_CONFIG_SED +=
s:^(CT_TOOLCHAIN_PKGVERSION)="(\s*)":\1="buildroot
$(BR2_VERSION_FULL)":;

Otherwise we could use BR2_VERSION instead. This would still trigger an
unnecessary rebuild every time the buildroot version is bumped but that
would happen a lot less often.

Any suggestions on the best way to tackle this issue?

Regards,
Przemyslaw Wrzos

[Buildroot] Crosstool-NG unnecessary rebuilds [BUG]

[Thomas Petazzoni]

Dear Przemyslaw Wrzos,

On Wed, 13 Mar 2013 14:14:17 +1100, Przemyslaw Wrzos wrote:

> I'm finding that when using Crosstool-NG, the toolchain often seems to
> rebuild unnecessarily.
> 
> The condition seems to trigger if any change is made to the main
> buildroot configuration file (even though the change is unrelated to the
> toolchain) and a new git commit is made (or uncommitted changes are
> introduced into the build tree). As far as I can tell this is caused by
> one of the CTNG_FIX_BUILDROOT_CONFIG_SED rules used to modify the
> crosstool-NG configuration (found in
> toolchain/toolchain-crosstool-ng/crosstool-ng.mk).
> 
> The rule is:
>     CTNG_FIX_BUILDROOT_CONFIG_SED +=
> s:^(CT_TOOLCHAIN_PKGVERSION)="(.*)":\1="buildroot $(BR2_VERSION_FULL)":;
> 
> The problem is its dependence on BR2_VERSION_FULL which changes every
> time a git commit is made.
> 
> I'm not sure what the best way to tackle this is. Perhaps allowing the
> user to specify a fixed TOOLCHAIN_PKGVERSION in the ctng-menuconfig, the
> above rule would then become something like:
>         CTNG_FIX_BUILDROOT_CONFIG_SED +=
> s:^(CT_TOOLCHAIN_PKGVERSION)="(\s*)":\1="buildroot
> $(BR2_VERSION_FULL)":;
> 
> Otherwise we could use BR2_VERSION instead. This would still trigger an
> unnecessary rebuild every time the buildroot version is bumped but that
> would happen a lot less often.
> 
> Any suggestions on the best way to tackle this issue?

Isn't this caused by the following dependency

$(CTNG_DIR)/.config: $(CTNG_CONFIG_FILE) $(BUILDROOT_CONFIG)

I don't think we should depend on the Buildroot configuration here. It
tries to be too smart by triggering the rebuild of the toolchain
whenever the Buildroot configuration has changed, but this isn't
normally done in Buildroot, so I'd say this dependency on
$(BUILDROOT_CONFIG) shouldn't be there. Cc'ing Yann on this one.

Best regards,

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

[Buildroot] Crosstool-NG unnecessary rebuilds [BUG]

[Przemyslaw Wrzos]

Hello Thomas,

On Wed, 13 Mar 2013 at 18:37:25, Thomas Petazzoni wrote:

> Dear Przemyslaw Wrzos,
> 
> On Wed, 13 Mar 2013 14:14:17 +1100, Przemyslaw Wrzos wrote:
> 
>> I'm finding that when using Crosstool-NG, the toolchain often seems
to
>> rebuild unnecessarily.
> 
> Isn't this caused by the following dependency
> 
> $(CTNG_DIR)/.config: $(CTNG_CONFIG_FILE) $(BUILDROOT_CONFIG)
> 
> I don't think we should depend on the Buildroot configuration here. It
> tries to be too smart by triggering the rebuild of the toolchain
> whenever the Buildroot configuration has changed, but this isn't
> normally done in Buildroot, so I'd say this dependency on
> $(BUILDROOT_CONFIG) shouldn't be there. Cc'ing Yann on this one.
> 
> Best regards,
> 
> Thomas

Yes, removing that dependency should also resolve this issue.

Cheers,
Przemyslaw Wrzos

[Buildroot] Crosstool-NG unnecessary rebuilds [BUG]

[Yann E. MORIN]

Przemyslaw, Thomas, All,

On Wednesday 13 March 2013 Thomas Petazzoni wrote:
> On Wed, 13 Mar 2013 14:14:17 +1100, Przemyslaw Wrzos wrote:
> > I'm finding that when using Crosstool-NG, the toolchain often seems to
> > rebuild unnecessarily.
[--SNIP--]
> Isn't this caused by the following dependency
> $(CTNG_DIR)/.config: $(CTNG_CONFIG_FILE) $(BUILDROOT_CONFIG)

Yes, and this dependency is here on purpose: we can't configure the
crosstool-NG backend until we first have the Buildroot config.

> I don't think we should depend on the Buildroot configuration here. It
> tries to be too smart by triggering the rebuild of the toolchain
> whenever the Buildroot configuration has changed, but this isn't
> normally done in Buildroot, so I'd say this dependency on
> $(BUILDROOT_CONFIG) shouldn't be there. Cc'ing Yann on this one.

Well, the .config file should not change if the toolchain options in
Buildroot have not changed.

That's the purpose of the .timestamp trick: if the .config did change,
then we leave the new .config, and that will kick in the rebuild of the
toolchain. OTOH, if the .config did not change, then we restore the
previous .config, and as the date of the .config has not changed, the
dependency is fulfilled, and the toolchain would not be re-built.

This *is* needed to catch tolchain changes. Admitedly, the internal backend
does not do that, but I think it is better to do it rather than not.

I have just checked that, and indeed, if I just change package options
without touching toolchain-related features, the toolchain is not rebuilt.

Now, getting the Buildroot version in the crostool-NG backend is arguably
usefull, especially if using (as is currently the case) the complete
version string. I personally find it useful, but I agree this can be seen
as an annoyance (note: I am not impacted, because I usually build the
toolchain directly with ct-ng, and use that as an external toolchain).

Maybe we can switch to using the short Buildroot version string, which
does not include the git cset in it. I'll propose a patch to this effect
shortly.

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] Crosstool-NG unnecessary rebuilds [BUG]

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Wed, 13 Mar 2013 19:10:06 +0100, Yann E. MORIN wrote:

> > Isn't this caused by the following dependency
> > $(CTNG_DIR)/.config: $(CTNG_CONFIG_FILE) $(BUILDROOT_CONFIG)
> 
> Yes, and this dependency is here on purpose: we can't configure the
> crosstool-NG backend until we first have the Buildroot config.

Hum there are many other places in Buildroot that can't be done until
we have the Buildroot config and still we don't have this Buildroot
configuration dependency. I think this dependency is useless because of
the big:

ifeq ($(BR2_HAVE_DOT_CONFIG),y)
[... do all the normal build stuff... ]
endif

that we have in the main Makefile.

> > I don't think we should depend on the Buildroot configuration here. It
> > tries to be too smart by triggering the rebuild of the toolchain
> > whenever the Buildroot configuration has changed, but this isn't
> > normally done in Buildroot, so I'd say this dependency on
> > $(BUILDROOT_CONFIG) shouldn't be there. Cc'ing Yann on this one.
> 
> Well, the .config file should not change if the toolchain options in
> Buildroot have not changed.

Which .config, crosstool-ng one, or Buildroot one?

> That's the purpose of the .timestamp trick: if the .config did change,
> then we leave the new .config, and that will kick in the rebuild of the
> toolchain. OTOH, if the .config did not change, then we restore the
> previous .config, and as the date of the .config has not changed, the
> dependency is fulfilled, and the toolchain would not be re-built.
> 
> This *is* needed to catch tolchain changes. Admitedly, the internal backend
> does not do that, but I think it is better to do it rather than not.

I'm not sure to agree here. The Buildroot policy is: we don't even try
to rebuild whatever would be needed when there are configuration
changes. For example, when there is a change of toolchain
configuration, you will with your code maybe rebuild the toolchain, but
not the entire userspace.

So either we do it completely, and correctly, or we don't do it. And as
far I as remember, the Buildroot project position on this has always
been: it is too complex to achieve entirely correctly, so we just don't
do it.

> Maybe we can switch to using the short Buildroot version string, which
> does not include the git cset in it. I'll propose a patch to this effect
> shortly.

I think the real fix is to just comply with the Buildroot principle of
not trying to magically adapt to configuration changes.

Best regards,

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

[Buildroot] Crosstool-NG unnecessary rebuilds [BUG]

[Yann E. MORIN]

Thomas, All,

On Thursday 14 March 2013 Thomas Petazzoni wrote:
> On Wed, 13 Mar 2013 19:10:06 +0100, Yann E. MORIN wrote:
> > > Isn't this caused by the following dependency
> > > $(CTNG_DIR)/.config: $(CTNG_CONFIG_FILE) $(BUILDROOT_CONFIG)
> > 
> > Yes, and this dependency is here on purpose: we can't configure the
> > crosstool-NG backend until we first have the Buildroot config.
> 
> Hum there are many other places in Buildroot that can't be done until
> we have the Buildroot config and still we don't have this Buildroot
> configuration dependency. I think this dependency is useless because of
> the big:
> 
> ifeq ($(BR2_HAVE_DOT_CONFIG),y)
> [... do all the normal build stuff... ]
> endif
> 
> that we have in the main Makefile.

Indeed, if we do not want to catch toolchain options changes, then the
dependency is superfluous.

> > > I don't think we should depend on the Buildroot configuration here. It
> > > tries to be too smart by triggering the rebuild of the toolchain
> > > whenever the Buildroot configuration has changed, but this isn't
> > > normally done in Buildroot, so I'd say this dependency on
> > > $(BUILDROOT_CONFIG) shouldn't be there. Cc'ing Yann on this one.
> > 
> > Well, the .config file should not change if the toolchain options in
> > Buildroot have not changed.
> 
> Which .config, crosstool-ng one, or Buildroot one?

Let me repjrase this:
    The crosstool-NG's .config should not change if the toolchain
    options in the Buildroot's .config did not change.

[--SNIP discussion about catching changes in toolchain options--]
> > Maybe we can switch to using the short Buildroot version string, which
> > does not include the git cset in it. I'll propose a patch to this effect
> > shortly.
> 
> I think the real fix is to just comply with the Buildroot principle of
> not trying to magically adapt to configuration changes.

I am not a fan, but I agree: let's adhere to the overall philosophy.

I will rework the patch to get rid of the changes-catching heuristic.

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] Crosstool-NG unnecessary rebuilds [BUG]

[Przemyslaw Wrzos]

Hello Thomas,

On Thu, 14 Mar 2013 at 18:48:16, Thomas Petazzoni wrote:

> I'm not sure to agree here. The Buildroot policy is: we don't even try
> to rebuild whatever would be needed when there are configuration
> changes. For example, when there is a change of toolchain
> configuration, you will with your code maybe rebuild the toolchain,
but
> not the entire userspace.
> 
> So either we do it completely, and correctly, or we don't do it. And
as
> far I as remember, the Buildroot project position on this has always
> been: it is too complex to achieve entirely correctly, so we just
don't
> do it.

So just a question about the effect of that. If we remove that
dependency then won't this be inconsistent with how the internal
buildroot toolchain build works? Or does it not matter because the
internal toolchain is going to be deprecated eventually anyway.

Cheers,
Przemyslaw Wrzos

[Buildroot] Crosstool-NG unnecessary rebuilds [BUG]

[Thomas Petazzoni]

Dear Przemyslaw Wrzos,

On Fri, 15 Mar 2013 11:18:44 +1100, Przemyslaw Wrzos wrote:

> So just a question about the effect of that. If we remove that
> dependency then won't this be inconsistent with how the internal
> buildroot toolchain build works?

Nothing in Buildroot tries to get rebuilt automatically when there are
configuration changes. This has been the Buildroot policy for a long
time, and only the Crosstool-NG backend was moving away from this
general policy.

If you make a change in the Buildroot configuration, it's up to you to
understand the consequences of the change, and take the appropriate
actions (a complete "make clean all" in some situations, remove some
stuff in other situations, etc.).

> Or does it not matter because the
> internal toolchain is going to be deprecated eventually anyway.

From the discussions of the last Buildroot Developers Meeting, it is
really not clear whether the internal toolchain backend will be
deprecated one day. There are still some integration problems in the
Crosstool-NG backend (download infrastructure, license infrastructure)
that are not easy to handle.

See http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013 (search for
"Switching to ct-ng as the default toolchain backend has been in the
plans for several years").

Best regards,

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

[Buildroot] Crosstool-NG unnecessary rebuilds [BUG]

[Przemyslaw Wrzos]

Hello Thomas,

On Fri, 15 Mar 2013 at 19:25:25, Thomas Petazzoni wrote:

> Nothing in Buildroot tries to get rebuilt automatically when there are
> configuration changes. This has been the Buildroot policy for a long
> time, and only the Crosstool-NG backend was moving away from this
> general policy.

I understand that's the idea, however, as it is now the internal
buildroot toolchain will attempt to rebuild uClibc if the uClibc
configuration file changes. I'm assuming it is via the following
dependency chain (found in toolchain/uClibc/uclibc.mk"):

    $(UCLIBC_DIR)/.oldconfig: $(UCLIBC_DIR)/.patched
$(UCLIBC_CONFIG_FILE)
    $(UCLIBC_DIR)/.config: $(UCLIBC_DIR)/.oldconfig
    $(UCLIBC_DIR)/.configured: $(LINUX_HEADERS_DIR)/.configured
$(UCLIBC_DIR)/.config
    $(UCLIBC_DIR)/lib/libc.a: $(UCLIBC_DIR)/.configured
$(gcc_intermediate) $(LIBFLOAT_TARGET)

> See http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013 (search for
> "Switching to ct-ng as the default toolchain backend has been in the
> plans for several years").

Thanks that's quite useful.

Cheers,
Przemyslaw Wrzos