From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 15 Jul 2015 10:28:06 -0600 Subject: [U-Boot] simple buildman usage In-Reply-To: References: <20150714175627.GJ23886@bill-the-cat> <55A56CED.5090008@wwwdotorg.org> <20150714220949.GD25532@bill-the-cat> <55A58F85.9090300@wwwdotorg.org> <20150714233319.GP25532@bill-the-cat> <55A68162.30608@wwwdotorg.org> Message-ID: <55A68A16.1080603@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/15/2015 09:54 AM, Simon Glass wrote: > Hi Stephen, > > On 15 July 2015 at 09:50, Stephen Warren 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.