public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

>

  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