* [U-Boot] [ANN] U-Boot v2015.07 released
@ 2015-07-14 17:56 Tom Rini
2015-07-14 20:11 ` Stephen Warren
` (3 more replies)
0 siblings, 4 replies; 27+ messages in thread
From: Tom Rini @ 2015-07-14 17:56 UTC (permalink / raw)
To: u-boot
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.
Finally, I would encourage custodians to follow-up with anything big I've
overlooked.
Thanks for the hard work everyone! The merge window is now open and
will close on Saturday Aug 1st.
--
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/20150714/965ee4e8/attachment.sig>
^ permalink raw reply [flat|nested] 27+ messages in thread* [U-Boot] [ANN] U-Boot v2015.07 released 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 20:14 ` [U-Boot] [ANN] U-Boot v2015.07 released Peter Robinson ` (2 subsequent siblings) 3 siblings, 1 reply; 27+ messages in thread From: Stephen Warren @ 2015-07-14 20:11 UTC (permalink / raw) To: u-boot 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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [ANN] U-Boot v2015.07 released 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 0 siblings, 1 reply; 27+ messages in thread From: Tom Rini @ 2015-07-14 22:09 UTC (permalink / raw) To: u-boot 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. 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? -- 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/20150714/bebcb3a0/attachment.sig> ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released) 2015-07-14 22:09 ` Tom Rini @ 2015-07-14 22:39 ` Stephen Warren 2015-07-14 23:07 ` Simon Glass 2015-07-14 23:33 ` [U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released) Tom Rini 0 siblings, 2 replies; 27+ messages in thread From: Stephen Warren @ 2015-07-14 22:39 UTC (permalink / raw) To: u-boot 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? I like the interface of just setting the CROSS_COMPILE variable, since I can just set it in the environment and forget it if I want. Perhaps buildman could just use it if it was set, and ignore the config file (or again, a simple wrapper script could do that)? ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released) 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:33 ` [U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released) Tom Rini 1 sibling, 1 reply; 27+ messages in thread From: Simon Glass @ 2015-07-14 23:07 UTC (permalink / raw) To: u-boot Hi Stephen, On 14 July 2015 at 16:39, Stephen Warren <swarren@wwwdotorg.org> 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. $ buildman seaboard will build U-Boot for seaboard. It does not copy the git tree. It puts the output in ../current, or some other directory of your choosing. I think that's pretty convenient. For toolchains you can use $ buildman --fetch-arch arm to get a default one and set it up ready for use complete with config file. But honestly the config file is not that hard to figure out! > >> 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? > > I like the interface of just setting the CROSS_COMPILE variable, since I can just set it in the environment and forget it if I want. Perhaps buildman could just use it if it was set, and ignore the config file (or again, a simple wrapper script could do that)? That would work for building a single arch. We could perhaps add an option for that. But full multi-toolchain support is something that would be nice to add to buildman, if someone has time. Regards, Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage 2015-07-14 23:07 ` Simon Glass @ 2015-07-14 23:27 ` Stephen Warren 2015-07-14 23:35 ` Tom Rini 2015-07-14 23:37 ` Simon Glass 0 siblings, 2 replies; 27+ messages in thread From: Stephen Warren @ 2015-07-14 23:27 UTC (permalink / raw) To: u-boot On 07/14/2015 05:07 PM, Simon Glass wrote: > Hi Stephen, > > On 14 July 2015 at 16:39, Stephen Warren <swarren@wwwdotorg.org> 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. > > $ buildman seaboard > > will build U-Boot for seaboard. It does not copy the git tree. It puts > the output in ../current, or some other directory of your choosing. I > think that's pretty convenient. I'd prefer it to go in . so I don't get clutter outside my working tree. > For toolchains you can use > > $ buildman --fetch-arch arm > > to get a default one and set it up ready for use complete with config > file. I already have the toolchain I want to use installed, so I'd like a simple way to use it. > But honestly the config file is not that hard to figure out! Well perhaps if you understand its concepts/semantics, but I've always had an extremely hard time grasping it, and at least the last time I RTFMd there weren't any examples aimed at "this is how to write a config file to just use this binary name in $PATH". Equally, having to edit a config file any time I want to switch compilers is a bit annoying. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage 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 1 sibling, 0 replies; 27+ messages in thread From: Tom Rini @ 2015-07-14 23:35 UTC (permalink / raw) To: u-boot On Tue, Jul 14, 2015 at 05:27:15PM -0600, Stephen Warren wrote: > On 07/14/2015 05:07 PM, Simon Glass wrote: [snip] > Equally, > having to edit a config file any time I want to switch compilers is > a bit annoying. As I have a wrapper to go and whack a specific value into the builmanrc I pass via -G so that I can use ELDK 5.2 or 5.3 or Linaro's whatever release or so on, +1 to it being annoying to have to edit a file to switch compilers. -- 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/20150714/4a109341/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage 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 1 sibling, 1 reply; 27+ messages in thread From: Simon Glass @ 2015-07-14 23:37 UTC (permalink / raw) To: u-boot Hi Stephen, On 14 July 2015 at 17:27, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/14/2015 05:07 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 14 July 2015 at 16:39, Stephen Warren <swarren@wwwdotorg.org> 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. >> >> >> $ buildman seaboard >> >> will build U-Boot for seaboard. It does not copy the git tree. It puts >> the output in ../current, or some other directory of your choosing. I >> think that's pretty convenient. > > > I'd prefer it to go in . so I don't get clutter outside my working tree. -o . > >> For toolchains you can use >> >> $ buildman --fetch-arch arm >> >> to get a default one and set it up ready for use complete with config >> file. > > > I already have the toolchain I want to use installed, so I'd like a simple > way to use it. > >> But honestly the config file is not that hard to figure out! > > > Well perhaps if you understand its concepts/semantics, but I've always had > an extremely hard time grasping it, and at least the last time I RTFMd there > weren't any examples aimed at "this is how to write a config file to just > use this binary name in $PATH". Equally, having to edit a config file any > time I want to switch compilers is a bit annoying. Agreed. Perhaps annoying enough to contribute a patch? Regards, Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage 2015-07-14 23:37 ` Simon Glass @ 2015-07-15 15:50 ` Stephen Warren 0 siblings, 0 replies; 27+ messages in thread From: Stephen Warren @ 2015-07-15 15:50 UTC (permalink / raw) To: u-boot On 07/14/2015 05:37 PM, Simon Glass wrote: > Hi Stephen, > > On 14 July 2015 at 17:27, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 07/14/2015 05:07 PM, Simon Glass wrote: >>> >>> Hi Stephen, >>> >>> On 14 July 2015 at 16:39, Stephen Warren <swarren@wwwdotorg.org> 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. >>> >>> >>> $ buildman seaboard >>> >>> will build U-Boot for seaboard. It does not copy the git tree. It puts >>> the output in ../current, or some other directory of your choosing. I >>> think that's pretty convenient. >> >> >> I'd prefer it to go in . so I don't get clutter outside my working tree. > > -o . > >> >>> For toolchains you can use >>> >>> $ buildman --fetch-arch arm >>> >>> to get a default one and set it up ready for use complete with config >>> file. >> >> >> I already have the toolchain I want to use installed, so I'd like a simple >> way to use it. >> >>> But honestly the config file is not that hard to figure out! >> >> >> Well perhaps if you understand its concepts/semantics, but I've always had >> an extremely hard time grasping it, and at least the last time I RTFMd there >> weren't any examples aimed at "this is how to write a config file to just >> use this binary name in $PATH". Equally, having to edit a config file any >> time I want to switch compilers is a bit annoying. > > Agreed. Perhaps annoying enough to contribute a patch? I recall vaguely looking at the buildman source to try and work out how the config file worked, but failing. Most likely, I'll just save off a shell snippet that runs "make xxx_config && make" and use that instead. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released) 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:33 ` Tom Rini 2015-07-15 15:31 ` Simon Glass 2015-07-15 15:50 ` [U-Boot] simple buildman usage Stephen Warren 1 sibling, 2 replies; 27+ messages in thread From: Tom Rini @ 2015-07-14 23:33 UTC (permalink / raw) To: u-boot 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? That much does work for finding cross tools installed into those paths. But if you have > 1 architecture toolchain in a single location buildman does fail there today. > I like the interface of just setting the CROSS_COMPILE variable, > since I can just set it in the environment and forget it if I want. > Perhaps buildman could just use it if it was set, and ignore the > config file (or again, a simple wrapper script could do that)? I do not want a wrapper script. Trying to make one thing act like another thing leads to madness and corner cases. That said, how hard would it be to have buildman see if CROSS_COMPILE is set and in turn force that to be used for all specified build targets? I thought about making it see what the value is and then heuristic which arch to use, but I think that's more error prone than perhaps buildman --default-tool-chain (Uses passed value or CROSS_COMPILE if set in env) ? -- 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/20150714/d15ab949/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released) 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 1 sibling, 0 replies; 27+ messages in thread From: Simon Glass @ 2015-07-15 15:31 UTC (permalink / raw) To: u-boot Hi Tom, On 14 July 2015 at 17:33, Tom Rini <trini@konsulko.com> 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? That much does work for finding cross tools installed into > those paths. But if you have > 1 architecture toolchain in a > single location buildman does fail there today. > > > I like the interface of just setting the CROSS_COMPILE variable, > > since I can just set it in the environment and forget it if I want. > > Perhaps buildman could just use it if it was set, and ignore the > > config file (or again, a simple wrapper script could do that)? > > I do not want a wrapper script. Trying to make one thing act like > another thing leads to madness and corner cases. That said, how hard > would it be to have buildman see if CROSS_COMPILE is set and in turn > force that to be used for all specified build targets? I thought about > making it see what the value is and then heuristic which arch to use, > but I think that's more error prone than perhaps buildman > --default-tool-chain (Uses passed value or CROSS_COMPILE if set in env) We can do that - is this a boolean value? What do you mean by 'passed value'? Regards, Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage 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 ` Stephen Warren 2015-07-15 15:54 ` Simon Glass 1 sibling, 1 reply; 27+ messages in thread From: Stephen Warren @ 2015-07-15 15:50 UTC (permalink / raw) To: u-boot 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:-) ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage 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 16:28 ` Stephen Warren 0 siblings, 2 replies; 27+ messages in thread From: Simon Glass @ 2015-07-15 15:54 UTC (permalink / raw) To: u-boot 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? Regards, Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage 2015-07-15 15:54 ` Simon Glass @ 2015-07-15 16:14 ` Tom Rini 2015-07-15 20:12 ` Stephen Warren 2015-07-15 16:28 ` Stephen Warren 1 sibling, 1 reply; 27+ messages in thread From: Tom Rini @ 2015-07-15 16:14 UTC (permalink / raw) To: u-boot 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? And that's the problem / hard part about having buildman do something with CROSS_COMPILE. CROSS_COMPILE is inherently single-arch. 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. -- 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/f97fe9b7/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage 2015-07-15 16:14 ` Tom Rini @ 2015-07-15 20:12 ` Stephen Warren 2015-07-15 20:45 ` Tom Rini 0 siblings, 1 reply; 27+ messages in thread From: Stephen Warren @ 2015-07-15 20:12 UTC (permalink / raw) To: u-boot 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. > 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. > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage 2015-07-15 20:12 ` Stephen Warren @ 2015-07-15 20:45 ` Tom Rini 0 siblings, 0 replies; 27+ messages in thread From: Tom Rini @ 2015-07-15 20:45 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage 2015-07-15 15:54 ` Simon Glass 2015-07-15 16:14 ` Tom Rini @ 2015-07-15 16:28 ` Stephen Warren 2015-07-15 17:50 ` Simon Glass 1 sibling, 1 reply; 27+ messages in thread From: Stephen Warren @ 2015-07-15 16:28 UTC (permalink / raw) To: u-boot On 07/15/2015 09:54 AM, 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? 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] simple buildman usage 2015-07-15 16:28 ` Stephen Warren @ 2015-07-15 17:50 ` Simon Glass 0 siblings, 0 replies; 27+ messages in thread From: Simon Glass @ 2015-07-15 17:50 UTC (permalink / raw) To: u-boot Hi Stephen, On 15 July 2015 at 10:28, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/15/2015 09:54 AM, 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? > > > 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. OK. Do you think Tom's idea works for you? Perhaps reply on that thread. I'm willing to work up a patch if yes as I assume your use case is not that unusual. Regards, Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [ANN] U-Boot v2015.07 released 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 20:14 ` Peter Robinson 2015-07-14 20:24 ` Nikolay Dimitrov 2015-07-15 7:15 ` Wolfgang Denk 2015-08-07 7:03 ` Wolfgang Denk 3 siblings, 1 reply; 27+ messages in thread From: Peter Robinson @ 2015-07-14 20:14 UTC (permalink / raw) To: u-boot Hi Tom, On Tue, Jul 14, 2015 at 6:56 PM, Tom Rini <trini@konsulko.com> wrote: > Hey all, > > I've pushed v2015.07 out to the repository and tarballs should exist > soon. I don't see the release tag in git either by doing a pull from my checkout or via the web interface. Does it take time to sync? Peter > 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. > > Finally, I would encourage custodians to follow-up with anything big I've > overlooked. > > Thanks for the hard work everyone! The merge window is now open and > will close on Saturday Aug 1st. > > -- > Tom > > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [ANN] U-Boot v2015.07 released 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 0 siblings, 2 replies; 27+ messages in thread From: Nikolay Dimitrov @ 2015-07-14 20:24 UTC (permalink / raw) To: u-boot Hi Tom, On 07/14/2015 11:14 PM, Peter Robinson wrote: > Hi Tom, > > On Tue, Jul 14, 2015 at 6:56 PM, Tom Rini <trini@konsulko.com> wrote: >> Hey all, >> >> I've pushed v2015.07 out to the repository and tarballs should exist >> soon. > > I don't see the release tag in git either by doing a pull from my > checkout or via the web interface. Does it take time to sync? > > Peter Same here, the release tag is missing. Kind regards, Nikolay ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [ANN] U-Boot v2015.07 released 2015-07-14 20:24 ` Nikolay Dimitrov @ 2015-07-14 20:59 ` Robert Nelson 2015-07-14 22:02 ` Tom Rini 1 sibling, 0 replies; 27+ messages in thread From: Robert Nelson @ 2015-07-14 20:59 UTC (permalink / raw) To: u-boot On Tue, Jul 14, 2015 at 3:24 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote: > Hi Tom, > > On 07/14/2015 11:14 PM, Peter Robinson wrote: >> >> Hi Tom, >> >> On Tue, Jul 14, 2015 at 6:56 PM, Tom Rini <trini@konsulko.com> wrote: >>> >>> Hey all, >>> >>> I've pushed v2015.07 out to the repository and tarballs should exist >>> soon. >> >> >> I don't see the release tag in git either by doing a pull from my >> checkout or via the web interface. Does it take time to sync? >> >> Peter > > > Same here, the release tag is missing. The public repo is on a 6 hour cron job, give it a few more hours.. Regards, -- Robert Nelson https://rcn-ee.com/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [ANN] U-Boot v2015.07 released 2015-07-14 20:24 ` Nikolay Dimitrov 2015-07-14 20:59 ` Robert Nelson @ 2015-07-14 22:02 ` Tom Rini 1 sibling, 0 replies; 27+ messages in thread From: Tom Rini @ 2015-07-14 22:02 UTC (permalink / raw) To: u-boot On Tue, Jul 14, 2015 at 11:24:52PM +0300, Nikolay Dimitrov wrote: > Hi Tom, > > On 07/14/2015 11:14 PM, Peter Robinson wrote: > >Hi Tom, > > > >On Tue, Jul 14, 2015 at 6:56 PM, Tom Rini <trini@konsulko.com> wrote: > >>Hey all, > >> > >>I've pushed v2015.07 out to the repository and tarballs should exist > >>soon. > > > >I don't see the release tag in git either by doing a pull from my > >checkout or via the web interface. Does it take time to sync? > > > >Peter > > Same here, the release tag is missing. Yes, there is a delay between push and sync to git.denx.de. -- 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/20150714/91ea3533/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [ANN] U-Boot v2015.07 released 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 20:14 ` [U-Boot] [ANN] U-Boot v2015.07 released Peter Robinson @ 2015-07-15 7:15 ` Wolfgang Denk 2015-07-29 0:54 ` Simon Glass 2015-08-07 7:03 ` Wolfgang Denk 3 siblings, 1 reply; 27+ messages in thread From: Wolfgang Denk @ 2015-07-15 7:15 UTC (permalink / raw) To: u-boot Dear Tom, In message <20150714175627.GJ23886@bill-the-cat> you wrote: > > I've pushed v2015.07 out to the repository and tarballs should exist > soon. Tarballs are both on the ACD [1] and the FTP server [2]. [1] https://www.amazon.com/clouddrive/share/zgc1Jd4CgnLfkP0DypkZAvXAM8Hz3IOiHbM9edV1PB8?ref_=cd_share_link_copy [2] ftp://ftp.denx.de/pub/u-boot/u-boot-2015.07.tar.bz2 Thanks! Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de backups: always in season, never out of style. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [ANN] U-Boot v2015.07 released 2015-07-15 7:15 ` Wolfgang Denk @ 2015-07-29 0:54 ` Simon Glass 0 siblings, 0 replies; 27+ messages in thread From: Simon Glass @ 2015-07-29 0:54 UTC (permalink / raw) To: u-boot Hi Wolfgang, On 15 July 2015 at 01:15, Wolfgang Denk <wd@denx.de> wrote: > Dear Tom, > > In message <20150714175627.GJ23886@bill-the-cat> you wrote: >> >> I've pushed v2015.07 out to the repository and tarballs should exist >> soon. > > Tarballs are both on the ACD [1] and the FTP server [2]. > > [1] https://www.amazon.com/clouddrive/share/zgc1Jd4CgnLfkP0DypkZAvXAM8Hz3IOiHbM9edV1PB8?ref_=cd_share_link_copy > [2] ftp://ftp.denx.de/pub/u-boot/u-boot-2015.07.tar.bz2 > > Thanks! > > > Wolfgang Denk I don't see the normal statistics - are they coming? Regards, Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [ANN] U-Boot v2015.07 released 2015-07-14 17:56 [U-Boot] [ANN] U-Boot v2015.07 released Tom Rini ` (2 preceding siblings ...) 2015-07-15 7:15 ` Wolfgang Denk @ 2015-08-07 7:03 ` Wolfgang Denk 2015-08-07 8:11 ` Jagan Teki 3 siblings, 1 reply; 27+ messages in thread From: Wolfgang Denk @ 2015-08-07 7:03 UTC (permalink / raw) To: u-boot Dear Tom, In message <20150714175627.GJ23886@bill-the-cat> you wrote: > > I've pushed v2015.07 out to the repository and tarballs should exist > soon. Here finally the release statistics - sorry this took so long. For the full list please see [1]. [1] http://www.denx.de/wiki/U-Boot/UbootStat_2015_07 Processed 1563 csets from 156 developers 24 employers found A total of 176355 lines added, 44130 removed (delta 132225) Developers with the most changesets Simon Glass 311 (19.9%) Joe Hershberger 111 (7.1%) Hans de Goede 106 (6.8%) Tim Harvey 77 (4.9%) Masahiro Yamada 68 (4.4%) Bin Meng 56 (3.6%) Jagannadh Teki 44 (2.8%) Przemyslaw Marczak 43 (2.8%) Paul Kocialkowski 42 (2.7%) Kishon Vijay Abraham I 41 (2.6%) ... Developers with the most changed lines Masahiro Yamada 56181 (28.7%) Simon Glass 22872 (11.7%) Hans de Goede 19807 (10.1%) Kishon Vijay Abraham I 15720 (8.0%) Joe Hershberger 13351 (6.8%) Prabhakar Kushwaha 6857 (3.5%) Przemyslaw Marczak 6471 (3.3%) Stefan Roese 3275 (1.7%) Bin Meng 3114 (1.6%) Haikun Wang 3058 (1.6%) ... Developers with the most lines removed Andreas Bie?mann 2018 (4.6%) Angelo Dureghello 1628 (3.7%) Stefan Roese 1117 (2.5%) Peter Robinson 1105 (2.5%) Jagannadh Teki 1001 (2.3%) Ian Campbell 354 (0.8%) Valentin Longchamp 116 (0.3%) Lars Poeschel 52 (0.1%) Jagannadha Sutradharudu Teki 41 (0.1%) Stephen Warren 15 (0.0%) ... Developers with the most signoffs (total 302) Tom Warren 60 (19.9%) Hans de Goede 55 (18.2%) Michal Simek 19 (6.3%) York Sun 19 (6.3%) Tom Rini 10 (3.3%) Nishanth Menon 9 (3.0%) Rabeeh Khoury 8 (2.6%) Andre Przywara 6 (2.0%) Rob Herring 5 (1.7%) Radha Mohan Chintakuntla 5 (1.7%) ... Developers with the most reviews (total 486) Simon Glass 101 (20.8%) Marek Vasut 88 (18.1%) Tom Rini 80 (16.5%) York Sun 50 (10.3%) ?ukasz Majewski 41 (8.4%) Bin Meng 38 (7.8%) Hans de Goede 15 (3.1%) Joe Hershberger 14 (2.9%) Jagannadha Sutradharudu Teki 13 (2.7%) Jagannadh Teki 12 (2.5%) ... Developers with the most test credits (total 127) Simon Glass 17 (13.4%) Kevin Smith 14 (11.0%) Dirk Eibach 13 (10.2%) Thierry Reding 11 (8.7%) Ian Campbell 11 (8.7%) Vagrant Cascadian 9 (7.1%) Jagannadh Teki 8 (6.3%) Haikun Wang 6 (4.7%) Bin Meng 4 (3.1%) Joe Hershberger 3 (2.4%) ... Developers who gave the most tested-by credits (total 127) Stefan Roese 27 (21.3%) Jan Kiszka 18 (14.2%) Fabio Estevam 11 (8.7%) Przemyslaw Marczak 11 (8.7%) Simon Glass 8 (6.3%) Haikun Wang 8 (6.3%) Ian Campbell 6 (4.7%) Jagannadh Teki 5 (3.9%) Heiko Schocher 4 (3.1%) Bin Meng 3 (2.4%) ... Developers with the most report credits (total 21) Simon Glass 5 (23.8%) Joe Hershberger 2 (9.5%) Ingrid Viitanen 2 (9.5%) Haikun Wang 1 (4.8%) Bin Meng 1 (4.8%) Tim Harvey 1 (4.8%) Michal Simek 1 (4.8%) Pavel Machek 1 (4.8%) Vagrant Cascadian 1 (4.8%) Maxin B. John 1 (4.8%) ... Developers who gave the most report credits (total 21) Simon Glass 7 (33.3%) Joe Hershberger 5 (23.8%) Lokesh Vutla 3 (14.3%) Fabio Estevam 2 (9.5%) Tom Rini 1 (4.8%) Jagannadha Sutradharudu Teki 1 (4.8%) Daniel Schwierzeck 1 (4.8%) Hans de Goede 1 (4.8%) Top changeset contributors by employer (Unknown) 571 (36.5%) Google, Inc. 312 (20.0%) Freescale 151 (9.7%) National Instruments 111 (7.1%) Red Hat 106 (6.8%) Texas Instruments 81 (5.2%) DENX Software Engineering 73 (4.7%) Samsung 65 (4.2%) Xilinx 25 (1.6%) Siemens 14 (0.9%) ... Top lines changed by employer (Unknown) 86637 (44.3%) Google, Inc. 22901 (11.7%) Red Hat 19807 (10.1%) Freescale 19443 (9.9%) Texas Instruments 17540 (9.0%) National Instruments 13351 (6.8%) Samsung 6796 (3.5%) DENX Software Engineering 6241 (3.2%) Xilinx 890 (0.5%) Siemens 412 (0.2%) ... Employers with the most signoffs (total 302) (Unknown) 61 (20.2%) NVidia 60 (19.9%) Red Hat 55 (18.2%) Freescale 51 (16.9%) Texas Instruments 22 (7.3%) Xilinx 20 (6.6%) Samsung 10 (3.3%) Siemens 7 (2.3%) Google, Inc. 5 (1.7%) Renesas Electronics 5 (1.7%) ... Employers with the most hackers (total 158) (Unknown) 81 (51.3%) Freescale 25 (15.8%) Texas Instruments 9 (5.7%) Samsung 6 (3.8%) DENX Software Engineering 5 (3.2%) Linaro 5 (3.2%) Xilinx 3 (1.9%) Marvell 3 (1.9%) NVidia 2 (1.3%) Siemens 2 (1.3%) ... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de That was the thing about deserts. They had their own gravity. They sucked you into the centre. - Terry Pratchett, _Small Gods_ ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [ANN] U-Boot v2015.07 released 2015-08-07 7:03 ` Wolfgang Denk @ 2015-08-07 8:11 ` Jagan Teki 2015-08-07 14:15 ` Wolfgang Denk 0 siblings, 1 reply; 27+ messages in thread From: Jagan Teki @ 2015-08-07 8:11 UTC (permalink / raw) To: u-boot On 7 August 2015 at 12:33, Wolfgang Denk <wd@denx.de> wrote: > Dear Tom, > > In message <20150714175627.GJ23886@bill-the-cat> you wrote: >> >> I've pushed v2015.07 out to the repository and tarballs should exist >> soon. > > Here finally the release statistics - sorry this took so long. For > the full list please see [1]. > > [1] http://www.denx.de/wiki/U-Boot/UbootStat_2015_07 > > > Processed 1563 csets from 156 developers > 24 employers found > A total of 176355 lines added, 44130 removed (delta 132225) > > Developers with the most changesets > Simon Glass 311 (19.9%) > Joe Hershberger 111 (7.1%) > Hans de Goede 106 (6.8%) > Tim Harvey 77 (4.9%) > Masahiro Yamada 68 (4.4%) > Bin Meng 56 (3.6%) > Jagannadh Teki 44 (2.8%) > Przemyslaw Marczak 43 (2.8%) > Paul Kocialkowski 42 (2.7%) > Kishon Vijay Abraham I 41 (2.6%) > ... > > Developers with the most changed lines > Masahiro Yamada 56181 (28.7%) > Simon Glass 22872 (11.7%) > Hans de Goede 19807 (10.1%) > Kishon Vijay Abraham I 15720 (8.0%) > Joe Hershberger 13351 (6.8%) > Prabhakar Kushwaha 6857 (3.5%) > Przemyslaw Marczak 6471 (3.3%) > Stefan Roese 3275 (1.7%) > Bin Meng 3114 (1.6%) > Haikun Wang 3058 (1.6%) > ... > > Developers with the most lines removed > Andreas Bie?mann 2018 (4.6%) > Angelo Dureghello 1628 (3.7%) > Stefan Roese 1117 (2.5%) > Peter Robinson 1105 (2.5%) > Jagannadh Teki 1001 (2.3%) > Ian Campbell 354 (0.8%) > Valentin Longchamp 116 (0.3%) > Lars Poeschel 52 (0.1%) > Jagannadha Sutradharudu Teki 41 (0.1%) > Stephen Warren 15 (0.0%) > ... > > Developers with the most signoffs (total 302) > Tom Warren 60 (19.9%) > Hans de Goede 55 (18.2%) > Michal Simek 19 (6.3%) > York Sun 19 (6.3%) > Tom Rini 10 (3.3%) > Nishanth Menon 9 (3.0%) > Rabeeh Khoury 8 (2.6%) > Andre Przywara 6 (2.0%) > Rob Herring 5 (1.7%) > Radha Mohan Chintakuntla 5 (1.7%) > ... > > Developers with the most reviews (total 486) > Simon Glass 101 (20.8%) > Marek Vasut 88 (18.1%) > Tom Rini 80 (16.5%) > York Sun 50 (10.3%) > ?ukasz Majewski 41 (8.4%) > Bin Meng 38 (7.8%) > Hans de Goede 15 (3.1%) > Joe Hershberger 14 (2.9%) > Jagannadha Sutradharudu Teki 13 (2.7%) > Jagannadh Teki 12 (2.5%) > ... > > Developers with the most test credits (total 127) > Simon Glass 17 (13.4%) > Kevin Smith 14 (11.0%) > Dirk Eibach 13 (10.2%) > Thierry Reding 11 (8.7%) > Ian Campbell 11 (8.7%) > Vagrant Cascadian 9 (7.1%) > Jagannadh Teki 8 (6.3%) > Haikun Wang 6 (4.7%) > Bin Meng 4 (3.1%) > Joe Hershberger 3 (2.4%) > ... > > Developers who gave the most tested-by credits (total 127) > Stefan Roese 27 (21.3%) > Jan Kiszka 18 (14.2%) > Fabio Estevam 11 (8.7%) > Przemyslaw Marczak 11 (8.7%) > Simon Glass 8 (6.3%) > Haikun Wang 8 (6.3%) > Ian Campbell 6 (4.7%) > Jagannadh Teki 5 (3.9%) > Heiko Schocher 4 (3.1%) > Bin Meng 3 (2.4%) > ... > > Developers with the most report credits (total 21) > Simon Glass 5 (23.8%) > Joe Hershberger 2 (9.5%) > Ingrid Viitanen 2 (9.5%) > Haikun Wang 1 (4.8%) > Bin Meng 1 (4.8%) > Tim Harvey 1 (4.8%) > Michal Simek 1 (4.8%) > Pavel Machek 1 (4.8%) > Vagrant Cascadian 1 (4.8%) > Maxin B. John 1 (4.8%) > ... > > Developers who gave the most report credits (total 21) > Simon Glass 7 (33.3%) > Joe Hershberger 5 (23.8%) > Lokesh Vutla 3 (14.3%) > Fabio Estevam 2 (9.5%) > Tom Rini 1 (4.8%) > Jagannadha Sutradharudu Teki 1 (4.8%) > Daniel Schwierzeck 1 (4.8%) > Hans de Goede 1 (4.8%) > > Top changeset contributors by employer > (Unknown) 571 (36.5%) > Google, Inc. 312 (20.0%) > Freescale 151 (9.7%) > National Instruments 111 (7.1%) > Red Hat 106 (6.8%) > Texas Instruments 81 (5.2%) > DENX Software Engineering 73 (4.7%) > Samsung 65 (4.2%) > Xilinx 25 (1.6%) > Siemens 14 (0.9%) > ... > > Top lines changed by employer > (Unknown) 86637 (44.3%) > Google, Inc. 22901 (11.7%) > Red Hat 19807 (10.1%) > Freescale 19443 (9.9%) > Texas Instruments 17540 (9.0%) > National Instruments 13351 (6.8%) > Samsung 6796 (3.5%) > DENX Software Engineering 6241 (3.2%) > Xilinx 890 (0.5%) > Siemens 412 (0.2%) > ... > > Employers with the most signoffs (total 302) > (Unknown) 61 (20.2%) > NVidia 60 (19.9%) > Red Hat 55 (18.2%) > Freescale 51 (16.9%) > Texas Instruments 22 (7.3%) > Xilinx 20 (6.6%) > Samsung 10 (3.3%) > Siemens 7 (2.3%) > Google, Inc. 5 (1.7%) > Renesas Electronics 5 (1.7%) > ... Any idea why would openedev missing on employer, does we need to indicate some where as all code was s-o-b openedev.com > > Employers with the most hackers (total 158) > (Unknown) 81 (51.3%) > Freescale 25 (15.8%) > Texas Instruments 9 (5.7%) > Samsung 6 (3.8%) > DENX Software Engineering 5 (3.2%) > Linaro 5 (3.2%) > Xilinx 3 (1.9%) > Marvell 3 (1.9%) > NVidia 2 (1.3%) > Siemens 2 (1.3%) > ... > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de > That was the thing about deserts. They had their own gravity. They > sucked you into the centre. - Terry Pratchett, _Small Gods_ > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot thanks! -- Jagan | openedev. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [ANN] U-Boot v2015.07 released 2015-08-07 8:11 ` Jagan Teki @ 2015-08-07 14:15 ` Wolfgang Denk 0 siblings, 0 replies; 27+ messages in thread From: Wolfgang Denk @ 2015-08-07 14:15 UTC (permalink / raw) To: u-boot Dear Jagan, In message <CAD6G_RTB0KyiYMWv5_jQ0VPzJ3P+5vYPgrYwsLUAX=gYgOfeSA@mail.gmail.com> you wrote: > > Any idea why would openedev missing on employer, does we need to > indicate some where > as all code was s-o-b openedev.com openedev.com has no entry in the domain-map. What should I add? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de When the ax entered the forest, the trees said, "The handle is one of us!" -- Turkish proverb ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2015-08-07 14:15 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.