[RFC] Refactor autoconf options and build scripts

[RFC] Refactor autoconf options and build scripts

[Bryan Hundven]

List,

Crosstool-NG has become a very useful and valuable tool for creating
custom GCC based toolchains, and over time a lot of new features have
been added.

The addition of features, and the complexity of options each component
can support makes developing new features (multi_cc, multiple
different libcs, new targets, new hosts, etc...) very difficult.

A large majority of components Crosstool-NG builds utilize the
autotools build approach, and have a multitude of different options
that may have many external dependencies. These dependencies are
difficult at best to track in one build script, let alone across many
scripts.

My first proposal on re-factoring Crosstool-NG is to move these
autoconf arguments (--with-options) to Kconfig options/strings that
can be selected or depended on by other components and move them out
of the build scripts to additionally simplify the build scripts.

For instance:

https://github.com/crosstool-ng/crosstool-ng/blob/master/scripts/build/cc/100-gcc.sh#L242
==========================================================
    if [ "${CT_CC_CXA_ATEXIT}" = "y" ]; then
        extra_config+=("--enable-__cxa_atexit")
    else
        extra_config+=("--disable-__cxa_atexit")
    fi
==========================================================

Could turn into:
==========================================================
if CC_CXA_ATEXIT
config CC_CXA_ATEXIT_CONFIG
    string "--enable-__cxa_atexit"
    depends on CC_CXA_ATEXIT
else # ! CC_CXA_ATEXIT
config CC_CXA_ATEXIT_CONFIG
    string "--disable-__cxa_atexit"
    depends on !CC_CXA_ATEXIT
endif # CC_CXA_ATEXIT
==========================================================

Then in the scripts/build/cc/100-gcc.sh, it would only have an override like:
==========================================================
CONFIGURE_OPTS += ${CT_CC_CXA_ATEXIT_CONFIG}
==========================================================

My second proposal is to refactor the build scripts themselves into a generic
build script. Then the current build scripts (i.e.: scripts/build/cc/100-gcc.sh)
would override variables and functionality in the generic build script, as
needed.

The benefits of making the build scripts more generic and moving the
configuration options out of the build scripts would allow for Crosstool-NG to
become more flexible for future development.

Cheers,

-Bryan

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Hello!

> My first proposal on re-factoring Crosstool-NG is to move these
> autoconf arguments (--with-options) to Kconfig options/strings that
> can be selected or depended on by other components and move them out
> of the build scripts to additionally simplify the build scripts.
This might make the build scripts easier, but Kconfig gets more complex.
You are right, that you can model dependencies more easy with Kconfig, but I
hope it will not grow into a mess with time.

> config CC_CXA_ATEXIT_CONFIG
>     string "--enable-__cxa_atexit"
>     depends on CC_CXA_ATEXIT
> else # ! CC_CXA_ATEXIT

During my work on arm-none-eabi, I discovered a lot of configurations, which
are already the default (at least for my used source versions) and I would
have been able to remove the option, which was not possible currently.

If someone likes to remove such an option completely, it might be useful to
define it so:
config CC_CXA_ATEXIT_CONFIG
    string
    prompt "enable atexit option"
    default "--enable-__cxa_atexit"
    depends on CC_CXA_ATEXIT
else # ! CC_CXA_ATEXIT

At least this can be done for some of the configurations where it seems to
be appropriate.

On the other hand we will duplicate some definitions. Most of the options
are needed for the first GCC and a second time for the final one. I am sure
it doesn't make sense to duplicate all, but for some it have to be done. One
example would be the supported languages (lang_list).
Or would you like to keep some things hard coded?

> My second proposal is to refactor the build scripts themselves into a generic
> build script. Then the current build scripts (i.e.: scripts/build/cc/100-
> gcc.sh) would override variables and functionality in the generic build
> script, as needed.
You mean the download, extract, patching, ... . So one generic basic script
(like a base class in c++) for all of this steps. Sounds like a good concept.
If you are interested in OO-Bash (never tried it):
-
http://hipersayanx.blogspot.co.at/2012/12/object-oriented-programming-in-bash.html
-  https://github.com/tomas/skull

Would you like to do this in steps or all at once?
Would you like to code it on your own or shall other people help?
If the latter, how would you like to distribute the work?
How can we be sure the new version does still build all the supported variants?
Are there regression testing scripts/configurations available?

BR
   Jasmin

*************************************************************************

On 09/08/2015 07:32 PM, Bryan Hundven wrote:
> List,
> 
> Crosstool-NG has become a very useful and valuable tool for creating
> custom GCC based toolchains, and over time a lot of new features have
> been added.
> 
> The addition of features, and the complexity of options each component
> can support makes developing new features (multi_cc, multiple
> different libcs, new targets, new hosts, etc...) very difficult.
> 
> A large majority of components Crosstool-NG builds utilize the
> autotools build approach, and have a multitude of different options
> that may have many external dependencies. These dependencies are
> difficult at best to track in one build script, let alone across many
> scripts.
> 
> My first proposal on re-factoring Crosstool-NG is to move these
> autoconf arguments (--with-options) to Kconfig options/strings that
> can be selected or depended on by other components and move them out
> of the build scripts to additionally simplify the build scripts.
> 
> For instance:
> 
> https://github.com/crosstool-ng/crosstool-ng/blob/master/scripts/build/cc/100-gcc.sh#L242
> ==========================================================
>     if [ "${CT_CC_CXA_ATEXIT}" = "y" ]; then
>         extra_config+=("--enable-__cxa_atexit")
>     else
>         extra_config+=("--disable-__cxa_atexit")
>     fi
> ==========================================================
> 
> Could turn into:
> ==========================================================
> if CC_CXA_ATEXIT
> config CC_CXA_ATEXIT_CONFIG
>     string "--enable-__cxa_atexit"
>     depends on CC_CXA_ATEXIT
> else # ! CC_CXA_ATEXIT
> config CC_CXA_ATEXIT_CONFIG
>     string "--disable-__cxa_atexit"
>     depends on !CC_CXA_ATEXIT
> endif # CC_CXA_ATEXIT
> ==========================================================
> 
> Then in the scripts/build/cc/100-gcc.sh, it would only have an override like:
> ==========================================================
> CONFIGURE_OPTS += ${CT_CC_CXA_ATEXIT_CONFIG}
> ==========================================================
> 
> My second proposal is to refactor the build scripts themselves into a generic
> build script. Then the current build scripts (i.e.: scripts/build/cc/100-gcc.sh)
> would override variables and functionality in the generic build script, as
> needed.
> 
> The benefits of making the build scripts more generic and moving the
> configuration options out of the build scripts would allow for Crosstool-NG to
> become more flexible for future development.
> 
> Cheers,
> 
> -Bryan
> 
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 

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

Re: [RFC] Refactor autoconf options and build scripts

[Thomas Petazzoni]

Bryan,

On Tue, 8 Sep 2015 10:32:20 -0700, Bryan Hundven wrote:

> Crosstool-NG has become a very useful and valuable tool for creating
> custom GCC based toolchains, and over time a lot of new features have
> been added.
> 
> The addition of features, and the complexity of options each component
> can support makes developing new features (multi_cc, multiple
> different libcs, new targets, new hosts, etc...) very difficult.
> 
> A large majority of components Crosstool-NG builds utilize the
> autotools build approach, and have a multitude of different options
> that may have many external dependencies. These dependencies are
> difficult at best to track in one build script, let alone across many
> scripts.
> 
> My first proposal on re-factoring Crosstool-NG is to move these
> autoconf arguments (--with-options) to Kconfig options/strings that
> can be selected or depended on by other components and move them out
> of the build scripts to additionally simplify the build scripts.
> 
> For instance:
> 
> https://github.com/crosstool-ng/crosstool-ng/blob/master/scripts/build/cc/100-gcc.sh#L242
> ==========================================================
>     if [ "${CT_CC_CXA_ATEXIT}" = "y" ]; then
>         extra_config+=("--enable-__cxa_atexit")
>     else
>         extra_config+=("--disable-__cxa_atexit")
>     fi
> ==========================================================
> 
> Could turn into:
> ==========================================================
> if CC_CXA_ATEXIT
> config CC_CXA_ATEXIT_CONFIG
>     string "--enable-__cxa_atexit"
>     depends on CC_CXA_ATEXIT
> else # ! CC_CXA_ATEXIT
> config CC_CXA_ATEXIT_CONFIG
>     string "--disable-__cxa_atexit"
>     depends on !CC_CXA_ATEXIT
> endif # CC_CXA_ATEXIT
> ==========================================================

I am really unsure this is making things simpler. I personally find
this in fact more complicated to understand.

However, what I think makes Crosstool-NG overly complicated is the way
too large number of options. There should be some rationalization:
support only a smaller subset of the gcc/binutils/C library versions,
remove seldom used configuration options, etc.

This profusion of config options also means that a lot of combinations
are not tested and do not build. My personal experience with
Crosstool-NG, and the feedback from several users on the list is that
you very often get build failures when you start toggling options. For
example, Crosstool-NG does not ensure that the proper cloog/mpc/gmp
version is selected for a given version of gcc (solution: make the
version of those components not configurable).

> My second proposal is to refactor the build scripts themselves into a generic
> build script. Then the current build scripts (i.e.: scripts/build/cc/100-gcc.sh)
> would override variables and functionality in the generic build script, as
> needed.
> 
> The benefits of making the build scripts more generic and moving the
> configuration options out of the build scripts would allow for Crosstool-NG to
> become more flexible for future development.

I think you might be confusing complexity with length. The current build
scripts may be long, but if it's just a list of:

    if [ "${CT_CC_CXA_ATEXIT}" = "y" ]; then
        extra_config+=("--enable-__cxa_atexit")
    else
        extra_config+=("--disable-__cxa_atexit")
    fi

Then it is trivial to understand. If you replace that by something
"generic" that is shorter but in fact trickier to understand, there is
no real benefit.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

Re: [RFC] Refactor autoconf options and build scripts

[Bryan Hundven]

Thomas, Jasmin, all,

On Sat, Sep 12, 2015 at 11:03 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Bryan,
>
> On Tue, 8 Sep 2015 10:32:20 -0700, Bryan Hundven wrote:
>
>> Crosstool-NG has become a very useful and valuable tool for creating
>> custom GCC based toolchains, and over time a lot of new features have
>> been added.
>>
>> The addition of features, and the complexity of options each component
>> can support makes developing new features (multi_cc, multiple
>> different libcs, new targets, new hosts, etc...) very difficult.
>>
>> A large majority of components Crosstool-NG builds utilize the
>> autotools build approach, and have a multitude of different options
>> that may have many external dependencies. These dependencies are
>> difficult at best to track in one build script, let alone across many
>> scripts.
>>
>> My first proposal on re-factoring Crosstool-NG is to move these
>> autoconf arguments (--with-options) to Kconfig options/strings that
>> can be selected or depended on by other components and move them out
>> of the build scripts to additionally simplify the build scripts.
>>
>> For instance:
>>
>> https://github.com/crosstool-ng/crosstool-ng/blob/master/scripts/build/cc/100-gcc.sh#L242
>> ==========================================================
>>     if [ "${CT_CC_CXA_ATEXIT}" = "y" ]; then
>>         extra_config+=("--enable-__cxa_atexit")
>>     else
>>         extra_config+=("--disable-__cxa_atexit")
>>     fi
>> ==========================================================
>>
>> Could turn into:
>> ==========================================================
>> if CC_CXA_ATEXIT
>> config CC_CXA_ATEXIT_CONFIG
>>     string "--enable-__cxa_atexit"
>>     depends on CC_CXA_ATEXIT
>> else # ! CC_CXA_ATEXIT
>> config CC_CXA_ATEXIT_CONFIG
>>     string "--disable-__cxa_atexit"
>>     depends on !CC_CXA_ATEXIT
>> endif # CC_CXA_ATEXIT
>> ==========================================================
>
> I am really unsure this is making things simpler. I personally find
> this in fact more complicated to understand.
>
> However, what I think makes Crosstool-NG overly complicated is the way
> too large number of options. There should be some rationalization:
> support only a smaller subset of the gcc/binutils/C library versions,
> remove seldom used configuration options, etc.

I agree with this. I guess that's why it's an RFC :)

> This profusion of config options also means that a lot of combinations
> are not tested and do not build. My personal experience with
> Crosstool-NG, and the feedback from several users on the list is that
> you very often get build failures when you start toggling options.

Well, I can admit that I have committed updated versions of newer
components without testing all combinations, let alone all samples. I
have also merged PR with out checking if the developer has as well. I
really need a computer where I can run build tests on. Yann has given
me access to one he uses for building, and I need to get time to sit
down and get some build tests going, for at least the samples/
directory.

I would also hope in that testing that I might be able to expose and
to utilize a randconfig for ct-ng. This would help to build random
configs and find combinations of options that should have constraints.

> For
> example, Crosstool-NG does not ensure that the proper cloog/mpc/gmp
> version is selected for a given version of gcc (solution: make the
> version of those components not configurable).

With current master, I know this to be true. I need to be more strict with PRs.

