From: York Sun <yorksun@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4 02/13] buildman: Add some notes about moving from MAKEALL
Date: Wed, 6 Aug 2014 02:53:22 +0000 [thread overview]
Message-ID: <D006E4E5.145C5%yorksun@freescale.com> (raw)
In-Reply-To: <CAPnjgZ3xHLagqfxe20XnTkJSS9NPnxdOJrXEywH3VvqK-w+xtQ@mail.gmail.com>
On 8/5/14 7:15 PM, "Simon Glass" <sjg@chromium.org> wrote:
>>>
>>> But in this case why not just leave off the 'freescale'?
>>
>> This is just an example. What if I chose "-a arm" and "-v freescale".
>>ARM has
>> 300+ targets, but only 20+ are for Freescale. I could save time by
>>building a
>> lot less platforms.
>>
>> The point here is the "OR" logic.
>
>I suppose you could use mx6 or similar, but I take your point.
>
>So what could we do here? Perhaps add a --vendor flag to limit to a
>particular vendor? Would that be enough?
With the ability to build targets for more than one arch, I will be
tempted to use syntax like this
buildman (powerpc & freescale) (arm & freescale) aarch64
buildman mpc85xx mpc83xx mpc86xx (arm & freescale) aarch64
buildman powerpc (arm & freescale) aarch64
I can see myself using these commands if they can be supported.
>
>>
>>>
>>>>
>>>> Beside, buildman still needs boards.cfg. It takes long to generate
>>>>this file.
>>>
>>> So does MAKEALL, right?
>>
>> Yes. MAKEALL also generates the boards.cfg.
>>
>>>
>>>> Not too long, but if my other tools clean the working directory for
>>>>each commit,
>>>> this accumulates to long time.
>>>
>>> Can you expand on at a little please? I'm not sure what this refers to.
>>>
>> Again it is our internal tools of choice. We use Gerrit and Jenkins.
>>Each commit
>> triggers a build on Jenkins. Right now I use MAKEALL to build the
>>concerned
>> targets. Before each build, the working directory is checkout out to
>>that
>> particular commit and cleaned. So if each build needs to generate the
>> boards.cfg, a lot of time will be consumed if I have many commits in
>>the queue.
>
>I don't think it works like that. Once you have a boards.cfg you don't
>need to regenerate it. Granted if a patch adds a new board there will
>be confusion.
I use "git clean -xfqd" after checkout every commit to make sure I have a
clean working directory. Each commit can potentially add/remove a board.
York
>
next prev parent reply other threads:[~2014-08-06 2:53 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-05 14:46 [U-Boot] [PATCH v4 0/13] Add some missing buildman features and deprecate MAKEALL Simon Glass
2014-08-05 14:46 ` [U-Boot] [PATCH v4 01/13] buildman: Fix a few typos Simon Glass
2014-08-05 14:46 ` [U-Boot] [PATCH v4 02/13] buildman: Add some notes about moving from MAKEALL Simon Glass
2014-08-05 22:34 ` York Sun
2014-08-05 23:07 ` Simon Glass
2014-08-05 23:21 ` York Sun
2014-08-06 2:15 ` Simon Glass
2014-08-06 2:53 ` York Sun [this message]
2014-08-06 14:20 ` Simon Glass
2014-08-06 15:06 ` Tom Rini
2014-08-07 12:12 ` Simon Glass
2014-08-07 13:14 ` Masahiro Yamada
2014-08-08 10:59 ` Simon Glass
2014-08-05 14:46 ` [U-Boot] [PATCH v4 03/13] buildman: Allow building of current source tree Simon Glass
2014-08-05 18:54 ` Tom Rini
2014-08-05 18:58 ` Simon Glass
2014-08-05 19:01 ` Tom Rini
2014-08-05 14:46 ` [U-Boot] [PATCH v4 04/13] buildman: Move BuilderThread code to its own file Simon Glass
2014-08-05 14:46 ` [U-Boot] [PATCH v4 05/13] buildman: Sort command line options Simon Glass
2014-08-05 14:46 ` [U-Boot] [PATCH v4 06/13] buildman: Refactor output options Simon Glass
2014-08-05 14:46 ` [U-Boot] [PATCH v4 07/13] buildman: Add verbose option to display errors as they happen Simon Glass
2014-08-05 14:46 ` [U-Boot] [PATCH v4 08/13] buildman: Remove unused non-incremental build method code Simon Glass
2014-08-05 14:46 ` [U-Boot] [PATCH v4 09/13] buildman: Add an option to specify the buildman config file Simon Glass
2014-08-05 14:47 ` [U-Boot] [PATCH v4 10/13] buildman: Add a message indicating there are no errors Simon Glass
2014-08-05 14:47 ` [U-Boot] [PATCH v4 11/13] buildman: Search for *cc instead of *gcc for the compiler Simon Glass
2014-08-05 17:41 ` Jeroen Hofstee
2014-08-05 18:25 ` Simon Glass
2014-08-05 14:47 ` [U-Boot] [PATCH v4 12/13] buildman: Add a few more toolchain examples to the README Simon Glass
2014-08-05 14:47 ` [U-Boot] [PATCH v4 13/13] RFC: Deprecate MAKEALL Simon Glass
2014-08-05 16:43 ` York Sun
2014-08-05 18:41 ` Simon Glass
2014-08-05 18:48 ` York Sun
2014-08-05 18:52 ` Simon Glass
2014-08-05 18:55 ` York Sun
2014-08-05 18:59 ` Simon Glass
2014-08-05 19:01 ` York Sun
2014-08-05 19:10 ` Tom Rini
2014-08-05 22:06 ` York Sun
2014-08-08 21:12 ` Tom Rini
2014-08-08 21:19 ` York Sun
2014-08-08 21:30 ` Tom Rini
2014-08-08 21:36 ` York Sun
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=D006E4E5.145C5%yorksun@freescale.com \
--to=yorksun@freescale.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