public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Andreas Bießmann" <andreas.devel@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] MAKEALL
Date: Wed, 19 Oct 2011 09:12:39 +0200	[thread overview]
Message-ID: <4E9E7867.1050906@gmail.com> (raw)
In-Reply-To: <CALButC+_q+bfZuMJyXjn-GbC1XFWjvGeD-go85LVUvp4S16WnA@mail.gmail.com>

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 <wd@denx.de> wrote:
>> Dear Mike Frysinger,
>>
>> In message <201110181301.57390.vapier@gentoo.org> you wrote:

<snip>

>> 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

  reply	other threads:[~2011-10-19  7:12 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-18  6:23 [U-Boot] [STATUS] "Quality" of patches / testing Wolfgang Denk
2011-10-18  6:51 ` Simon Schwarz
2011-10-18  9:22   ` Andreas Bießmann
2011-10-18  9:44     ` Wolfgang Denk
2011-10-18 13:05       ` Jason
2011-10-18 13:10         ` Jason
2011-10-18 13:13         ` Simon Schwarz
2011-10-18 13:49           ` Jason
2011-10-18 15:37             ` Jason
2011-10-18 16:12           ` Mike Frysinger
2011-10-18 13:36         ` Andreas Bießmann
2011-10-18 15:55           ` Jason
2011-10-18 14:05       ` Simon Glass
2011-10-18 16:59         ` Anton Staaf
2011-10-18 20:23         ` Wolfgang Denk
2011-10-20  0:39           ` Simon Glass
2011-10-20 15:32             ` Wolfgang Denk
2011-10-18 10:24     ` Lukasz Majewski
2011-10-18 11:02       ` Wolfgang Denk
2011-10-18  9:34   ` Wolfgang Denk
2011-10-18 13:05     ` Simon Schwarz
2011-10-18  8:49 ` Lukasz Majewski
2011-10-18 17:01 ` [U-Boot] MAKEALL Mike Frysinger
2011-10-18 17:39   ` Simon Glass
2011-10-18 17:58   ` Tom Rini
2011-10-18 18:11     ` Mike Frysinger
2011-10-18 18:31     ` Mike Frysinger
2011-10-18 18:54       ` Tom Rini
2011-10-18 19:49         ` Mike Frysinger
2011-10-18 20:07   ` Wolfgang Denk
2011-10-18 20:14     ` Mike Frysinger
2011-10-18 20:47       ` Wolfgang Denk
2011-10-18 20:55         ` Mike Frysinger
2011-10-18 21:30           ` Simon Glass
2011-10-18 22:21             ` Mike Frysinger
2011-10-19 11:36               ` Albert ARIBAUD
2011-10-19 14:25                 ` Mike Frysinger
2011-10-19 19:57                   ` Wolfgang Denk
2011-10-18 21:50           ` Wolfgang Denk
2011-10-18 22:18             ` Mike Frysinger
2011-10-18 22:33     ` Graeme Russ
2011-10-19  7:12       ` Andreas Bießmann [this message]
2011-10-19  8:57       ` Wolfgang Denk
2011-10-18 17:16 ` [U-Boot] [STATUS] "Quality" of patches / testing Anton Staaf
2011-10-18 17:44   ` Albert ARIBAUD
2011-10-18 18:07     ` Anton Staaf
2011-10-20  9:25 ` Detlev Zundel
  -- strict thread matches above, loose matches on Subject: below --
2014-01-03 23:05 [U-Boot] MAKEALL York Sun
2014-01-04  9:21 ` Wolfgang Denk
2014-01-08 16:54   ` Simon Glass
2014-02-12  9:55     ` Albert ARIBAUD
2014-02-12 10:42       ` Masahiro Yamada
2014-02-16  4:57         ` Simon Glass
2014-02-19 14:04           ` Masahiro Yamada
2014-01-29  7:13 JYOTI DUBEY
2014-01-29  7:24 ` Anatolij Gustschin
     [not found]   ` <CAE0zQku6s7L=C87CjW6wTmorttnPbeXEgHg2eBx2TcV2hvBysw@mail.gmail.com>
2014-01-29  7:45     ` Anatolij Gustschin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E9E7867.1050906@gmail.com \
    --to=andreas.devel@googlemail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox