[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