[U-Boot] [ANN] U-Boot v2015.07 released
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.
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?
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?
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)?
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
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.
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.
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
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.
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) ?
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
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:-)
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
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.
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.
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.
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.
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
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@lists.denx.de http://lists.denx.de/mailman/listinfo/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
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,
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.
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/zgc1Jd4CgnLfkP0DypkZAvXAM8Hz3IOiHbM9... [2] ftp://ftp.denx.de/pub/u-boot/u-boot-2015.07.tar.bz2
Thanks!
Wolfgang Denk
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/zgc1Jd4CgnLfkP0DypkZAvXAM8Hz3IOiHbM9... [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
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
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@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
thanks!
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
participants (8)
-
Jagan Teki -
Nikolay Dimitrov -
Peter Robinson -
Robert Nelson -
Simon Glass -
Stephen Warren -
Tom Rini -
Wolfgang Denk