>> My second proposal is to refactor the build scripts themselves into a generic
>> build script. Then the current build scripts (i.e.: scripts/build/cc/100-gcc.sh)
>> would override variables and functionality in the generic build script, as
>> needed.
>>
>> The benefits of making the build scripts more generic and moving the
>> configuration options out of the build scripts would allow for Crosstool-NG to
>> become more flexible for future development.
>
> I think you might be confusing complexity with length. The current build
> scripts may be long, but if it's just a list of:
>
>     if [ "${CT_CC_CXA_ATEXIT}" = "y" ]; then
>         extra_config+=("--enable-__cxa_atexit")
>     else
>         extra_config+=("--disable-__cxa_atexit")
>     fi
>
> Then it is trivial to understand. If you replace that by something
> "generic" that is shorter but in fact trickier to understand, there is
> no real benefit.

I don't feel that I expressed myself fully, and will re-write my RFC
with a better plan. I still see the value in what I mean, I just don't
think I thought it through enough before sending it.

I appreciate your comments! I will keep those in mind while I rewrite.

> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

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

Re: [RFC] Refactor autoconf options and build scripts

[Trevor Woerner]

On 09/12/15 17:23, Bryan Hundven wrote:
> I
> really need a computer where I can run build tests on. Yann has given
> me access to one he uses for building, and I need to get time to sit
> down and get some build tests going, for at least the samples/
> directory.

Now that you've moved to github for the code, maybe
https://travis-ci.org might help (at least for the non-randconfig cases)?

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Bryan,

> Yann has given
> me access to one he uses for building, and I need to get time to sit
> down and get some build tests going, for at least the samples/
> directory.
If we use travis-ci, we would gain a good integration to GitHub. You can check
any pull request before you add it into master automatically.

> I would also hope in that testing that I might be able to expose and
> to utilize a randconfig for ct-ng. This would help to build random
> configs and find combinations of options that should have constraints.
This might be something for Yann's server.

>> For
>> example, Crosstool-NG does not ensure that the proper cloog/mpc/gmp
>> version is selected for a given version of gcc (solution: make the
>> version of those components not configurable).
> 
> With current master, I know this to be true. I need to be more strict with PRs.
The problem are the lacking predefined configurations, which are known to
work. Then each contributor can easily check if a patch doesn't break any of
this combinations.
For me, as a newbee to CT-NG, it is nearly impossible to know working
combinations. So the solution to this problem is regression testing, no matter
if it is done manually or automatic by Jenkins, Buildbot or travis-ci.

BR
  Jasmin

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Hi!

> If we use travis-ci, we would gain a good integration to GitHub. You can
> check any pull request before you add it into master automatically.
I just activated it for my CT-NG fork (was really simple).
  -> https://travis-ci.org/getting_started

I will give it a try, when I have time this week.
Maybe someone is so pleasant to tell me which binutils/gcc/libc(newlib)/gdb
combinations I shall try as a first step.

BR
  Jasmin

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Hi!

> I will give it a try, when I have time this week.
Well, I was too curious to sleep ... ;)
Here the result of the first ct-ng test build:
  https://travis-ci.org/jasmin-j/crosstool-ng/builds/80157690

Here is the source for travis-ci:
  https://github.com/jasmin-j/crosstool-ng/tree/add_travis_ci

> Maybe someone is so pleasant to tell me which binutils/gcc/libc(newlib)/gdb
> combinations I shall try as a first step.
What shall I try?

BR
   Jasmin

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

Re: [RFC] Refactor autoconf options and build scripts

[Jean-Marie Lemetayer]

Folks,

To continue the Jasmin work about Travis-CI, I have copy paste the
Jasmin `.travis.yml` on my fork and add a script line to build all
samples this way:

    for SAMPLE in $(./ct-ng list-samples 2>/dev/null | sed -n
's/^\[...\] *\(.*\)$/\1/p'); do ./ct-ng $SAMPLE; ./ct-ng build; done

It seems to be working for now: https://travis-ci.org/jmlemetayer/crosstool-ng

But going further into the Travis-CI documentation I see that the
build timeouts after 50 minutes:
http://docs.travis-ci.com/user/customizing-the-build/#Build-Timeouts

So it seems not to be the good strategy as building all samples
serially will take more than 50 minutes. But we could run parallel
builds using matrix build:
http://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix

The only difference is that we can't run build dynamically (using
`list-samples`) and we have to say which samples we want to build for
the continuous integration.

So, I think it could be a good thing to test / refresh the whole
samples and add them into the parallel integration builds when ready.

Regards,
JML

2015-09-14 2:31 GMT+02:00 Jasmin J. <jasmin@anw.at>:
> Hi!
>
>> I will give it a try, when I have time this week.
> Well, I was too curious to sleep ... ;)
> Here the result of the first ct-ng test build:
>   https://travis-ci.org/jasmin-j/crosstool-ng/builds/80157690
>
> Here is the source for travis-ci:
>   https://github.com/jasmin-j/crosstool-ng/tree/add_travis_ci
>
>> Maybe someone is so pleasant to tell me which binutils/gcc/libc(newlib)/gdb
>> combinations I shall try as a first step.
> What shall I try?
>
> BR
>    Jasmin
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>

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

Re: [RFC] Refactor autoconf options and build scripts

[Trevor Woerner]

On 09/15/15 10:21, Jean-Marie Lemetayer wrote:
> To continue the Jasmin work about Travis-CI, I have copy paste the
> Jasmin `.travis.yml` on my fork and add a script line to build all
> samples this way:
>
>     for SAMPLE in $(./ct-ng list-samples 2>/dev/null | sed -n
> 's/^\[...\] *\(.*\)$/\1/p'); do ./ct-ng $SAMPLE; ./ct-ng build; done
>
> It seems to be working for now: https://travis-ci.org/jmlemetayer/crosstool-ng
>
> But going further into the Travis-CI documentation I see that the
> build timeouts after 50 minutes:
> http://docs.travis-ci.com/user/customizing-the-build/#Build-Timeouts
>
> So it seems not to be the good strategy as building all samples
> serially will take more than 50 minutes. But we could run parallel
> builds using matrix build:
> http://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix
>
> The only difference is that we can't run build dynamically (using
> `list-samples`) and we have to say which samples we want to build for
> the continuous integration.

Maybe you could rework your "for SAMPLE in..." script to run each sample
in a subprocess then wait for the results?

http://stackoverflow.com/questions/356100/how-to-wait-in-bash-for-several-subprocesses-to-finish-and-return-exit-code-0

That way the number of sample is still generated dynamically, the
results can be collected to show if any fail (or if they all succeed),
and the whole build (hopefully) still takes less than 50 minutes?

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

Re: [RFC] Refactor autoconf options and build scripts

[Jean-Marie Lemetayer]

Well, here is the first serial build result:
https://travis-ci.org/jmlemetayer/crosstool-ng/builds/80435130

Conclusion, doing serial build is space consuming ... :-) So we have
to add some `rm` between each builds.

I also tried to do parallel builds:
https://travis-ci.org/jmlemetayer/crosstool-ng/builds/80447510

Travis CI handle this very well and as you can see it is easy to see
which sample is good and which one is not. It is also more easy to
read the log on failure.

Personally, I think parallel builds could be a good option.

Regards,
JML

2015-09-15 16:39 GMT+02:00 Trevor Woerner <twoerner@gmail.com>:
> On 09/15/15 10:21, Jean-Marie Lemetayer wrote:
>> To continue the Jasmin work about Travis-CI, I have copy paste the
>> Jasmin `.travis.yml` on my fork and add a script line to build all
>> samples this way:
>>
>>     for SAMPLE in $(./ct-ng list-samples 2>/dev/null | sed -n
>> 's/^\[...\] *\(.*\)$/\1/p'); do ./ct-ng $SAMPLE; ./ct-ng build; done
>>
>> It seems to be working for now: https://travis-ci.org/jmlemetayer/crosstool-ng
>>
>> But going further into the Travis-CI documentation I see that the
>> build timeouts after 50 minutes:
>> http://docs.travis-ci.com/user/customizing-the-build/#Build-Timeouts
>>
>> So it seems not to be the good strategy as building all samples
>> serially will take more than 50 minutes. But we could run parallel
>> builds using matrix build:
>> http://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix
>>
>> The only difference is that we can't run build dynamically (using
>> `list-samples`) and we have to say which samples we want to build for
>> the continuous integration.
>
> Maybe you could rework your "for SAMPLE in..." script to run each sample
> in a subprocess then wait for the results?
>
> http://stackoverflow.com/questions/356100/how-to-wait-in-bash-for-several-subprocesses-to-finish-and-return-exit-code-0
>
> That way the number of sample is still generated dynamically, the
> results can be collected to show if any fail (or if they all succeed),
> and the whole build (hopefully) still takes less than 50 minutes?

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Jean-Marie,

thanks for continuing my work!

> Conclusion, doing serial build is space consuming ... :-) So we have
> to add some `rm` between each builds.
>
> I also tried to do parallel builds:
> https://travis-ci.org/jmlemetayer/crosstool-ng/builds/80447510
It seems the parallel build doesn't need a "rm", because each build has
its own disk space and time limit.

May I suggest, that you add a "cat .config" before the "./ct-ng build.2",
so that we can see what was really built.

In case of an error, it would maybe help to print the last 1000 lines of
"build.log". I guess this needs to be handled in an inline shell script,
if travis-ci does not execute further commands after a non 0 return value.

BR
   Jasmin

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Jean-Marie,

I have fixed README.md to look like the old one.
If you like, you can add it to your branch, as it seems you have now the
most advanced travis-ci branch ;)

I guess we are not far away from "production" state.
I hope Bryan likes travis-ci, too and will use it for the automated
regression tests of CT-NG (till now no comment from him).

BR
   Jasmin

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

Re: [RFC] Refactor autoconf options and build scripts

[Bryan Hundven]

Jasmin, Jean-Marie,

On Tue, Sep 15, 2015 at 11:30 AM, Jasmin J. <jasmin@anw.at> wrote:
> Jean-Marie,
>
> thanks for continuing my work!
>
>> Conclusion, doing serial build is space consuming ... :-) So we have
>> to add some `rm` between each builds.
>>
>> I also tried to do parallel builds:
>> https://travis-ci.org/jmlemetayer/crosstool-ng/builds/80447510
> It seems the parallel build doesn't need a "rm", because each build has
> its own disk space and time limit.
>
> May I suggest, that you add a "cat .config" before the "./ct-ng build.2",
> so that we can see what was really built.

Technically, the .config is in the first 100-ish lines of the build.log
Not sure that having it in the logs twice would be helpful.

> In case of an error, it would maybe help to print the last 1000 lines of
> "build.log". I guess this needs to be handled in an inline shell script,
> if travis-ci does not execute further commands after a non 0 return value.

We also could add the various CT_LOG_* options to be able to be passed
to ct-ng, so for instance you could do:

ct-ng <sample>
CT_LOG_DEBUG=y CT_LOG_LEVEL_MAX="DEBUG" ct-ng build.2

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

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Bryan,

>> May I suggest, that you add a "cat .config" before the "./ct-ng build.2",
>> so that we can see what was really built.
>
> Technically, the .config is in the first 100-ish lines of the build.log
> Not sure that having it in the logs twice would be helpful.
when you look to
  https://travis-ci.org/jmlemetayer/crosstool-ng/jobs/80447516
there is no build.log printed and I guess it would be a lot, if we do this.

> We also could add the various CT_LOG_* options to be able to be passed
> to ct-ng, so for instance you could do:
>
> ct-ng <sample>
> CT_LOG_DEBUG=y CT_LOG_LEVEL_MAX="DEBUG" ct-ng build.2
I don't know how much lines this will be at the end. It is always a trade
off ... .

What I have seen in the log is, that mostly the latest package versions are
used. I suggest to add some configs with preset gcc/binutils/... versions to
test older packages, too.
But keep in mind also, that travis-ci will try to build each commit on any
branch per default. Before we add travis-ci to master, we should add more
restrictions.

One could be:
# whitelist
branches:
  only:
    - master

To skip a build (from the docu page):
If you don’t want to run a build for a particular commit, because all you are
changing is the README for example, add [ci skip] to the git commit message.

Commits that have [ci skip] anywhere in the commit messages are ignored by
Travis CI.

Pull Requests only:
Another solution might be restricting the build to Pull Request and do not
build Pushes. We need to check if that is usable.

BR
   Jasmin

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

Re: [RFC] Refactor autoconf options and build scripts

[Bryan Hundven]

Jasmin,

On Tue, Sep 15, 2015 at 3:46 PM, Jasmin J. <jasmin@anw.at> wrote:
> Bryan,
>
>>> May I suggest, that you add a "cat .config" before the "./ct-ng build.2",
>>> so that we can see what was really built.
>>
>> Technically, the .config is in the first 100-ish lines of the build.log
>> Not sure that having it in the logs twice would be helpful.
> when you look to
>   https://travis-ci.org/jmlemetayer/crosstool-ng/jobs/80447516
> there is no build.log printed and I guess it would be a lot, if we do this.
>
>> We also could add the various CT_LOG_* options to be able to be passed
>> to ct-ng, so for instance you could do:
>>
>> ct-ng <sample>
>> CT_LOG_DEBUG=y CT_LOG_LEVEL_MAX="DEBUG" ct-ng build.2
> I don't know how much lines this will be at the end. It is always a trade
> off ... .

