Crosstool-ng always starts from the top

Crosstool-ng always starts from the top

[Stuart Longland]

Hi all,
	Is there a way to convince crosstool-ng to pick up where it left off? 
I've got a situation where some misconfigured options caused crosstool 
to fail to build gcc (arm-cortex-eabi target; GCC was to be configured 
using --with-cpu=cortex-m3 -- this fails because the "CPU does not 
support ARM mode").

	The upshot is that I have to run `ct-ng menuconfig` again, and tweak 
the options for gcc and run it again.  This is fine, but when I run 
`ct-ng build`, it starts right from scratch again building GMP, MPFR, 
PPL, Cloog and binutils... which all should be identical to before, and 
shouldn't need rebuilding.

	Is there a reason why the builder can't just assume (or be convinced to 
assume) those components are already built and resume at the last 
component where the failure occurred?

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
   ...it's backed up on a tape somewhere.

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

Re: Crosstool-ng always starts from the top

[Yann E. MORIN]

Stuart, All,

On Wednesday 31 March 2010 00:52:00 Stuart Longland wrote:
> Is there a way to convince crosstool-ng to pick up where it left off? 

This is a limitation: crosstool-NG was not designed to be restartable.

However, it appeared that debugging crosstool-NG itself was cumbersome
when a single script was modified, so a /kind of/ stop-and-restart
feature was added, that works _iff_ the configuration has not changed.

That way, I was able to try to patch gcc or it's build script and restart
again without loosing too much time.

To sum-up:
 - no, it's not possible to restart where it left off, if the
   configuration has changed
 - yes you can stop-and-restart at any place iff the configuration
   has *not* changed.

> The upshot is that I have to run `ct-ng menuconfig` again, and tweak 
> the options for gcc and run it again.  This is fine, but when I run 
> `ct-ng build`, it starts right from scratch again building GMP, MPFR, 
> PPL, Cloog and binutils... which all should be identical to before, and 
> shouldn't need rebuilding.

That's right from a theorical point of view. 

> Is there a reason why the builder can't just assume (or be convinced to 
> assume) those components are already built and resume at the last 
> component where the failure occurred?

Well, most notably a design issue. The /issue/ is that crosstool-NG has
(so far) no way to tell what changed in the configuration, related to
what component(s), and what following copmponent(s) the change does
impact.

And fixing this will need a *huge* amount of work, which I am not yet ready
to invest. Except if someone comes with a patch that I can review! ;-)

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

Re: Crosstool-ng always starts from the top

[David Wuertele]

Howdy folks,

If restartability is a requirement but mature software is not, can I
recommend Crossplex?
Crossplex is a library of macros for GNU make that let you embed your
own toolchain and root-filesystem builder in any makefile.  Crossplex
was designed from the ground up to be restartable.
It is still new and doesn't have the broad userbase or compatibility
that a great tool like crosstool-NG has, but it is scrappy and has big
dreams!
One of its main features is building multiple software configurations
in the same tree.  You can change your software configuration or add
new ones without starting from a clean build.
Anything that Crossplex can determine that can be reused between
configurations will get reused without recompilation.
There isn't much documentation yet, but I'm adding more almost daily.

  http://crossplex.org

Dave

PS I'm a big fan of crosstool and crosstool-NG.  I've learned a lot
from you guys and I hope my little contribution will be a hundredth as
useful as your awesome tools!

On Tue, Mar 30, 2010 at 11:10 PM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Stuart, All,
>
> On Wednesday 31 March 2010 00:52:00 Stuart Longland wrote:
>> Is there a way to convince crosstool-ng to pick up where it left off?
>
> This is a limitation: crosstool-NG was not designed to be restartable.
>
> However, it appeared that debugging crosstool-NG itself was cumbersome
> when a single script was modified, so a /kind of/ stop-and-restart
> feature was added, that works _iff_ the configuration has not changed.
>
> That way, I was able to try to patch gcc or it's build script and restart
> again without loosing too much time.
>
> To sum-up:
>  - no, it's not possible to restart where it left off, if the
>   configuration has changed
>  - yes you can stop-and-restart at any place iff the configuration
>   has *not* changed.
>
>> The upshot is that I have to run `ct-ng menuconfig` again, and tweak
>> the options for gcc and run it again.  This is fine, but when I run
>> `ct-ng build`, it starts right from scratch again building GMP, MPFR,
>> PPL, Cloog and binutils... which all should be identical to before, and
>> shouldn't need rebuilding.
>
> That's right from a theorical point of view.
>
>> Is there a reason why the builder can't just assume (or be convinced to
>> assume) those components are already built and resume at the last
>> component where the failure occurred?
>
> Well, most notably a design issue. The /issue/ is that crosstool-NG has
> (so far) no way to tell what changed in the configuration, related to
> what component(s), and what following copmponent(s) the change does
> impact.
>
> And fixing this will need a *huge* amount of work, which I am not yet ready
> to invest. Except if someone comes with a patch that I can review! ;-)
>
> 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