[RFC] Refactor autoconf options and build scripts
Bryan Hundven
bryanhundven@gmail.com
Tue Sep 15 23:21:00 GMT 2015
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
More information about the crossgcc
mailing list