Hi Tom, On 14 July 2015 at 17:33, Tom Rini <tr...@konsulko.com> 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? 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)
We can do that - is this a boolean value? What do you mean by 'passed value'? Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
