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