From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 15 Jul 2015 14:12:15 -0600 Subject: [U-Boot] simple buildman usage In-Reply-To: <20150715161431.GR25532@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> <55A68162.30608@wwwdotorg.org> <20150715161431.GR25532@bill-the-cat> Message-ID: <55A6BE9F.9090805@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 10:14 AM, Tom Rini wrote: > On Wed, Jul 15, 2015 at 09:54:41AM -0600, 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? (I think this is the email Simon asked me to respond to...) > And that's the problem / hard part about having buildman do something > with CROSS_COMPILE. CROSS_COMPILE is inherently single-arch. IIRC I've seen other projects use CROSS_COMPILE_ARM, CROSS_COMPILE_X86, etc. and blindly use those without any kind of probing/heuristics, but rather purely based on the architecture the tool is building for. I'd certainly prefer something that just uses the toolchain that it's told to rather than trying to probe a list of them, even if I can force something to override the list. > And while > that's fine for some use cases that's a huge problem for other use > cases. What I have in mind is we add an option called say: > --add-tool-chain=PREFIX. Will force PREFIX to be the toolchain used > for whatever architecture the heuristics apply it to. This will > override anything found by the automagic checking. > > This means that everyone that has automagic scripts for kernel building > can wrap in --add-tool-chain=${CROSS_COMPILE} and be done with it. This > is slightlyd different than when I was thinking last night, but I think > more useful / less likely to surprise people. >