[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