From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Andreas_Bie=DFmann?= Date: Wed, 19 Oct 2011 09:12:39 +0200 Subject: [U-Boot] MAKEALL In-Reply-To: References: <20111018062310.61320140797D@gemini.denx.de> <201110181301.57390.vapier@gentoo.org> <20111018200738.B432E14094B4@gemini.denx.de> Message-ID: <4E9E7867.1050906@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Graeme Russ, Am 19.10.2011 00:33, schrieb Graeme Russ: > Hi Wolfgang, > > On Wed, Oct 19, 2011 at 7:07 AM, Wolfgang Denk wrote: >> Dear Mike Frysinger, >> >> In message <201110181301.57390.vapier@gentoo.org> you wrote: >> And then, for compatibility testings, I want to compile all this with >> ELDK 4.2. Or ELDK 4.1. Or CodeSourcery xxx. Or... >> >> I see no clean way to implement this - ok, we could provide an >> external tool / data base that maps boards or SoC names to >> CROSS_COMPILE/ARCH/PATH settings, which each user has to configure for >> his own set of tool chain settings. > > IMHO, for running MAKEALL, I see no problem with this. If we had a > 'toolchains.cfg' file which could be a format like: > > #ARCH SOC BOARD TOOLCHAIN > x86 sc520 - /path/to/gcc > > This would give new developers a head-up as to what the defacto toolchains > are That is OK. > We can then have 'toolchains.cfg.local' which is added to .gitignore so > individual users can override the toolchain. But all patch submissions > must pass MAKEALL without using toolchains.cfg.local (something like > 'MAKEALL --no-custom-toolchains'. The first thing MAKEALL should do is > scan toolchains.cfg (and toolchains.cfg.local if required) for each > selected arch and check that each toolchain is available and spit out > 'toolchain not available' warnings. But I don't like to force the users to have _all_ toolchains installed on their work station. I think the current procedure to MAKEALL _at least_ two different arches is enough. Furthermore I don't like to force the users to have a specific toolchain for submitting a patch to the list. I think it is a benefit to have a lot of different toolchains on different host systems building the code, but one should see the build-environment in MAKEALL output to be able to distinguish between error from patch or error from toolchain. > All we need to do then is setup our build machines to do an automated > git-pull and MAKEALL It is a good idea for some automated build process which runs in the backyard and spit out some error/warning messages if one patch does break the build unattended (i.e. the two arches MAKEALL did fail). best regards Andreas Bie?mann