one line of:

export CT_blah_blah

in kconfig.mk for each option.

> What I have seen in the log is, that mostly the latest package versions are
> used. I suggest to add some configs with preset gcc/binutils/... versions to
> test older packages, too.

Rather then confusing users with different samples using different
versions, why not just create a separate git repository with the
samples, then clone the test samples before running the test. Just a
thought.

> But keep in mind also, that travis-ci will try to build each commit on any
> branch per default. Before we add travis-ci to master, we should add more
> restrictions.
>
> One could be:
> # whitelist
> branches:
>   only:
>     - master
>
> To skip a build (from the docu page):

Sure.

> If you don’t want to run a build for a particular commit, because all you are
> changing is the README for example, add [ci skip] to the git commit message.
>
> Commits that have [ci skip] anywhere in the commit messages are ignored by
> Travis CI.
>
> Pull Requests only:
> Another solution might be restricting the build to Pull Request and do not
> build Pushes. We need to check if that is usable.
>
> BR
>    Jasmin


All very good info! :)

I think the only downside to travis-ci is that while the build may be
successful, the toolchain itself can still be totally useless.

What I am looking at is a two part test. One part builds crosstool-ng.
The second part runs the dejagnu gcc test-suite. The results from that
test vary, depending on options used and target.

When I researched travis-ci previously, it wasn't able to do this (it
would take longer then there storage limitations and timeout
restrictions.

So I started looking at getting a server and setting up jenkins-ci, so
that I can be in control of the test environment, and a much larger
storage restriction and no timeouts for tests. (I mean obviously we
would want to say that the test is dead if it took longer then X
minutes/hours.)

Just my 2cents...

-Bryan

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Bryan,

>>> ct-ng <sample>
>>> CT_LOG_DEBUG=y CT_LOG_LEVEL_MAX="DEBUG" ct-ng build.2
>> I don't know how much lines this will be at the end. It is always a trade
>> off ... .
> 
> one line of:
> 
> export CT_blah_blah
> 
> in kconfig.mk for each option.
I meant the resulting log output to the console. If it is too much it is not
readable and we might better "cat build.log" at the end.

> Rather then confusing users with different samples using different
> versions, why not just create a separate git repository with the
> samples, then clone the test samples before running the test. Just a
> thought.
You are the CT-NG maintainer, so you have to define how the repo is structured.
I personally like the idea to separate samples from tests. But I wouldn't use
another repo, but a new sub directory "testing". There we can add what ever we
need, test scripts, test configurations, ... .

> I think the only downside to travis-ci is that while the build may be
> successful, the toolchain itself can still be totally useless.
This is totally true, but it will detect simple mistakes, like mine with
isl/ClooG/gcc-5.x dependencies. So I could have seen this much earlier.
I guess most of the changes in CT-NG are currently related to new package
versions and new configuration options, like my LIBC_NEWLIB_TARGET_CFLAGS.

> When I researched travis-ci previously, it wasn't able to do this (it
> would take longer then there storage limitations and timeout
> restrictions.
I haven't found a configuration to extend the 50 minutes on travis-ci. There
is the possibility to extend the 10 minutes limit (printing to stdout/stderr).
The command needs to be prefixed with "travis_wait". This will print every
minute a short log.

> So I started looking at getting a server and setting up jenkins-ci, so
> that I can be in control of the test environment, and a much larger
> storage restriction and no timeouts for tests. (I mean obviously we
> would want to say that the test is dead if it took longer then X
> minutes/hours.)
Would you like to see travis-ci integrated with CT-NG?
When you will get your server for jenkins-ci?

If the answer to the second question is "within a short time" (e.g. a handful
weeks), then it makes no sense to put effort into travis-ci. jenkins-ci can be
integrated to GitHub, too:
  https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin
I guess it would be possible to run automated test for every pull request like
travis-ci offers.
Moreover, you could allow all users who have a CT-NG fork to start/stop tests
on their forks, too (manually only). Thus, you could define a pull request have
to have a positive test result on your Jenkis server. Then the test effort is
spread over time due to the different locations of the contributors and you
need much less time to accept pull requests.

Independent of the used tool, we need the test-setup mentioned above (subdir
testing) with preconfigured package combinations, which are known to work.

BR
   Jasmin

PS: I asked my partner, who is an ISP, for server space. Currently there aren't
    any resources free, but this might change with the new 48 Core/128GB RAM
    machine, which is planned for Feb. 2016.

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

Re: [RFC] Refactor autoconf options and build scripts

[Jean-Marie Lemetayer]

Hi,

I have made something proper in a new branch `travis_ci`. Here is the
new `.travis.yml`:
https://github.com/jmlemetayer/crosstool-ng/blob/travis_ci/.travis.yml

The white-list stuff is commented because I am not developing in
master for now. It should be uncommented before to create the pull
request.

I have selected only few samples. I think it is better to begin with
few of them, and after add other tested samples (much easier to have a
'all green status').

I have add an `after_failure` handle to display the last 500 lines of
'build.log'. Personally, I will decrease this to the last 200 lines.

Bryan, regarding the two-part test. I think it might be a good idea to
split this into:

    1. A quick build test with a small set of configured samples (or
maybe no samples at all) which could be handle automatically by
travis-ci on each commits / pull request.
    2. A manually trigger longer test with all samples (and maybe
other things to test all combinations) which can be handle by jenkins
or buildbot on private servers.

Regards,
JML

ps: I also have a server which can be used to do jenkins/buildbot
distributed builds.
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds
http://buildbot.net

