All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] simple buildman usage
Date: Wed, 15 Jul 2015 16:45:34 -0400	[thread overview]
Message-ID: <20150715204534.GS25532@bill-the-cat> (raw)
In-Reply-To: <55A6BE9F.9090805@wwwdotorg.org>

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 <swarren@wwwdotorg.org> 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: <http://lists.denx.de/pipermail/u-boot/attachments/20150715/65583901/attachment.sig>

  reply	other threads:[~2015-07-15 20:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-14 17:56 [U-Boot] [ANN] U-Boot v2015.07 released Tom Rini
2015-07-14 20:11 ` Stephen Warren
2015-07-14 22:09   ` Tom Rini
2015-07-14 22:39     ` [U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released) Stephen Warren
2015-07-14 23:07       ` Simon Glass
2015-07-14 23:27         ` [U-Boot] simple buildman usage Stephen Warren
2015-07-14 23:35           ` Tom Rini
2015-07-14 23:37           ` Simon Glass
2015-07-15 15:50             ` Stephen Warren
2015-07-14 23:33       ` [U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released) Tom Rini
2015-07-15 15:31         ` Simon Glass
2015-07-15 15:50         ` [U-Boot] simple buildman usage Stephen Warren
2015-07-15 15:54           ` Simon Glass
2015-07-15 16:14             ` Tom Rini
2015-07-15 20:12               ` Stephen Warren
2015-07-15 20:45                 ` Tom Rini [this message]
2015-07-15 16:28             ` Stephen Warren
2015-07-15 17:50               ` Simon Glass
2015-07-14 20:14 ` [U-Boot] [ANN] U-Boot v2015.07 released Peter Robinson
2015-07-14 20:24   ` Nikolay Dimitrov
2015-07-14 20:59     ` Robert Nelson
2015-07-14 22:02     ` Tom Rini
2015-07-15  7:15 ` Wolfgang Denk
2015-07-29  0:54   ` Simon Glass
2015-08-07  7:03 ` Wolfgang Denk
2015-08-07  8:11   ` Jagan Teki
2015-08-07 14:15     ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150715204534.GS25532@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.