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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.