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
next prev parent 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