From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3149 invoked by alias); 16 Sep 2015 11:17:42 -0000 Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org Received: (qmail 3136 invoked by uid 89); 16 Sep 2015 11:17:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail.anw.at Received: from ns1.anw.at (HELO mail.anw.at) (195.234.101.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 16 Sep 2015 11:17:38 +0000 Received: from [10.12.40.38] ([195.29.66.214]) by mail.anw.at (8.14.4/8.14.4/Debian-4) with ESMTP id t8GBHWkI009763; Wed, 16 Sep 2015 13:17:33 +0200 Message-ID: <55F94FCC.3050805@anw.at> Date: Wed, 16 Sep 2015 11:17:00 -0000 From: "Jasmin J." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bryan Hundven CC: Jean-Marie Lemetayer , crossgcc Subject: Re: [RFC] Refactor autoconf options and build scripts References: <20150912200305.69b80a14@free-electrons.com> <55F60487.5030805@anw.at> <55F6081F.8070905@anw.at> <55F61553.6040401@anw.at> <55F82DB2.80306@gmail.com> <55F863B8.402@anw.at> <55F89FDA.5000209@anw.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00051.txt.bz2 Bryan, >>> ct-ng >>> 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. I meant the resulting log output to the console. If it is too much it is not readable and we might better "cat build.log" at the end. > 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. You are the CT-NG maintainer, so you have to define how the repo is structured. I personally like the idea to separate samples from tests. But I wouldn't use another repo, but a new sub directory "testing". There we can add what ever we need, test scripts, test configurations, ... . > I think the only downside to travis-ci is that while the build may be > successful, the toolchain itself can still be totally useless. This is totally true, but it will detect simple mistakes, like mine with isl/ClooG/gcc-5.x dependencies. So I could have seen this much earlier. I guess most of the changes in CT-NG are currently related to new package versions and new configuration options, like my LIBC_NEWLIB_TARGET_CFLAGS. > When I researched travis-ci previously, it wasn't able to do this (it > would take longer then there storage limitations and timeout > restrictions. I haven't found a configuration to extend the 50 minutes on travis-ci. There is the possibility to extend the 10 minutes limit (printing to stdout/stderr). The command needs to be prefixed with "travis_wait". This will print every minute a short log. > 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.) Would you like to see travis-ci integrated with CT-NG? When you will get your server for jenkins-ci? If the answer to the second question is "within a short time" (e.g. a handful weeks), then it makes no sense to put effort into travis-ci. jenkins-ci can be integrated to GitHub, too: https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin I guess it would be possible to run automated test for every pull request like travis-ci offers. Moreover, you could allow all users who have a CT-NG fork to start/stop tests on their forks, too (manually only). Thus, you could define a pull request have to have a positive test result on your Jenkis server. Then the test effort is spread over time due to the different locations of the contributors and you need much less time to accept pull requests. Independent of the used tool, we need the test-setup mentioned above (subdir testing) with preconfigured package combinations, which are known to work. BR Jasmin PS: I asked my partner, who is an ISP, for server space. Currently there aren't any resources free, but this might change with the new 48 Core/128GB RAM machine, which is planned for Feb. 2016. -- For unsubscribe information see http://sourceware.org/lists.html#faq