2015-09-16 1:21 GMT+02:00 Bryan Hundven <bryanhundven@gmail.com>:
> Jasmin,
>
> On Tue, Sep 15, 2015 at 3:46 PM, Jasmin J. <jasmin@anw.at> wrote:
>> Bryan,
>>
>>>> May I suggest, that you add a "cat .config" before the "./ct-ng build.2",
>>>> so that we can see what was really built.
>>>
>>> Technically, the .config is in the first 100-ish lines of the build.log
>>> Not sure that having it in the logs twice would be helpful.
>> when you look to
>>   https://travis-ci.org/jmlemetayer/crosstool-ng/jobs/80447516
>> there is no build.log printed and I guess it would be a lot, if we do this.
>>
>>> We also could add the various CT_LOG_* options to be able to be passed
>>> to ct-ng, so for instance you could do:
>>>
>>> ct-ng <sample>
>>> CT_LOG_DEBUG=y CT_LOG_LEVEL_MAX="DEBUG" ct-ng build.2
>> I don't know how much lines this will be at the end. It is always a trade
>> off ... .
>
> one line of:
>
> export CT_blah_blah
>
> in kconfig.mk for each option.
>
>> What I have seen in the log is, that mostly the latest package versions are
>> used. I suggest to add some configs with preset gcc/binutils/... versions to
>> test older packages, too.
>
> Rather then confusing users with different samples using different
> versions, why not just create a separate git repository with the
> samples, then clone the test samples before running the test. Just a
> thought.
>
>> But keep in mind also, that travis-ci will try to build each commit on any
>> branch per default. Before we add travis-ci to master, we should add more
>> restrictions.
>>
>> One could be:
>> # whitelist
>> branches:
>>   only:
>>     - master
>>
>> To skip a build (from the docu page):
>
> Sure.
>
>> If you don’t want to run a build for a particular commit, because all you are
>> changing is the README for example, add [ci skip] to the git commit message.
>>
>> Commits that have [ci skip] anywhere in the commit messages are ignored by
>> Travis CI.
>>
>> Pull Requests only:
>> Another solution might be restricting the build to Pull Request and do not
>> build Pushes. We need to check if that is usable.
>>
>> BR
>>    Jasmin
>
>
> All very good info! :)
>
> I think the only downside to travis-ci is that while the build may be
> successful, the toolchain itself can still be totally useless.
>
> What I am looking at is a two part test. One part builds crosstool-ng.
> The second part runs the dejagnu gcc test-suite. The results from that
> test vary, depending on options used and target.
>
> When I researched travis-ci previously, it wasn't able to do this (it
> would take longer then there storage limitations and timeout
> restrictions.
>
> So I started looking at getting a server and setting up jenkins-ci, so
> that I can be in control of the test environment, and a much larger
> storage restriction and no timeouts for tests. (I mean obviously we
> would want to say that the test is dead if it took longer then X
> minutes/hours.)
>
> Just my 2cents...
>
> -Bryan

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

Re: [RFC] Refactor autoconf options and build scripts

[Jean-Marie Lemetayer]

I forgot to give you the result build link:
https://travis-ci.org/jmlemetayer/crosstool-ng/builds/80602525

2015-09-16 13:44 GMT+02:00 Jean-Marie Lemetayer <jeanmarie.lemetayer@gmail.com>:
> Hi,
>
> I have made something proper in a new branch `travis_ci`. Here is the
> new `.travis.yml`:
> https://github.com/jmlemetayer/crosstool-ng/blob/travis_ci/.travis.yml
>
> The white-list stuff is commented because I am not developing in
> master for now. It should be uncommented before to create the pull
> request.
>
> I have selected only few samples. I think it is better to begin with
> few of them, and after add other tested samples (much easier to have a
> 'all green status').
>
> I have add an `after_failure` handle to display the last 500 lines of
> 'build.log'. Personally, I will decrease this to the last 200 lines.
>
> Bryan, regarding the two-part test. I think it might be a good idea to
> split this into:
>
>     1. A quick build test with a small set of configured samples (or
> maybe no samples at all) which could be handle automatically by
> travis-ci on each commits / pull request.
>     2. A manually trigger longer test with all samples (and maybe
> other things to test all combinations) which can be handle by jenkins
> or buildbot on private servers.
>
> Regards,
> JML
>
> ps: I also have a server which can be used to do jenkins/buildbot
> distributed builds.
> https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds
> http://buildbot.net
>
> 2015-09-16 1:21 GMT+02:00 Bryan Hundven <bryanhundven@gmail.com>:
>> Jasmin,
>>
>> On Tue, Sep 15, 2015 at 3:46 PM, Jasmin J. <jasmin@anw.at> wrote:
>>> Bryan,
>>>
>>>>> May I suggest, that you add a "cat .config" before the "./ct-ng build.2",
>>>>> so that we can see what was really built.
>>>>
>>>> Technically, the .config is in the first 100-ish lines of the build.log
>>>> Not sure that having it in the logs twice would be helpful.
>>> when you look to
>>>   https://travis-ci.org/jmlemetayer/crosstool-ng/jobs/80447516
>>> there is no build.log printed and I guess it would be a lot, if we do this.
>>>
>>>> We also could add the various CT_LOG_* options to be able to be passed
>>>> to ct-ng, so for instance you could do:
>>>>
>>>> ct-ng <sample>
>>>> CT_LOG_DEBUG=y CT_LOG_LEVEL_MAX="DEBUG" ct-ng build.2
>>> I don't know how much lines this will be at the end. It is always a trade
>>> off ... .
>>
>> one line of:
>>
>> export CT_blah_blah
>>
>> in kconfig.mk for each option.
>>
>>> What I have seen in the log is, that mostly the latest package versions are
>>> used. I suggest to add some configs with preset gcc/binutils/... versions to
>>> test older packages, too.
>>
>> Rather then confusing users with different samples using different
>> versions, why not just create a separate git repository with the
>> samples, then clone the test samples before running the test. Just a
>> thought.
>>
>>> But keep in mind also, that travis-ci will try to build each commit on any
>>> branch per default. Before we add travis-ci to master, we should add more
>>> restrictions.
>>>
>>> One could be:
>>> # whitelist
>>> branches:
>>>   only:
>>>     - master
>>>
>>> To skip a build (from the docu page):
>>
>> Sure.
>>
>>> If you don’t want to run a build for a particular commit, because all you are
>>> changing is the README for example, add [ci skip] to the git commit message.
>>>
>>> Commits that have [ci skip] anywhere in the commit messages are ignored by
>>> Travis CI.
>>>
>>> Pull Requests only:
>>> Another solution might be restricting the build to Pull Request and do not
>>> build Pushes. We need to check if that is usable.
>>>
>>> BR
>>>    Jasmin
>>
>>
>> All very good info! :)
>>
>> I think the only downside to travis-ci is that while the build may be
>> successful, the toolchain itself can still be totally useless.
>>
>> What I am looking at is a two part test. One part builds crosstool-ng.
>> The second part runs the dejagnu gcc test-suite. The results from that
>> test vary, depending on options used and target.
>>
>> When I researched travis-ci previously, it wasn't able to do this (it
>> would take longer then there storage limitations and timeout
>> restrictions.
>>
>> So I started looking at getting a server and setting up jenkins-ci, so
>> that I can be in control of the test environment, and a much larger
>> storage restriction and no timeouts for tests. (I mean obviously we
>> would want to say that the test is dead if it took longer then X
>> minutes/hours.)
>>
>> Just my 2cents...
>>
>> -Bryan

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Jean-Marie,

> I forgot to give you the result build link:
> https://travis-ci.org/jmlemetayer/crosstool-ng/builds/80602525
Looks really good and we see now the last build.log lines, too.

>> I have selected only few samples. I think it is better to begin with
>> few of them, and after add other tested samples (much easier to have a
>> 'all green status').
But most of the selected samples did fail ;)

What do you think about a new subdirectory "testing" and the corresponding
CT-NG target to build the configurations stored there. This would separate the
samplings for the user from our regression tests.

>> I have add an `after_failure` handle to display the last 500 lines of
>> 'build.log'. Personally, I will decrease this to the last 200 lines.
Yes, reduce it to 200.

BR
   Jasmin

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

Re: [RFC] Refactor autoconf options and build scripts

[Jean-Marie Lemetayer]

> But most of the selected samples did fail ;)
Yeah, I don't known why. I just update my fork. Maybe a regression ! :P

> What do you think about a new subdirectory "testing" and the corresponding
> CT-NG target to build the configurations stored there. This would separate the
> samplings for the user from our regression tests.

As suggested by Bryan, we should do a two-part test. The first part,
run by travis on each commit / pull request could be testing the
standard user samples (arm, x86, raspberrypi...). The second part,
manually triggered, running on jenkins or buildbot servers, could be
using a "testing" directory to store testing samples / script. It
could be useful to test all cases. Maybe a random config as in the
kernel?

This way we can quickly identify regression on standard samples with
travis, and run full regression test when developing / reworking some
major features.

If, it is OK for you, I can finish the travis part. I just need to
identify the "standard" samples.

Regards,
JML



2015-09-16 15:20 GMT+02:00 Jasmin J. <jasmin@anw.at>:
> Jean-Marie,
>
>> I forgot to give you the result build link:
>> https://travis-ci.org/jmlemetayer/crosstool-ng/builds/80602525
> Looks really good and we see now the last build.log lines, too.
>
>>> I have selected only few samples. I think it is better to begin with
>>> few of them, and after add other tested samples (much easier to have a
>>> 'all green status').
> But most of the selected samples did fail ;)
>
> What do you think about a new subdirectory "testing" and the corresponding
> CT-NG target to build the configurations stored there. This would separate the
> samplings for the user from our regression tests.
>
>>> I have add an `after_failure` handle to display the last 500 lines of
>>> 'build.log'. Personally, I will decrease this to the last 200 lines.
> Yes, reduce it to 200.
>
> BR
>    Jasmin

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Jean-Marie,

> This way we can quickly identify regression on standard samples with
> travis, and run full regression test when developing / reworking some
> major features.
I see the problem, that the samples doesn't define a gcc/binutils/... version.
So the tests are done with the default (newest) versions of the tools.
If we go the direction samples, then we should define the most important
configurations for older GCC versions, too. I don't know which combination(s)
would be representative. This is something Bryan can do best, I think.

Maybe we don't need to define this combinations within the samples. We can
define this in the travis-ci configuration, I guess.
If you look here:
  http://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix
  -> Explicity Including Builds
Can be used to define an additional env: for the GCC/binutils/... version.

> This way we can quickly identify regression on standard samples with
> travis, and run full regression test when developing / reworking some
> major features.
I agree!

> If, it is OK for you, I can finish the travis part. I just need to
> identify the "standard" samples.
From my point you have the "OK". It is better to start with a few tests, than
nothing (like now).
When someone of us has time, we can add more (GCC/binutils/... version).

BR
   Jasmin

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Jean-Marie,

>> If, it is OK for you, I can finish the travis part. I just need to
>> identify the "standard" samples.
> From my point you have the "OK". It is better to start with a few tests, than
> nothing (like now).
> When someone of us has time, we can add more (GCC/binutils/... version).
I haven't seen a pull request from you nor any new commit on your branch.
What else is missing to continue with this?

BR
   Jasmin

*********************************************************************

On 2015-09-16 16:50, Jasmin J. wrote:
> Jean-Marie,
> 
>> This way we can quickly identify regression on standard samples with
>> travis, and run full regression test when developing / reworking some
>> major features.
> I see the problem, that the samples doesn't define a gcc/binutils/... version.
> So the tests are done with the default (newest) versions of the tools.
> If we go the direction samples, then we should define the most important
> configurations for older GCC versions, too. I don't know which combination(s)
> would be representative. This is something Bryan can do best, I think.
> 
> Maybe we don't need to define this combinations within the samples. We can
> define this in the travis-ci configuration, I guess.
> If you look here:
>   http://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix
>   -> Explicity Including Builds
> Can be used to define an additional env: for the GCC/binutils/... version.
> 
>> This way we can quickly identify regression on standard samples with
>> travis, and run full regression test when developing / reworking some
>> major features.
> I agree!
> 
>> If, it is OK for you, I can finish the travis part. I just need to
>> identify the "standard" samples.
>From my point you have the "OK". It is better to start with a few tests, than
> nothing (like now).
> When someone of us has time, we can add more (GCC/binutils/... version).
> 
> BR
>    Jasmin
> 
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 

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

Re: [RFC] Refactor autoconf options and build scripts

[Jean-Marie Lemetayer]

Jasmin, Bryan, All,

I was just waiting for a Bryan approval about the selected - so called
- standard samples.

For now I have selected:

 * arm-unknown-eabi
 * armeb-unknown-eabi
 * arm-unknown-linux-gnueabi
 * armeb-unknown-linux-gnueabi

I think it's a good start. We could add the other later.

To go faster, I have created a pull request as it is:
https://github.com/crosstool-ng/crosstool-ng/pull/180

Regards,
JML

2015-09-22 0:55 GMT+02:00 Jasmin J. <jasmin@anw.at>:
> Jean-Marie,
>
>>> If, it is OK for you, I can finish the travis part. I just need to
>>> identify the "standard" samples.
>> From my point you have the "OK". It is better to start with a few tests, than
>> nothing (like now).
>> When someone of us has time, we can add more (GCC/binutils/... version).
> I haven't seen a pull request from you nor any new commit on your branch.
> What else is missing to continue with this?
>
> BR
>    Jasmin
>
> *********************************************************************
>
> On 2015-09-16 16:50, Jasmin J. wrote:
>> Jean-Marie,
>>
>>> This way we can quickly identify regression on standard samples with
>>> travis, and run full regression test when developing / reworking some
>>> major features.
>> I see the problem, that the samples doesn't define a gcc/binutils/... version.
>> So the tests are done with the default (newest) versions of the tools.
>> If we go the direction samples, then we should define the most important
>> configurations for older GCC versions, too. I don't know which combination(s)
>> would be representative. This is something Bryan can do best, I think.
>>
>> Maybe we don't need to define this combinations within the samples. We can
>> define this in the travis-ci configuration, I guess.
>> If you look here:
>>   http://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix
>>   -> Explicity Including Builds
>> Can be used to define an additional env: for the GCC/binutils/... version.
>>
>>> This way we can quickly identify regression on standard samples with
>>> travis, and run full regression test when developing / reworking some
>>> major features.
>> I agree!
>>
>>> If, it is OK for you, I can finish the travis part. I just need to
>>> identify the "standard" samples.
>>From my point you have the "OK". It is better to start with a few tests, than
>> nothing (like now).
>> When someone of us has time, we can add more (GCC/binutils/... version).
>>
>> BR
>>    Jasmin
>>
>> --
>> For unsubscribe information see http://sourceware.org/lists.html#faq
>>

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

