On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
On 07/14/2015 04:09 PM, Tom Rini wrote:
On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
On 07/14/2015 11:56 AM, Tom Rini wrote:
Hey all,
I've pushed v2015.07 out to the repository and tarballs should exist soon.
This sounds a bit like a broken record, but it's true. The Kconfig migration and DM work continue moving along.
Looking over the announcement for v2015.04, I see I said we'd deprecate MAKEALL. So I've applied http://patchwork.ozlabs.org/patch/383960/ right after the tag. If buildman isn't working for you and your use case, we really need to talk.
The nice thing about MAKEALL was that I could simply grab a source tree, and run the following to build in-tree:
CROSS_COMPILE=something ./MAKEALL foo
However, with buildman, some complex config file needed to be set up to configure the toolchain (and I could never parse the docs to work out how to create it in a new checkout), plus it made copies of the source tree which takes ages for me.
Is there an equivalently simple way to invoke buildman that doesn't require configuration and copying?
For no copying, --in-tree does what you want I think.
OK. Making that the default would be useful, or providing a buildman wrapper script in the root directory that always passes this option.
For not configuring a toolchain, there's two ways to go about this. One would be to do something like:
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py index e33e105..bba60d5 100644 --- a/tools/buildman/toolchain.py +++ b/tools/buildman/toolchain.py @@ -159,7 +159,7 @@ class Toolchains: " to your buildman config file %s. See README for details" % bsettings.config_fname)
paths = []
paths = ['/usr', '/usr/local'] for name, value in toolchains: if '*' in value: paths += glob.glob(value)And then any toolchains in /usr and /usr/local would be picked up and used. Another option would be to add --tool-chain-path DIR and throw that into the above function. Thoughts?
Does that find cross-compilers? IIRC I had to add the full compiler binary name into the config file, not just a /usr search directory, so I don't think the above patch is enough to make it work. What if I want to use a specific cross-compiler and I have 4 different ARM compilers installed in /usr? How would it know which architecture's cross-compiler to use?
Well, how much are you expecting to Just Work without making a real config? That much does work for finding cross tools installed into those paths. But if you have > 1 architecture toolchain in a single location buildman does fail there today.
I like the interface of just setting the CROSS_COMPILE variable, since I can just set it in the environment and forget it if I want. Perhaps buildman could just use it if it was set, and ignore the config file (or again, a simple wrapper script could do that)?
I do not want a wrapper script. Trying to make one thing act like another thing leads to madness and corner cases. That said, how hard would it be to have buildman see if CROSS_COMPILE is set and in turn force that to be used for all specified build targets? I thought about making it see what the value is and then heuristic which arch to use, but I think that's more error prone than perhaps buildman --default-tool-chain (Uses passed value or CROSS_COMPILE if set in env) ?