From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 15 Jul 2015 09:50:58 -0600 Subject: [U-Boot] simple buildman usage In-Reply-To: <20150714233319.GP25532@bill-the-cat> References: <20150714175627.GJ23886@bill-the-cat> <55A56CED.5090008@wwwdotorg.org> <20150714220949.GD25532@bill-the-cat> <55A58F85.9090300@wwwdotorg.org> <20150714233319.GP25532@bill-the-cat> Message-ID: <55A68162.30608@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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:-)