Hi Stephen, On 14 July 2015 at 16:39, Stephen Warren <swar...@wwwdotorg.org> 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.
$ buildman seaboard will build U-Boot for seaboard. It does not copy the git tree. It puts the output in ../current, or some other directory of your choosing. I think that's pretty convenient. For toolchains you can use $ buildman --fetch-arch arm to get a default one and set it up ready for use complete with config file. But honestly the config file is not that hard to figure out! > >> 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? > > 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)? That would work for building a single arch. We could perhaps add an option for that. But full multi-toolchain support is something that would be nice to add to buildman, if someone has time. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
