All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] How do I tell buildman to use a /specific/ toolchain?
Date: Thu, 1 Oct 2015 17:27:35 -0600	[thread overview]
Message-ID: <560DC167.5080805@wwwdotorg.org> (raw)
In-Reply-To: <CAPnjgZ3Ujh8WF4zFBncuGfiFoCYjKrQ6O4Re6b-zPWXy3qahRQ@mail.gmail.com>

On 10/01/2015 04:59 PM, Simon Glass wrote:
> Hi Stephen,
>
> On Wednesday, 23 September 2015, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>
>> Simon,
>>
>> I have 3 different ARM toolchains installed into /usr/bin via distro packages. How do I tell buildman which of those to use?
>>
>> I had originally thought that ~/.buildman's [toolchain] section contained CROSS_COMPILE-like values, so I tried:
>>
>>> [toolchain]
>>> root: /
>>> arm0-not-installed: arm-none-gnueabi-
>>> arm1: arm-none-eabi-
>>> arm2: arm-linux-gnueabihf-
>>> arm3: arm-linux-gnueabi-
>>> arch64: aarch64-linux-gnu-
>>>
>>> [toolchain-alias]
>>> arm: arm1
>>> aarch64: aarch64
>>
>>
>> (I intended to change the "arm: arm1" line to point at arm1/2/3 based on which I wanted to use at a particular time).
>>
>> However, running "buildman --list-toolchains" and re-reading the docs shows me that the [toolchain] values are absolute directories that buildman searches for files named *-gcc:
>>
>>>     - scanning path 'arm-none-gnueabi-'
>>>        - looking in 'arm-none-gnueabi-/.'
>>>        - looking in 'arm-none-gnueabi-/bin'
>>>        - looking in 'arm-none-gnueabi-/usr/bin'
>>
>>
>> If buildman finds multiple toolchains, there doesn't seem to be a way to tell it which one to use. Am I missing something?
>>
>> I suppose a solution wouuld be to move the compiler binaries into different separate directories, and only list one of those directories in ~/.buildman. However, I can't do that for distro-packaged toolchains (well, I suppose I could manually mv everything all over the place, but that's really fragile since it'd break any time the package got upgraded or removed and re-installed).
>>
>> I think it makes sense to add new syntax into ~/.buildman to specify "don't do automagical searching, just use this CROSS_COMPILE value that I say". Does that sound reasonable? Automagic stuff makes for great defaults, but if it can't be overridden, it sucks when you actually know what you want.
>
> Yes I think it would be fine to add an option to use CROSS_COMPILE (of
> course it would fail if you tried to build the board with the wrong
> arch).

I wasn't necessarily looking for buildman to pick up the CROSS_COMPILE 
environment variable, although that would be a simple solution for 
single-arch builds at least. My mention of CROSS_COMPILE immediately 
above was re: using values that are formatted in the same way as the 
CROSS_COMPILE environment variable would be, rather than directory 
names, in the config file. In other words, the example content I showed 
above.

> The option other option at present is -G which lets you use multiple
> .buildman files. You could have one of these for each toolchain.

I don't think that gets me what I want. As far as I can tell, the 
buildman config file contains a list directories to search within, yet 
if I have 3 toolchains in a single directory, there's no way to select 
which one I want to use, is there?

In other words, a config file that contains:

[toolchain]
distro-packages: /usr/bin

... finds the following toolchains:

[swarren at swarren-lx1 u-boot]$ ./tools/buildman/buildman \
	--list-tool-chains
Scanning for tool chains
    - scanning path '/usr/bin'
       - looking in '/usr/bin/.'
          - found '/usr/bin/./arm-linux-gnueabi-gcc'
          - found '/usr/bin/./arm-linux-gnueabihf-gcc'
          - found '/usr/bin/./arm-none-eabi-gcc'
(That's 3 AArch32 toolchains found)
          - found '/usr/bin/./winegcc'
          - found '/usr/bin/./aarch64-linux-gnu-gcc'
          - found '/usr/bin/./gcc'
          - found '/usr/bin/./c89-gcc'
          - found '/usr/bin/./x86_64-linux-gnu-gcc'
          - found '/usr/bin/./i586-mingw32msvc-gcc'
          - found '/usr/bin/./c99-gcc'
       - looking in '/usr/bin/bin'
       - looking in '/usr/bin/usr/bin'
Tool chain test:  OK
Tool chain test:  OK
Tool chain test:  OK
Tool chain test:  OK
Tool chain test:  OK
Tool chain test:  OK
Tool chain test:  OK
Tool chain test:  OK
Tool chain test:  OK
Tool chain test:  OK
List of available toolchains (7):
aarch64   : /usr/bin/./aarch64-linux-gnu-gcc
arm       : /usr/bin/./arm-linux-gnueabi-gcc
(Buildman chose that one, and I think I have no control over that?)
c89       : /usr/bin/./c89-gcc
c99       : /usr/bin/./c99-gcc
i586      : /usr/bin/./i586-mingw32msvc-gcc
sandbox   : /usr/bin/./winegcc
x86_64    : /usr/bin/./x86_64-linux-gnu-gcc

  reply	other threads:[~2015-10-01 23:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-23 19:47 [U-Boot] How do I tell buildman to use a /specific/ toolchain? Stephen Warren
2015-10-01 22:59 ` Simon Glass
2015-10-01 23:27   ` Stephen Warren [this message]
2015-10-03 14:30     ` Simon Glass
2015-10-03 19:20       ` Stephen Warren
2015-10-04 16:38         ` Simon Glass
2015-10-05  1:19           ` Stephen Warren
2016-03-07  2:39             ` Simon Glass
2015-10-20 15:21           ` Tom Rini
2015-10-20 17:23             ` Simon Glass
2016-03-07 18:30               ` Simon Glass

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=560DC167.5080805@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --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.