Re: [RFC] Refactor autoconf options and build scripts

["Jasmin J." <jasmin@anw.at>]

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