From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 15 Jul 2015 16:45:34 -0400 Subject: [U-Boot] simple buildman usage In-Reply-To: <55A6BE9F.9090805@wwwdotorg.org> 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> <55A6BE9F.9090805@wwwdotorg.org> Message-ID: <20150715204534.GS25532@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Jul 15, 2015 at 02:12:15PM -0600, Stephen Warren wrote: > 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. Which is what the preferences file is for[1]. But since you're trying to avoid making one... > > 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. Does this do what you're asking for? [1]: Yes, it's not quite right in all cases, which I consider something that needs work. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: