Hi Stephen,
On 15 July 2015 at 10:28, Stephen Warren swarren@wwwdotorg.org wrote:
On 07/15/2015 09:54 AM, Simon Glass wrote:
Hi Stephen,
On 15 July 2015 at 09:50, Stephen Warren swarren@wwwdotorg.org wrote:
On 07/14/2015 05:33 PM, Tom Rini wrote:
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?
The same way MAKEALL did; by honoring CROSS_COMPILE:-)
Do you give it a different CROSS_COMPILE for every arch? Isn't that a pain?
No, I almost always only build for ARM. I just very rarely build for x86/sandbox, which simply requires not including the CROSS_COMPILE value on the command-line. For new shells, I simply cut/paste the command-lines from a text file I keep my shell history all saved it, so I find it quite easy.
OK. Do you think Tom's idea works for you? Perhaps reply on that thread. I'm willing to work up a patch if yes as I assume your use case is not that unusual.
Regards, Simon