Re: [RFC] Refactor autoconf options and build scripts

[Bryan Hundven]

Jean-Marie, Jasmin,

On Tue, Sep 22, 2015 at 1:16 AM, Jean-Marie Lemetayer
<jeanmarie.lemetayer@gmail.com> wrote:
> Jasmin, Bryan, All,
>
> I was just waiting for a Bryan approval about the selected - so called
> - standard samples.
>
> For now I have selected:
>
>  * arm-unknown-eabi
>  * armeb-unknown-eabi
>  * arm-unknown-linux-gnueabi
>  * armeb-unknown-linux-gnueabi
>
> I think it's a good start. We could add the other later.
>
> To go faster, I have created a pull request as it is:
> https://github.com/crosstool-ng/crosstool-ng/pull/180
>
> Regards,
> JML

I have merged the PR, and then merged a PR from Jasmin to test the
travis-ci out.
A build is running:
https://travis-ci.org/crosstool-ng/crosstool-ng/builds

Thanks for adding this!

I am still working towards a jenkins build, to actually run dejagnu,
but I just haven't had time.
Next I'd like to add powerpc and mips builds.

Cheers,

-Bryan

PS. Please don't top post. It just makes it harder to follow the flow
of conversation. :)

> 2015-09-22 0:55 GMT+02:00 Jasmin J. <jasmin@anw.at>:
>> Jean-Marie,
>>
>>>> If, it is OK for you, I can finish the travis part. I just need to
>>>> identify the "standard" samples.
>>> From my point you have the "OK". It is better to start with a few tests, than
>>> nothing (like now).
>>> When someone of us has time, we can add more (GCC/binutils/... version).
>> I haven't seen a pull request from you nor any new commit on your branch.
>> What else is missing to continue with this?
>>
>> BR
>>    Jasmin
>>
>> *********************************************************************
>>
>> On 2015-09-16 16:50, Jasmin J. wrote:
>>> Jean-Marie,
>>>
>>>> This way we can quickly identify regression on standard samples with
>>>> travis, and run full regression test when developing / reworking some
>>>> major features.
>>> I see the problem, that the samples doesn't define a gcc/binutils/... version.
>>> So the tests are done with the default (newest) versions of the tools.
>>> If we go the direction samples, then we should define the most important
>>> configurations for older GCC versions, too. I don't know which combination(s)
>>> would be representative. This is something Bryan can do best, I think.
>>>
>>> Maybe we don't need to define this combinations within the samples. We can
>>> define this in the travis-ci configuration, I guess.
>>> If you look here:
>>>   http://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix
>>>   -> Explicity Including Builds
>>> Can be used to define an additional env: for the GCC/binutils/... version.
>>>
>>>> This way we can quickly identify regression on standard samples with
>>>> travis, and run full regression test when developing / reworking some
>>>> major features.
>>> I agree!
>>>
>>>> If, it is OK for you, I can finish the travis part. I just need to
>>>> identify the "standard" samples.
>>>From my point you have the "OK". It is better to start with a few tests, than
>>> nothing (like now).
>>> When someone of us has time, we can add more (GCC/binutils/... version).
>>>
>>> BR
>>>    Jasmin
>>>
>>> --
>>> For unsubscribe information see http://sourceware.org/lists.html#faq
>>>

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

Re: [RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Thomas,

> support only a smaller subset of the gcc/binutils/C library versions,
> remove seldom used configuration options, etc.
My main goal is use CT-NG to build an arm-none-eabi compiler. This is currently
not full supported by CT-NG, at least with all the options the original build
script is using. But I am very happy to have all the current options and
selections which makes my life easier.

A solution might be to enable some of the options only in experimental mode or
to introduce a new mode, which allows only a few version combinations. If the
new "Expert Mode" is selected, then you will get all the options to change the
versions.

> For example, Crosstool-NG
> does not ensure that the proper cloog/mpc/gmp version is selected for a
> given version of gcc
At least for ClooG/isl I just implemented this. But you are right, who has the
time to check all the possible combinations.

> I think you might be confusing complexity with length. The current build 
> scripts may be long, but if it's just a list of:
> 
> if [ "${CT_CC_CXA_ATEXIT}" = "y" ]; then 
> extra_config+=("--enable-__cxa_atexit") else 
> extra_config+=("--disable-__cxa_atexit") fi
> 
> Then it is trivial to understand. If you replace that by something
> "generic" that is shorter but in fact trickier to understand, there is no
> real benefit.
100-gcc.sh uses "do_gcc_core_backend" for both the core and the final gcc,
when building for bare-metal. I don't know why, but the do_gcc_core_backend
function does not set the options for libssp and libquadmath and the handling
of "CT_CC_GCC_USE_LTO" is different, too.
So a generic "base class" for the gcc build might help to reduce such
inconsistencies, because I guess this difference for both compilers is not
intended.

I guess it depends how Bryan wants to implement the generic script and how it
can be tailored in the specific script. For example, I want to build newlib
in two variants. This requires an additional build step "newlib-nano". However
I will implement this, it is a complete copy of the newlib step with only 2..3
options changed/added. Having here a generic build script would reduce the work
to implement this.

> Now that you've moved to github for the code, maybe
> https://travis-ci.org might help (at least for the non-randconfig cases)?
Although this is intended for program regression tests, it can be used for
CT-NG with this options (I guess):

before_install:
	- sudo apt-get update -qq
	- sudo apt-get install -qq [packages list]
 -> used to install the packages required for CT-NG

install: ./tests/config_cg_ng.sh
 -> will do bootstrap, configure --enable-local and make

script: ./tests/run-tests.sh
 -> will execute CT-NG with the predefined configurations

Note:
 a) ./tests is a new subdirectory for the travis-ci scripts.
 b) Someone needs to define predefined configs for the different variants to
    test and enter them into run-tests.sh

Got this info about the configuration from here:
  http://docs.travis-ci.com/user/customizing-the-build/

BR
   Jasmin

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