This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |