linux/uboot: add support for custom Mercurial repositories
PATCH v4 1/1 linux/uboot: add support for custom Mercurial repositories
Hi,
This series adds support for custom Mercurial repositories in uboot and linux packages.
This version is rebased with the 2013.08 master, there are only a few real changes.
Best regards,
Thomas
Config.in.legacy | 139 +++++++++++++++++++++++++++++++-- boot/barebox/Config.in | 4 +- boot/uboot/Config.in | 37 +++++--- boot/uboot/uboot.mk | 5 +- configs/arm_foundationv8_defconfig | 4 +- configs/beaglebone_defconfig | 4 +- configs/calao_snowball_defconfig | 4 +- configs/cubieboard_defconfig | 8 +- configs/ea3250_defconfig | 8 +- configs/fdi3250_defconfig | 8 +- configs/gnublin_defconfig | 8 +- configs/mx53loco_defconfig | 8 +- configs/phy3250_defconfig | 8 +- configs/rpi_defconfig | 4 +- fs/jffs2/Config.in | 4 +- linux/Config.in | 38 ++++++-- linux/linux.mk | 5 +- package/gcc/Config.in.host | 2 +- package/linux-headers/Config.in.host | 2 +- package/uclibc/Config.in | 2 +- toolchain/toolchain-external/Config.in | 2 +- 21 files changed, 225 insertions(+), 79 deletions(-)
PATCH v4 1/1 Config.in.legacy: update description for developers
The existing comments in Config.in.legacy are not entirely in-line with current practice. The comments implies that BR2_LEGACY should not be set when the conversion from old-to-new symbol can be done automatically using the appropriate 'select' statements. However, none of the existing legacy options does it this way. Moreover, I think it's intentional that the user is notified of the change, so that the removal of the legacy options in later buildroot versions no longer poses a problem.
Additionally, the comments now describe how to handle string options.
---
v4: no changes
v3:
- reorganize description
- update string description for automatic propagation
- extend string example
- 'depends on BR2_LEGACY' --> 'select BR2_LEGACY' (spotted by Arnout)
(v2): new patch in this series
Config.in.legacy | 50 +++++++++++++++++++++++++++++++++++++++++++------- 1 files changed, 43 insertions(+), 7 deletions(-)
Config.in.legacy +43 -7
@@ -1,13 +1,9 @@ # # Config.in.legacy - support for backward compatibility # -# When an existing Config.in symbol is removed, it should be added again in this -# file, and take appropriate action to approximate backward compatibility. If -# there is an equivalent (set of) new symbols, these can just be select'ed by -# the old symbol. This makes sure that running 'make oldconfig' will make things -# "just work" when upgrading to a new buildroot version. If the change is too -# fundamental and cannot be fixed by a simple select, then the old symbol should -# select BR2_LEGACY. If that symbol is set, the build will issue an error. +# When an existing Config.in symbol is removed, it should be added again in +# this file, and take appropriate action to approximate backward compatibility. +# This will make the transition for the user more convenient. # # When adding legacy symbols to this file, add them to the front. The oldest # symbols will be removed again after about two years.
@@ -15,6 +11,46 @@ # The symbol should be copied as-is from the place where it was previously # defined, but the help text should be removed or replaced with something that # explains how to fix it. +# +# For bool options, the old symbol should select BR2_LEGACY, so that the user +# is informed at build-time about selected legacy options. +# If there is an equivalent (set of) new symbols, these should be select'ed by +# the old symbol for backwards compatibility. +# +# For string options, it is not possible to directly select another symbol. In +# this case, a hidden wrap bool option has to be added, that defaults to y if +# the old string is not set at its default value. The wrap symbol should select +# BR2_LEGACY. +# If the original symbol has been renamed, the new symbol should use the value +# of the old symbol as default. This requires a change outside of +# Config.in.legacy, and this should be clearly marked as such below, so that +# removal of legacy options also include the removal of these external +# references. +# +# [Example: renaming a string option from FOO to BAR] +# original symbol: +# config BR2_FOO_STRING +# string "Some foo string" +# +# becomes: +# config BR2_BAR_STRING +# string "Some bar string" +# default BR2_FOO_STRING if BR2_FOO_STRING != "" # legacy +# +# and in Config.in.legacy: +# config BR2_FOO_STRING +# string "The foo string has been renamed" +# help +# <suitable help text> +# +# config BR2_FOO_STRING_WRAP +# bool +# default y if BR2_FOO_STRING != "" +# select BR2_LEGACY +# +# # Note: BR2_FOO_STRING is still referenced from package/foo/Config.in +# +# [End of example] config BR2_LEGACY bool
PATCH v4 1/1 Config.in.legacy: update description for developers
Dear Thomas De Schampheleire,
Quoted 7 lines · Thomas De Schampheleire
The existing comments in Config.in.legacy are not entirely in-line with current practice. The comments implies that
BR2_LEGACYshould not be set when the conversion from old-to-new symbol can be done automatically using the appropriate 'select' statements. However, none of the existing legacy options does it this way. Moreover, I think it's intentional that the user is notified of the change, so that the removal of the legacy options in later buildroot versions no longer poses a problem.
Does what we are doing today really makes sense? For example, option BR2_PACKAGE_FOO_BAR is renamed to BR2_PACKAGE_FOO_BARBLEH. BR2_PACKAGE_FOO_BAR is added to Config.in.legacy, with a message like "Option bar for package foo has been renamed barbleh". So the user goes into the sub-options of package "foo"... and discovers that barbleh is already enabled. So he kind of wonders what sort of drug Buildroot developers are taking, no?
When there is a direct 1:1 mapping between the old option and the new option, is it really necessary to select BR2_LEGACY ?
Shouldn't be select BR2_LEGACY only when there is really a change in behavior (like a package has been entirely removed, or a feature like toolchain on target has been removed) ?
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 1/1 Config.in.legacy: update description for developers
Hi Thomas, all,
Quoted 12 lines · Thomas Petazzoni
Dear Thomas De Schampheleire,
Quoted 7 lines · Thomas De Schampheleire
The existing comments in Config.in.legacy are not entirely in-line with current practice. The comments implies that
BR2_LEGACYshould not be set when the conversion from old-to-new symbol can be done automatically using the appropriate 'select' statements. However, none of the existing legacy options does it this way. Moreover, I think it's intentional that the user is notified of the change, so that the removal of the legacy options in later buildroot versions no longer poses a problem.
Quoted 7 lines
Does what we are doing today really makes sense? For example, option
BR2_PACKAGE_FOO_BARis renamed toBR2_PACKAGE_FOO_BARBLEH.BR2_PACKAGE_FOO_BARis added to Config.in.legacy, with a message like "Option bar for package foo has been renamed barbleh". So the user goes into the sub-options of package "foo"... and discovers that barbleh is already enabled. So he kind of wonders what sort of drug Buildroot developers are taking, no?
:-D
Quoted 7 lines
When there is a direct 1:1 mapping between the old option and the new option, is it really necessary to select
BR2_LEGACY?Shouldn't be select
BR2_LEGACYonly when there is really a change in behavior (like a package has been entirely removed, or a feature like toolchain on target has been removed) ?
I think there are only a few options:
1. Don't ever rename or remove symbols (so no legacy problems ever). I don't think this is feasible/desirable.
2. Allow symbols to be renamed/removed if there is a good reason for it, but only mention it in the README or Changelog when there is a new release (no legacy menu). In this case, the user is completely on his own when migrating to another buildroot release, every action is manual. This was the situation before the legacy menu was introduced.
3. Use a legacy menu for renamed/removed symbols, indicating which symbols are now legacy. Don't do any automatic propagation of old to new symbols: simply warn the user and let him/her review and update the configuration. This is the simplest to implement, there are also no problems with weird kconfig behavior. By disabling the legacy option, the user simply acknowledges that he has seen the legacy messages, and the rest of the configuration remains untouched.
4. Use a legacy menu as in 3., but additionally perform automatic propagation of old to new symbols where possible and appropriate. This means 'select'ing the right symbols, and also introducing the following kconfig behavior: if you disable the legacy option that automatically selected the new symbol, the new symbol will be disabled too if you did not save your configuration yet (see my other patch and the resulting discussion). This is what is done at the moment, and this is the same path my patch series was continuing on.
5. Use a legacy menu only for symbols that cannot be automatically propagated. For all other legacy symbols, do the automatic propagation but do not inform the user. Here you will still have an old symbol 'select'ing the new one, and the old symbol should remain hidden (I think, to not confuse the user). I haven't tried this yet, but in my understanding the old symbol will remain selected, and will also be part of the defconfig. This would be confusing.
Since in this case there is no communication to the user, I think there can be a problem with migration of defconfigs. Consider the
following: a user starts with buildroot version A, saves his project's defconfig. Then he migrates to version B, in which some symbols have been marked as legacy, but automatically propagated. The user does not see a reason to update his defconfig as everything still works and he doesn't know better. Then, he migrates to buildroot version C, where the legacy symbols have suddenly been removed. Since his defconfig was not changed, there is no reference to the new alternatives of the legacy symbols, and his configuration is suddenly dysfunctional. I think this is not very nice.
If the user would have been warned between the A->B transition, he would have realized he needed to save a new defconfig, and the transition from B->C would be successful.
As it stands, I'm leaning towards 3 or 4, but am open for discussion.
Best regards,
Thomas
PATCH v4 1/1 Config.in.legacy: update description for developers
Quoted 4 lines · Thomas De Schampheleire
Hi Thomas, all,
On Mon, Sep 2, 2013 at 10:54 PM, Thomas Petazzoni
<[email protected]> wrote:
[snip]
Quoted 8 lines
Quoted 6 lines
When there is a direct 1:1 mapping between the old option and the new option, is it really necessary to select
BR2_LEGACY?Shouldn't be select
BR2_LEGACYonly when there is really a change in behavior (like a package has been entirely removed, or a feature like toolchain on target has been removed) ?I think there are only a few options:
Nice analysis!
Quoted 2 lines
1. Don't ever rename or remove symbols (so no legacy problems ever). I don't think this is feasible/desirable.
This was actually more or less the intention when the Config.in.legacy
was introduced. It was not really intended for giving Kconfig symbols more consistent names. Instead, it was intended to have a path forward in a situation as for gettext/libintl. There used to be a BR2_PACKAGE_LIBINTL symbol, which actually enabled an option in the gettext package instead of selecting the libintl package.
Peter's point of view was/is that the Kconfig symbols are not visible
to the user, so the user doesn't care about inconsistencies there. However, if a symbol is renamed, it suddenly does become visible to the user (even with the current legacy approach), so that should be avoided.
Quoted 23 lines
2. Allow symbols to be renamed/removed if there is a good reason for it, but only mention it in the README or Changelog when there is a new release (no legacy menu). In this case, the user is completely on his own when migrating to another buildroot release, every action is manual. This was the situation before the legacy menu was introduced.
3. Use a legacy menu for renamed/removed symbols, indicating which symbols are now legacy. Don't do any automatic propagation of old to new symbols: simply warn the user and let him/her review and update the configuration. This is the simplest to implement, there are also no problems with weird kconfig behavior. By disabling the legacy option, the user simply acknowledges that he has seen the legacy messages, and the rest of the configuration remains untouched.
4. Use a legacy menu as in 3., but additionally perform automatic propagation of old to new symbols where possible and appropriate. This means 'select'ing the right symbols, and also introducing the following kconfig behavior: if you disable the legacy option that automatically selected the new symbol, the new symbol will be disabled too if you did not save your configuration yet (see my other patch and the resulting discussion). This is what is done at the moment, and this is the same path my patch series was continuing on.
Quoted 7 lines
5. Use a legacy menu only for symbols that cannot be automatically propagated. For all other legacy symbols, do the automatic propagation but do not inform the user. Here you will still have an old symbol 'select'ing the new one, and the old symbol should remain hidden (I think, to not confuse the user). I haven't tried this yet, but in my understanding the old symbol will remain selected, and will also be part of the defconfig. This would be confusing.
It's even worse.
The option _must_ remain visible, otherwise it is stripped from the
.config when it is read in.
Also, when a defconfig is saved, it will be saved under the old name
and the new name will not appear in the defconfig. So if the legacy part is removed a couple of years down the line, users who rely on defconfigs are screwed.
IMHO, Kconfig is just too limited to do all the things we want to do.
Quoted 16 lines
Since in this case there is no communication to the user, I think there can be a problem with migration of defconfigs. Consider the
following: a user starts with buildroot version A, saves his project's defconfig. Then he migrates to version B, in which some symbols have been marked as legacy, but automatically propagated. The user does not see a reason to update his defconfig as everything still works and he doesn't know better. Then, he migrates to buildroot version C, where the legacy symbols have suddenly been removed. Since his defconfig was not changed, there is no reference to the new alternatives of the legacy symbols, and his configuration is suddenly dysfunctional. I think this is not very nice.
If the user would have been warned between theA->Btransition, he would have realized he needed to save a new defconfig, and the transition fromB->Cwould be successful.
Quoted 1 line
As it stands, I'm leaning towards 3 or 4, but am open for discussion.
I prefer to keep things as they are, i.e. option 4.
I'm also in favour of minimizing the number of simple renames. For
instance, I think the rename of BR2_PACKAGE_DOSFSTOOLS_DOSFSCK was unnecessary.
Regards,
Arnout
Quoted 5 lines
Best regards,
Thomas
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH v4 1/1 Config.in.legacy: update description for developers
In reply to Thomas De SchampheleireQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Hi,
Quoted 11 lines
The existing comments in Config.in.legacy are not entirely in-line with current practice. The comments implies that
BR2_LEGACYshould not be set when the conversion from old-to-new symbol can be done automatically using the appropriate 'select' statements. However, none of the existing legacy options does it this way. Moreover, I think it's intentional that the user is notified of the change, so that the removal of the legacy options in later buildroot versions no longer poses a problem.
Additionally, the comments now describe how to handle string options.
(Finally) committed series with some minor fixups to get them to apply, thanks!
Signature · 1 line
Bye, Peter Korsgaard
PATCH v4 1/1 Config.in.legacy: update description for developers
Quoted 13 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Hi,
Quoted 8 lines
The existing comments in Config.in.legacy are not entirely in-line with current practice. The comments implies that
BR2_LEGACYshould not be set when the conversion from old-to-new symbol can be done automatically using the appropriate 'select' statements. However, none of the existing legacy options does it this way. Moreover, I think it's intentional that the user is notified of the change, so that the removal of the legacy options in later buildroot versions no longer poses a problem.
Additionally, the comments now describe how to handle string options.
Quoted 5 lines
Quoted 2 lines
(Finally) committed series with some minor fixups to get them to apply, thanks!
Thanks Peter! (and also thanks to the other fabulous people present at the Buildroot Developer Days :-) )
PATCH v4 1/1 Config.in.legacy: update description for users
In reply to Thomas De SchampheleireThis patch clarifies the message shown to users in the legacy menu. It explicitly mentions the need to save the configuration before disabling the legacy options.
---
v4: - reorder paragraphs (and modify text a bit to suit this new order)
- add "Once you have removed all ..." sentence
- add vertical whitespace (I used the least visible * symbol to preserve whitespace)
(all comments from Arnout)
(v3): new patch in this series
Config.in.legacy | 24 ++++++++++++++++++++---- 1 files changed, 20 insertions(+), 4 deletions(-)
Config.in.legacy +20 -4
@@ -69,11 +69,27 @@ menu "Legacy config options" if BR2_LEGACY comment "Your old configuration uses legacy options that no " -comment "longer exist in buildroot. " -comment "Please look at the options which have been selected " -comment "and read their help text. " -comment "As long as these options stay selected, the build " +comment "longer exist in buildroot, as indicated in the menu " +comment "below. As long as these options stay selected, or in" +comment "case of string options are non-empty, the build " comment "will fail. " +comment "* " +comment "Where possible, an automatic conversion from old to " +comment "new symbols has been performed. Before making any " +comment "change in this legacy menu, make sure to exit the " +comment "configuration editor a first time and save the " +comment "configuration. Otherwise, the automatic conversion " +comment "of symbols will be lost. " +comment "* " +comment "After this initial save, reopen the configuration " +comment "editor, inspect the options selected below, read " +comment "their help texts, and verify/update the new " +comment "configuration in the corresponding configuration " +comment "menus. When everything is ok, you can disable the " +comment "legacy options in the menu below. Once you have " +comment "disabled all legacy options, this text will " +comment "disappear and you will be able to start the build. " +comment "* " comment "Note: at some point in the future, the oldest legacy" comment "options will be removed, and configuration files " comment "that still have those options set, will fail to "
PATCH v4 1/1 Config.in.legacy: update description for users
Dear Thomas De Schampheleire,
Quoted 7 lines · Thomas De Schampheleire
if
BR2_LEGACY
comment "Your old configuration uses legacy options that no "Config.in.legacy +1
-4-comment "longer exist in buildroot. " -comment "Please look at the options which have been selected " -comment "and read their help text. " -comment "As long as these options stay selected, the build " +comment "longer exist in buildroot, as indicated in the menu "
Config.in.legacy menu "Legacy config options" · line 82
Quoted 10 lines
Config.in.legacy +9
-0+comment "below. As long as these options stay selected, or in" +comment "case of string options are non-empty, the build " comment "will fail. " +comment "* " +comment "Where possible, an automatic conversion from old to " +comment "new symbols has been performed. Before making any " +comment "change in this legacy menu, make sure to exit the " +comment "configuration editor a first time and save the " +comment "configuration. Otherwise, the automatic conversion " +comment "of symbols will be lost. "
This really seems ugly for users, no? I know it's been discussed, but can you summarize why this should be done by our users?
Thanks!
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 1/1 Config.in.legacy: update description for users
Quoted 16 lines · Thomas Petazzoni
Dear Thomas De Schampheleire,
Quoted 12 lines · Thomas De Schampheleire
if
BR2_LEGACY
comment "Your old configuration uses legacy options that no "Config.in.legacy +5
-4-comment "longer exist in buildroot. " -comment "Please look at the options which have been selected " -comment "and read their help text. " -comment "As long as these options stay selected, the build " +comment "longer exist in buildroot, as indicated in the menu " +comment "below. As long as these options stay selected, or in" +comment "case of string options are non-empty, the build " comment "will fail. " +comment "* " +comment "Where possible, an automatic conversion from old to "
Quoted 8 lines
Config.in.legacy menu "Legacy config options" · line 82
Quoted 5 lines
Config.in.legacy +5
-0+comment "new symbols has been performed. Before making any " +comment "change in this legacy menu, make sure to exit the " +comment "configuration editor a first time and save the " +comment "configuration. Otherwise, the automatic conversion " +comment "of symbols will be lost. "This really seems ugly for users, no? I know it's been discussed, but can you summarize why this should be done by our users?
I.e., add "because of Kconfig limitations", right?
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH v4 1/1 Config.in.legacy: update description for users
Dear Arnout Vandecappelle,
Quoted 21 lines · Arnout Vandecappelle
Quoted 12 lines
Quoted 12 lines
if
BR2_LEGACY
comment "Your old configuration uses legacy options that no "Config.in.legacy +5
-4-comment "longer exist in buildroot. " -comment "Please look at the options which have been selected " -comment "and read their help text. " -comment "As long as these options stay selected, the build " +comment "longer exist in buildroot, as indicated in the menu " +comment "below. As long as these options stay selected, or in" +comment "case of string options are non-empty, the build " comment "will fail. " +comment "* " +comment "Where possible, an automatic conversion from old to "Quoted 8 lines
Config.in.legacy menu "Legacy config options" · line 82
Quoted 5 lines
Config.in.legacy +5
-0+comment "new symbols has been performed. Before making any " +comment "change in this legacy menu, make sure to exit the " +comment "configuration editor a first time and save the " +comment "configuration. Otherwise, the automatic conversion " +comment "of symbols will be lost. "This really seems ugly for users, no? I know it's been discussed, but can you summarize why this should be done by our users?
Quoted 1 line
I.e., add "because of
Kconfiglimitations", right?
That I understood, but for my own culture, can you summarize what are those limitations? Maybe it would be good to document them in the big fat comment inside Config.in.legacy (not the one shown to the user, but the one inside the source code). Having to exit menuconfig, and restart it doesn't seem like a really great thing, so I'd like to understand why we need that, and what are our options to maybe solve this in the future.
Thanks!
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 1/1 Config.in.legacy: update description for users
Hi Thomas, all,
Quoted 27 lines · Thomas Petazzoni
Dear Arnout Vandecappelle,
Quoted 21 lines · Arnout Vandecappelle
Quoted 12 lines
Quoted 12 lines
if
BR2_LEGACY
comment "Your old configuration uses legacy options that no "Config.in.legacy +5
-4-comment "longer exist in buildroot. " -comment "Please look at the options which have been selected " -comment "and read their help text. " -comment "As long as these options stay selected, the build " +comment "longer exist in buildroot, as indicated in the menu " +comment "below. As long as these options stay selected, or in" +comment "case of string options are non-empty, the build " comment "will fail. " +comment "* " +comment "Where possible, an automatic conversion from old to "Quoted 8 lines
Config.in.legacy menu "Legacy config options" · line 82
Quoted 5 lines
Config.in.legacy +5
-0+comment "new symbols has been performed. Before making any " +comment "change in this legacy menu, make sure to exit the " +comment "configuration editor a first time and save the " +comment "configuration. Otherwise, the automatic conversion " +comment "of symbols will be lost. "This really seems ugly for users, no? I know it's been discussed, but can you summarize why this should be done by our users?
Quoted 1 line
I.e., add "because of
Kconfiglimitations", right?
Quoted 8 lines
That I understood, but for my own culture, can you summarize what are those limitations? Maybe it would be good to document them in the big fat comment inside Config.in.legacy (not the one shown to the user, but the one inside the source code). Having to exit menuconfig, and restart it doesn't seem like a really great thing, so I'd like to understand why we need that, and what are our options to maybe solve this in the future.
The basic problem is that kconfig seems to remember how a given symbol was selected, *within one kconfig session*. 'How' can be: explicitly selected by the user, or selected through a 'select' statement of another symbol. In the latter case, when the first symbol is disabled, the 'selected' symbol is also automatically disabled.
When you start a new kconfig session (by saving the configuration and reopening it) kconfig has no clue anymore about how the different symbols became selected, because clearly there is no indication about this whatsoever in the .config file.
Applied to the legacy symbols: suppose symbol FOO is renamed into BAR, and we have made the legacy symbol FOO 'select' the new symbol BAR through Config.in.legacy. The user opens the menuconfig, sees that there is something in the legacy menu, reads the help text, goes to the menu where FOO used to be selected, sees that BAR is already correctly selected thanks to the automatic propagation, and decides to clear the legacy FOO symbol in the legacy menu. Then he saves the configuration.
If you check the .config file afterwards (or even if you check the BAR symbol after deselecting FOO before exiting menuconfig) you will see that BAR is no longer selected. The only way to saveguard that is by saving the configuration before fiddling with the legacy menu, thereby 'flattening' the symbols.
Provided we want automatic propagation of symbols (boolean or otherwise), I don't see another solution.
See also the other thread where you asked whether it's at all logical to have something in legacy for such renames.
Best regards,
Thomas
PATCH v4 1/1 Config.in.legacy: update description for users
Dear Thomas De Schampheleire,
Quoted 24 lines · Thomas De Schampheleire
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
This really seems ugly for users, no? I know it's been discussed, but can you summarize why this should be done by our users?
I.e., add "because of
Kconfiglimitations", right?Quoted 8 lines
That I understood, but for my own culture, can you summarize what are those limitations? Maybe it would be good to document them in the big fat comment inside Config.in.legacy (not the one shown to the user, but the one inside the source code). Having to exit menuconfig, and restart it doesn't seem like a really great thing, so I'd like to understand why we need that, and what are our options to maybe solve this in the future.
The basic problem is that kconfig seems to remember how a given symbol was selected, *within one kconfig session*. 'How' can be: explicitly selected by the user, or selected through a 'select' statement of another symbol. In the latter case, when the first symbol is disabled, the 'selected' symbol is also automatically disabled.
When you start a new kconfig session (by saving the configuration and reopening it) kconfig has no clue anymore about how the different symbols became selected, because clearly there is no indication about this whatsoever in the .config file.
Quoted 13 lines
Applied to the legacy symbols: suppose symbol FOO is renamed into BAR, and we have made the legacy symbol FOO 'select' the new symbol BAR through Config.in.legacy. The user opens the menuconfig, sees that there is something in the legacy menu, reads the help text, goes to the menu where FOO used to be selected, sees that BAR is already correctly selected thanks to the automatic propagation, and decides to clear the legacy FOO symbol in the legacy menu. Then he saves the configuration.
If you check the .config file afterwards (or even if you check the BAR symbol after deselecting FOO before exiting menuconfig) you will see that BAR is no longer selected. The only way to saveguard that is by saving the configuration before fiddling with the legacy menu, thereby 'flattening' the symbols.
Thanks for the great summary. I now understand the problem (sorry for being slow).
Quoted 4 lines
Provided we want automatic propagation of symbols (boolean or otherwise), I don't see another solution.
See also the other thread where you asked whether it's at all logical to have something in legacy for such renames.
In the light of this, I indeed restate my question asking whether it's logical to select BR2_LEGACY for renames that are equivalent.
So I believe I would rather classify the legacy options in two categories:
(1) Options that have been renamed, or can be approximated in such a close way that letting the user know about the rename or change is not important: we simply add an hidden Config.in.legacy symbol that selects the new relevant option. This legacy symbol does not select BR2_LEGACY, and things are fully transparent for the user. Of course the symbol remains =y in the .config file, but it's clearly identified as such.
(2) Options that have been removed, or changed in such a way that it's not possible to approximate the modification by selecting other options. In this case, the legacy Config.in.legacy symbol is not hidden, and only selects BR2_LEGACY and no other option, and the user is requested to act by disabling this option and doing the necessary configuration changes.
So far, the only problem I see with this are related to minimal defconfigs. In the case (1) above, the minimal defconfig will continue to contain the name of the legacy option, and not the name of the new option, since the new option is selected by the legacy option. This is annoying since it means minimal defconfigs are not progressively updated to use the new option name. And this probably makes my entire proposal moot.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 1/1 Config.in.legacy: update description for users
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Thomas> So far, the only problem I see with this are related to minimal Thomas> defconfigs. In the case (1) above, the minimal defconfig will continue Thomas> to contain the name of the legacy option, and not the name of the new Thomas> option, since the new option is selected by the legacy option. This is Thomas> annoying since it means minimal defconfigs are not progressively Thomas> updated to use the new option name. And this probably makes my entire Thomas> proposal moot.
Damn, yes :/
So people really do need to explictly change to the new option / restart make menuconfig.
Signature · 1 line
Bye, Peter Korsgaard
PATCH v4 1/1 Config.in.legacy: update description for users
Quoted 11 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Thomas> So far, the only problem I see with this are related to minimal Thomas> defconfigs. In the case (1) above, the minimal defconfig will continue Thomas> to contain the name of the legacy option, and not the name of the new Thomas> option, since the new option is selected by the legacy option. This is Thomas> annoying since it means minimal defconfigs are not progressively Thomas> updated to use the new option name. And this probably makes my entire Thomas> proposal moot.
Quoted 4 lines
Damn, yes :/
So people really do need to explictly change to the new option / restart make menuconfig.
I never tried it, but a workaround could be to run olddefconfig before
any interactive config (menuconfig, nconfig, xconfig, qconfig). olddefconfig should be equivalent to saving immediately.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH v4 1/1 Config.in.legacy: update description for users
Hi Arnout,
Quoted 21 lines · Arnout Vandecappelle
Quoted 20 lines · Peter Korsgaard
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Thomas> So far, the only problem I see with this are related to minimal Thomas> defconfigs. In the case (1) above, the minimal defconfig will
continue
Thomas> to contain the name of the legacy option, and not the name of
the new
Thomas> option, since the new option is selected by the legacy option.
This is
Thomas> annoying since it means minimal defconfigs are not progressively Thomas> updated to use the new option name. And this probably makes my
entire
Thomas> proposal moot.Damn, yes :/
Quoted 7 lines
Quoted 2 lines
So people really do need to explictly change to the new option / restart make menuconfig.
I never tried it, but a workaround could be to run olddefconfig before any
interactive config (menuconfig, nconfig, xconfig, qconfig). olddefconfig should be equivalent to saving immediately.
I tried it manually (not yet integrated in a Makefile) and it works as expected. However, a disadvantage is that any new symbol will no longer be marked as NEW in the interactive config. So the trade-off would be between loosing this NEW marker, and requiring the user to do an intermediate save.
Best regards,
Thomas
PATCH v4 1/1 Config.in.legacy: update description for users
Quoted 32 lines · Thomas De Schampheleire
Hi Arnout,
Quoted 21 lines · Arnout Vandecappelle
Quoted 20 lines · Peter Korsgaard
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Thomas> So far, the only problem I see with this are related to minimal Thomas> defconfigs. In the case (1) above, the minimal defconfig will
continue
Thomas> to contain the name of the legacy option, and not the name of
the new
Thomas> option, since the new option is selected by the legacy option.
This is
Thomas> annoying since it means minimal defconfigs are not progressively Thomas> updated to use the new option name. And this probably makes my
entire
Thomas> proposal moot.Damn, yes :/
Quoted 7 lines
Quoted 2 lines
So people really do need to explictly change to the new option / restart make menuconfig.
I never tried it, but a workaround could be to run olddefconfig before any
interactive config (menuconfig, nconfig, xconfig, qconfig). olddefconfig should be equivalent to saving immediately.
Quoted 5 lines
I tried it manually (not yet integrated in a
Makefile) and it works as expected. However, a disadvantage is that any new symbol will no longer be marked as NEW in the interactive config. So the trade-off would be between loosing this NEW marker, and requiring the user to do an intermediate save.
If the user does an intermediate save, the NEW marker will also be gone...
But at least, this is only for a user that has legacy stuff, not for
all those innocent people out there that just do a 'make menuconfig' after 'git pull'.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH v4 1/1 Config.in.legacy: update description for users
Op 4-sep.-2013 20:35 schreef "Arnout Vandecappelle" <[email protected]> het volgende:
Quoted 6 lines · Thomas De Schampheleire
Quoted 4 lines
Hi Arnout,
On Tue, Sep 3, 2013 at 6:50 PM, Arnout Vandecappelle <[email protected]>
Quoted 11 lines · wrote:
Quoted 11 lines
Quoted 11 lines · Peter Korsgaard
Quoted 9 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Thomas> So far, the only problem I see with this are related to
minimal
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Thomas> defconfigs. In the case (1) above, the minimal defconfig
will
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
continue
Thomas> to contain the name of the legacy option, and not the name
of
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
the new
Thomas> option, since the new option is selected by the legacy
option.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
This is
Thomas> annoying since it means minimal defconfigs are not
progressively
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Thomas> updated to use the new option name. And this probably makes
my
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
entire
Thomas> proposal moot.Damn, yes :/
So people really do need to explictly change to the new option /
restart
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
make menuconfig.
I never tried it, but a workaround could be to run olddefconfig
before any
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
interactive config (menuconfig, nconfig, xconfig, qconfig). olddefconfig should be equivalent to saving immediately.
I tried it manually (not yet integrated in a
Makefile) and it works as
expected.
Quoted 7 lines
Quoted 4 lines
However, a disadvantage is that any new symbol will no longer be marked as NEW in the interactive config. So the trade-off would be between loosing this NEW marker, and requiring the user to do an intermediate save.
If the user does an intermediate save, the NEW marker will also be
gone...
Yes, but before that save he does see the markers...
Quoted 2 lines
But at least, this is only for a user that has legacy stuff, not for all
those innocent people out there that just do a 'make menuconfig' after 'git pull'.
Right.
To proceed with this, I think the community should decide which alternative we prefer, knowing that each one has its pros and cons...
Looking forward to everyone's input...
Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130904/5990fb74/attachment-0001.html>
PATCH v4 1/1 Config.in.legacy: add separator to description for users
In reply to Thomas De SchampheleireWhen legacy symbols are selected, the menuconfig shows the explanation for users, immediately followed by the line "Legacy options removed in 2013.08". In order to visually keep these apart, we introduce a separator.
Note that a line with all spaces is not correctly shown by menuconfig (the
width will not be kept at 80 characters, so the output is '*** ***').
A dashed line seemed a logical alternative, and with another dashed line on top, the description becomes a block.
---
This patch is pure aesthetics. I kept it as a separate patch so it can be rejected easily if you don't feel the same way.
v4: no changes
(v3): new patch in this series
Config.in.legacy | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
Config.in.legacy +2 -0
@@ -68,6 +68,7 @@ comment "Legacy detected: check the cont menu "Legacy config options" if BR2_LEGACY +comment "----------------------------------------------------" comment "Your old configuration uses legacy options that no " comment "longer exist in buildroot, as indicated in the menu " comment "below. As long as these options stay selected, or in"
@@ -94,6 +95,7 @@ comment "Note: at some point in the futu comment "options will be removed, and configuration files " comment "that still have those options set, will fail to " comment "build, or run, in unpredictable ways. " +comment "----------------------------------------------------" endif ###############################################################################
PATCH v4 1/1 Remove redundant dollar signs in Config.in files
In reply to Thomas De SchampheleireSome Config.in(.host) files have constructs like:
config FOO_VERSION
string default "1.0" if FOO_1_0 default "2.0" if FOO_2_0 default $FOO_CUSTOM_VERSION if FOO_CUSTOM
The dollar sign here is not needed and confusing, so can be removed.
---
v4: also check Config.in.host
(v3): new patch in this series
boot/barebox/Config.in | 4 ++-- boot/uboot/Config.in | 4 ++-- fs/jffs2/Config.in | 4 ++-- linux/Config.in | 2 +- package/gcc/Config.in.host | 2 +- package/linux-headers/Config.in.host | 2 +- package/uclibc/Config.in | 2 +- toolchain/toolchain-external/Config.in | 2 +- 8 files changed, 11 insertions(+), 11 deletions(-)
boot/barebox/Config.in +2 -2
@@ -41,9 +41,9 @@ endif config BR2_TARGET_BAREBOX_VERSION string default "2013.07.0" if BR2_TARGET_BAREBOX_LATEST_VERSION - default $BR2_TARGET_BAREBOX_CUSTOM_VERSION_VALUE if BR2_TARGET_BAREBOX_CUSTOM_VERSION + default BR2_TARGET_BAREBOX_CUSTOM_VERSION_VALUE if BR2_TARGET_BAREBOX_CUSTOM_VERSION default "custom" if BR2_TARGET_BAREBOX_CUSTOM_TARBALL - default $BR2_TARGET_BAREBOX_CUSTOM_GIT_VERSION if BR2_TARGET_BAREBOX_CUSTOM_GIT + default BR2_TARGET_BAREBOX_CUSTOM_GIT_VERSION if BR2_TARGET_BAREBOX_CUSTOM_GIT config BR2_TARGET_BAREBOX_CUSTOM_PATCH_DIR string "custom patch dir"
boot/uboot/Config.in +2 -2
@@ -47,9 +47,9 @@ endif config BR2_TARGET_UBOOT_VERSION string default "2013.07" if BR2_TARGET_UBOOT_LATEST_VERSION - default $BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE if BR2_TARGET_UBOOT_CUSTOM_VERSION + default BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE if BR2_TARGET_UBOOT_CUSTOM_VERSION default "custom" if BR2_TARGET_UBOOT_CUSTOM_TARBALL - default $BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION if BR2_TARGET_UBOOT_CUSTOM_GIT + default BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION if BR2_TARGET_UBOOT_CUSTOM_GIT config BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR string "custom patch dir"
fs/jffs2/Config.in +2 -2
@@ -58,7 +58,7 @@ config BR2_TARGET_ROOTFS_JFFS2_PAGESIZE default 0x800 if BR2_TARGET_ROOTFS_JFFS2_NANDFLASH_2K_128K default 0x1000 if BR2_TARGET_ROOTFS_JFFS2_FLASH_128 default 0x1000 if BR2_TARGET_ROOTFS_JFFS2_FLASH_64 - default $(BR2_TARGET_ROOTFS_JFFS2_CUSTOM_PAGESIZE) if BR2_TARGET_ROOTFS_JFFS2_CUSTOM + default BR2_TARGET_ROOTFS_JFFS2_CUSTOM_PAGESIZE if BR2_TARGET_ROOTFS_JFFS2_CUSTOM config BR2_TARGET_ROOTFS_JFFS2_EBSIZE hex
@@ -68,7 +68,7 @@ config BR2_TARGET_ROOTFS_JFFS2_EBSIZE default 0x20000 if BR2_TARGET_ROOTFS_JFFS2_NANDFLASH_2K_128K default 0x20000 if BR2_TARGET_ROOTFS_JFFS2_FLASH_128 default 0x10000 if BR2_TARGET_ROOTFS_JFFS2_FLASH_64 - default $(BR2_TARGET_ROOTFS_JFFS2_CUSTOM_EBSIZE) if BR2_TARGET_ROOTFS_JFFS2_CUSTOM + default BR2_TARGET_ROOTFS_JFFS2_CUSTOM_EBSIZE if BR2_TARGET_ROOTFS_JFFS2_CUSTOM config BR2_TARGET_ROOTFS_JFFS2_NOCLEANMARKER bool "Do not use Cleanmarker"
linux/Config.in +1 -1
@@ -79,7 +79,7 @@ config BR2_LINUX_KERNEL_VERSION default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL - default $BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION if BR2_LINUX_KERNEL_CUSTOM_GIT + default BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION if BR2_LINUX_KERNEL_CUSTOM_GIT # # Patch selection
package/gcc/Config.in.host +1 -1
@@ -91,7 +91,7 @@ config BR2_GCC_VERSION default "4.7.3" if BR2_GCC_VERSION_4_7_X default "4.8.1" if BR2_GCC_VERSION_4_8_X default "4.8-arc" if BR2_GCC_VERSION_4_8_ARC - default $BR2_GCC_SNAP_DATE if BR2_GCC_VERSION_SNAP + default BR2_GCC_SNAP_DATE if BR2_GCC_VERSION_SNAP config BR2_EXTRA_GCC_CONFIG_OPTIONS string "Additional gcc options"
package/linux-headers/Config.in.host +1 -1
@@ -84,4 +84,4 @@ config BR2_DEFAULT_KERNEL_HEADERS default "3.9.11" if BR2_KERNEL_HEADERS_3_9 default "3.10.10" if BR2_KERNEL_HEADERS_3_10 default "2.6" if BR2_KERNEL_HEADERS_SNAP - default $BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION + default BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION
package/uclibc/Config.in +1 -1
@@ -37,7 +37,7 @@ config BR2_UCLIBC_VERSION_STRING default 0.9.32.1 if BR2_UCLIBC_VERSION_0_9_32 default 0.9.33.2 if BR2_UCLIBC_VERSION_0_9_33 default 0.9.33-arc if BR2_UCLIBC_VERSION_0_9_33_ARC - default $BR2_USE_UCLIBC_SNAPSHOT if BR2_UCLIBC_VERSION_SNAPSHOT + default BR2_USE_UCLIBC_SNAPSHOT if BR2_UCLIBC_VERSION_SNAPSHOT config BR2_UCLIBC_CONFIG string "uClibc configuration file to use?"
toolchain/toolchain-external/Config.in +1 -1
@@ -832,7 +832,7 @@ config BR2_TOOLCHAIN_EXTERNAL_PREFIX default "bfin-linux-uclibc" if BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_2012R1 && BR2_BINFMT_FDPIC default "bfin-uclinux" if BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_2012R2 && BR2_BINFMT_FLAT default "bfin-linux-uclibc" if BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_2012R2 && BR2_BINFMT_FDPIC - default $(BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX) \ + default BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX \ if BR2_TOOLCHAIN_EXTERNAL_CUSTOM config BR2_TOOLCHAIN_EXTERNAL_GLIBC
PATCH v4 1/1 linux: add support for custom Mercurial repository
In reply to Thomas De Schampheleire---
v4: rebased
v3:
- add automatic propagation of old->new values (comment Arnout)
- fix legacy entries
v2: add Config.in.legacy entries (comment Peter)
Config.in.legacy | 33 +++++++++++++++++++++++++++++++++ linux/Config.in | 32 +++++++++++++++++++++++--------- linux/linux.mk | 5 ++++- 3 files changed, 60 insertions(+), 10 deletions(-)
Config.in.legacy +33 -0
@@ -99,6 +99,39 @@ comment "------------------------------- endif ############################################################################### +comment "Legacy options removed in 2013.11" + +config BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL + string "linux: the git repository URL option has been renamed" + help + The option BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL has + been renamed to + BR2_LINUX_KERNEL_CUSTOM_REPO_URL. + +config BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL_WRAP + bool + default y if BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL != "" + select BR2_LEGACY + +# Note: BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL is still referenced from +# linux/Config.in + +config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION + string "linux: the git repository version option has been renamed" + help + The option BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION has + been renamed to + BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION. + +config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION_WRAP + bool + default y if BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION != "" + select BR2_LEGACY + +# Note: BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION is still referenced from +# linux/Config.in + +############################################################################### comment "Legacy options removed in 2013.08" config BR2_ARM_OABI
linux/Config.in +23 -9
@@ -52,6 +52,12 @@ config BR2_LINUX_KERNEL_CUSTOM_GIT This option allows Buildroot to get the Linux kernel source code from a Git repository. +config BR2_LINUX_KERNEL_CUSTOM_HG + bool "Custom Mercurial repository" + help + This option allows Buildroot to get the Linux kernel source + code from a Mercurial repository. + endchoice config BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE
@@ -62,24 +68,32 @@ config BR2_LINUX_KERNEL_CUSTOM_TARBALL_L string "URL of custom kernel tarball" depends on BR2_LINUX_KERNEL_CUSTOM_TARBALL -config BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL - string "URL of custom Git repository" - depends on BR2_LINUX_KERNEL_CUSTOM_GIT +if BR2_LINUX_KERNEL_CUSTOM_GIT || BR2_LINUX_KERNEL_CUSTOM_HG -config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION - string "Custom Git version" - depends on BR2_LINUX_KERNEL_CUSTOM_GIT +config BR2_LINUX_KERNEL_CUSTOM_REPO_URL + string "URL of custom repository" + default BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL \ + if BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL != "" # legacy + +config BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION + string "Custom repository version" + default BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION \ + if BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION != "" # legacy help - Git revision to use in the format used by git rev-parse, + Revision to use in the typical format used by Git/Mercurial E.G. a sha id, a tag, branch, .. +endif + config BR2_LINUX_KERNEL_VERSION string default "3.10.10" if BR2_LINUX_KERNEL_LATEST_VERSION default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS - default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION + default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE \ + if BR2_LINUX_KERNEL_CUSTOM_VERSION default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL - default BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION if BR2_LINUX_KERNEL_CUSTOM_GIT + default BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION \ + if BR2_LINUX_KERNEL_CUSTOM_GIT || BR2_LINUX_KERNEL_CUSTOM_HG # # Patch selection
linux/linux.mk +4 -1
@@ -14,8 +14,11 @@ LINUX_TARBALL = $(call qstrip,$(BR2_LINU LINUX_SITE = $(patsubst %/,%,$(dir $(LINUX_TARBALL))) LINUX_SOURCE = $(notdir $(LINUX_TARBALL)) else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_GIT),y) -LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL)) +LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL)) LINUX_SITE_METHOD = git +else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_HG),y) +LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL)) +LINUX_SITE_METHOD = hg else LINUX_SOURCE = linux-$(LINUX_VERSION).tar.xz # In X.Y.Z, get X and Y. We replace dots and dashes by spaces in order
PATCH v4 1/1 u-boot: add support for custom Mercurial repository
In reply to Thomas De Schampheleire---
v4: no changes
v3:
- add automatic propagation of old->new values
- fix legacy entries
v2: add Config.in.legacy entries (comment Peter)
Config.in.legacy | 30 ++++++++++++++++++++++++++++++ boot/uboot/Config.in | 23 ++++++++++++++++------- boot/uboot/uboot.mk | 5 ++++- 3 files changed, 50 insertions(+), 8 deletions(-)
Config.in.legacy +30 -0
@@ -101,6 +101,36 @@ endif ############################################################################### comment "Legacy options removed in 2013.11" +config BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL + string "u-boot: the git repository URL option has been renamed" + help + The option BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL has + been renamed to + BR2_TARGET_UBOOT_CUSTOM_REPO_URL. + +config BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL_WRAP + bool + default y if BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL != "" + select BR2_LEGACY + +# Note: BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL is still referenced from +# boot/uboot/Config.in + +config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION + string "u-boot: the git repository version option has been renamed" + help + The option BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION has + been renamed to + BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION. + +config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION_WRAP + bool + default y if BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION != "" + select BR2_LEGACY + +# Note: BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION is still referenced from +# boot/uboot/Config.in + config BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL string "linux: the git repository URL option has been renamed" help
boot/uboot/Config.in +16 -7
@@ -31,6 +31,9 @@ config BR2_TARGET_UBOOT_CUSTOM_TARBALL config BR2_TARGET_UBOOT_CUSTOM_GIT bool "Custom Git repository" +config BR2_TARGET_UBOOT_CUSTOM_HG + bool "Custom Mercurial repository" + endchoice config BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE
@@ -47,9 +50,11 @@ endif config BR2_TARGET_UBOOT_VERSION string default "2013.07" if BR2_TARGET_UBOOT_LATEST_VERSION - default BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE if BR2_TARGET_UBOOT_CUSTOM_VERSION + default BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE \ + if BR2_TARGET_UBOOT_CUSTOM_VERSION default "custom" if BR2_TARGET_UBOOT_CUSTOM_TARBALL - default BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION if BR2_TARGET_UBOOT_CUSTOM_GIT + default BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION \ + if BR2_TARGET_UBOOT_CUSTOM_GIT || BR2_TARGET_UBOOT_CUSTOM_HG config BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR string "custom patch dir"
@@ -60,13 +65,17 @@ config BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR Most users may leave this empty -if BR2_TARGET_UBOOT_CUSTOM_GIT +if BR2_TARGET_UBOOT_CUSTOM_GIT || BR2_TARGET_UBOOT_CUSTOM_HG -config BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL - string "URL of custom Git repository" +config BR2_TARGET_UBOOT_CUSTOM_REPO_URL + string "URL of custom repository" + default BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL \ + if BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL != "" # legacy -config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION - string "Custom Git version" +config BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION + string "Custom repository version" + default BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION \ + if BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION != "" # legacy endif
boot/uboot/uboot.mk +4 -1
@@ -18,8 +18,11 @@ UBOOT_TARBALL = $(call qstrip,$(BR2_TARG UBOOT_SITE = $(patsubst %/,%,$(dir $(UBOOT_TARBALL))) UBOOT_SOURCE = $(notdir $(UBOOT_TARBALL)) else ifeq ($(BR2_TARGET_UBOOT_CUSTOM_GIT),y) -UBOOT_SITE = $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL)) +UBOOT_SITE = $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_REPO_URL)) UBOOT_SITE_METHOD = git +else ifeq ($(BR2_TARGET_UBOOT_CUSTOM_HG),y) +UBOOT_SITE = $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_REPO_URL)) +UBOOT_SITE_METHOD = hg else # Handle stable official U-Boot versions UBOOT_SITE = ftp://ftp.denx.de/pub/u-boot
PATCH v4 1/1 linux/uboot: line-up repository-related configuration options
In reply to Thomas De SchampheleireAlthough the configuration options for custom repository locations and versions are very similar between the linux and uboot packages, there are some minor differences. This patch lines up both packages.
---
v4: no changes
v3: update after changes in previous patches
v2:
- remove 'HEAD/tip' defaults for repository version (comment Peter)
- replace if/config/endif with config/depends for uboot tarball
- move repo url/version settings before unrelated 'custom patch dir'
Note: one remaining difference is that there are help texts in linux for options BR2_LINUX_KERNEL_CUSTOM_GIT and BR2_LINUX_KERNEL_CUSTOM_HG. I didn't add them to uboot because it seems a bit redundant, but if you prefer we can line this up as well (either add help texts to uboot or remove them from linux).
boot/uboot/Config.in | 32 ++++++++++++++++---------------- linux/Config.in | 2 +- 2 files changed, 17 insertions(+), 17 deletions(-)
boot/uboot/Config.in +16 -16
@@ -40,10 +40,24 @@ config BR2_TARGET_UBOOT_CUSTOM_VERSION_V string "U-Boot version" depends on BR2_TARGET_UBOOT_CUSTOM_VERSION -if BR2_TARGET_UBOOT_CUSTOM_TARBALL - config BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION string "URL of custom U-Boot tarball" + depends on BR2_TARGET_UBOOT_CUSTOM_TARBALL + +if BR2_TARGET_UBOOT_CUSTOM_GIT || BR2_TARGET_UBOOT_CUSTOM_HG + +config BR2_TARGET_UBOOT_CUSTOM_REPO_URL + string "URL of custom repository" + default BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL \ + if BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL != "" # legacy + +config BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION + string "Custom repository version" + default BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION \ + if BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION != "" # legacy + help + Revision to use in the typical format used by Git/Mercurial + E.G. a sha id, a tag, branch, .. endif
@@ -65,20 +79,6 @@ config BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR Most users may leave this empty -if BR2_TARGET_UBOOT_CUSTOM_GIT || BR2_TARGET_UBOOT_CUSTOM_HG - -config BR2_TARGET_UBOOT_CUSTOM_REPO_URL - string "URL of custom repository" - default BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL \ - if BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL != "" # legacy - -config BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION - string "Custom repository version" - default BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION \ - if BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION != "" # legacy - -endif - choice prompt "U-Boot binary format" default BR2_TARGET_UBOOT_FORMAT_BIN
linux/Config.in +1 -1
@@ -47,7 +47,7 @@ config BR2_LINUX_KERNEL_CUSTOM_TARBALL specific kernel source tarball config BR2_LINUX_KERNEL_CUSTOM_GIT - bool "Custom Git tree" + bool "Custom Git repository" help This option allows Buildroot to get the Linux kernel source code from a Git repository.
PATCH v4 1/1 defconfigs: update after rename of custom git repo/version options
In reply to Thomas De Schampheleire---
v4: no changes
(v3): new patch in this series (comment Arnout)
configs/arm_foundationv8_defconfig | 4 ++-- configs/beaglebone_defconfig | 4 ++-- configs/calao_snowball_defconfig | 4 ++-- configs/cubieboard_defconfig | 8 ++++---- configs/ea3250_defconfig | 8 ++++---- configs/fdi3250_defconfig | 8 ++++---- configs/gnublin_defconfig | 8 ++++---- configs/mx53loco_defconfig | 8 ++++---- configs/phy3250_defconfig | 8 ++++---- configs/rpi_defconfig | 4 ++-- 10 files changed, 32 insertions(+), 32 deletions(-)
configs/arm_foundationv8_defconfig +2 -2
@@ -8,8 +8,8 @@ BR2_TARGET_BOOT_WRAPPER_AARCH64_DTS="vex BR2_TARGET_BOOT_WRAPPER_AARCH64_BOOTARGS="root=/dev/vda consolelog=9 console=ttyAMA0 rw" BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y -BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.linaro.org/kernel/linaro-aarch64.git" -BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="7181edd0539e195f78adedbb6c3878f9f1e0c4bb" +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.linaro.org/kernel/linaro-aarch64.git" +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="7181edd0539e195f78adedbb6c3878f9f1e0c4bb" BR2_LINUX_KERNEL_DEFCONFIG="vexpress" BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y BR2_LINUX_KERNEL_IMAGE_TARGET_NAME="Image"
configs/beaglebone_defconfig +2 -2
@@ -30,8 +30,8 @@ BR2_TARGET_UBOOT_SPL_NAME="MLO" # kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y -BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git" -BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="935f6c2f82056d538b528272e2bdbb5c08d69a58" +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git" +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="935f6c2f82056d538b528272e2bdbb5c08d69a58" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/beaglebone/linux-3.8.config" BR2_LINUX_KERNEL_DTS_SUPPORT=y
configs/calao_snowball_defconfig +2 -2
@@ -16,8 +16,8 @@ BR2_TARGET_UBOOT=y BR2_TARGET_UBOOT_BOARDNAME="snowball" BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y -BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="https://github.com/igloocommunity/igloo-kernel" -BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="stable-linux-ux500-3.4" +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/igloocommunity/igloo-kernel" +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="stable-linux-ux500-3.4" BR2_LINUX_KERNEL_PATCH="board/calao/snowball/" BR2_LINUX_KERNEL_DEFCONFIG="u8500" BR2_LINUX_KERNEL_INSTALL_TARGET=y
configs/cubieboard_defconfig +4 -4
@@ -22,8 +22,8 @@ BR2_KERNEL_HEADERS_3_4=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y -BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="https://github.com/linux-sunxi/linux-sunxi.git" -BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="274a66a7bfcbaabb88d63e4eba161965383cc416" +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/linux-sunxi/linux-sunxi.git" +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="274a66a7bfcbaabb88d63e4eba161965383cc416" BR2_LINUX_KERNEL_VERSION="sunxi-3.4" BR2_LINUX_KERNEL_DEFCONFIG="sun4i"
@@ -32,8 +32,8 @@ BR2_TARGET_UBOOT=y BR2_TARGET_UBOOT_BOARDNAME="cubieboard" BR2_TARGET_UBOOT_CUSTOM_GIT=y BR2_TARGET_UBOOT_VERSION="sunxi" -BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="https://github.com/linux-sunxi/u-boot-sunxi.git" -BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="1a8ac55429f7f8cc9f100c1cf2dc0195cf81e76f" +BR2_TARGET_UBOOT_CUSTOM_REPO_URL="https://github.com/linux-sunxi/u-boot-sunxi.git" +BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="1a8ac55429f7f8cc9f100c1cf2dc0195cf81e76f" BR2_TARGET_UBOOT_FORMAT_BIN=y BR2_TARGET_UBOOT_SPL=y BR2_TARGET_UBOOT_SPL_NAME="spl/sunxi-spl.bin"
configs/ea3250_defconfig +4 -4
@@ -27,8 +27,8 @@ BR2_TARGET_UBOOT=y BR2_TARGET_UBOOT_BOARDNAME="ea3250" BR2_TARGET_UBOOT_CUSTOM_GIT=y BR2_TARGET_UBOOT_VERSION="master" -BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx" -BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="master" +BR2_TARGET_UBOOT_CUSTOM_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx" +BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="master" BR2_TARGET_UBOOT_FORMAT_BIN=y BR2_TARGET_LPC32XXCDL=y BR2_TARGET_LPC32XXCDL_BOARDNAME="ea3250"
@@ -39,8 +39,8 @@ BR2_TARGET_LPC32XXCDL_BOARDNAME="ea3250" # BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y -BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx" -BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="master" +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx" +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="master" BR2_LINUX_KERNEL_VERSION="master" BR2_LINUX_KERNEL_PATCH="" BR2_LINUX_KERNEL_USE_DEFCONFIG=y
configs/fdi3250_defconfig +4 -4
@@ -27,8 +27,8 @@ BR2_TARGET_UBOOT=y BR2_TARGET_UBOOT_BOARDNAME="fdi3250" BR2_TARGET_UBOOT_CUSTOM_GIT=y BR2_TARGET_UBOOT_VERSION="master" -BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx" -BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="master" +BR2_TARGET_UBOOT_CUSTOM_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx" +BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="master" BR2_TARGET_UBOOT_FORMAT_BIN=y BR2_TARGET_LPC32XXCDL=y BR2_TARGET_LPC32XXCDL_BOARDNAME="fdi3250"
@@ -39,8 +39,8 @@ BR2_TARGET_LPC32XXCDL_BOARDNAME="fdi3250 # BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y -BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx" -BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="master" +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx" +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="master" BR2_LINUX_KERNEL_VERSION="master" BR2_LINUX_KERNEL_PATCH="" BR2_LINUX_KERNEL_USE_DEFCONFIG=y
configs/gnublin_defconfig +4 -4
@@ -15,13 +15,13 @@ BR2_TARGET_ROOTFS_EXT2_BLOCKS=475000 BR2_TARGET_UBOOT=y BR2_TARGET_UBOOT_BOARDNAME="GNUBLIN" BR2_TARGET_UBOOT_CUSTOM_GIT=y -BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="git://gitorious.org/u-boot-gnublin-support/u-boot-gnublin-support.git" -BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="2009.11_gnublin_support_v2" +BR2_TARGET_UBOOT_CUSTOM_REPO_URL="git://gitorious.org/u-boot-gnublin-support/u-boot-gnublin-support.git" +BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="2009.11_gnublin_support_v2" # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y -BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://gitorious.org/linux-3-7-gnublin/linux-3-7-gnublin.git" -BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="v3.7-gnublin-2" +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://gitorious.org/linux-3-7-gnublin/linux-3-7-gnublin.git" +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="v3.7-gnublin-2" BR2_LINUX_KERNEL_DEFCONFIG="gnublin" BR2_LINUX_KERNEL_INSTALL_TARGET=y
configs/mx53loco_defconfig +4 -4
@@ -8,8 +8,8 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttymxc0" BR2_TARGET_UBOOT=y BR2_TARGET_UBOOT_BOARDNAME="mx53_loco" BR2_TARGET_UBOOT_CUSTOM_GIT=y -BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="git://git.freescale.com/imx/uboot-imx.git" -BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="rel_imx_2.6.35_11.09.01" +BR2_TARGET_UBOOT_CUSTOM_REPO_URL="git://git.freescale.com/imx/uboot-imx.git" +BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="rel_imx_2.6.35_11.09.01" # filesystem BR2_TARGET_ROOTFS_EXT2=y
@@ -17,6 +17,6 @@ BR2_TARGET_ROOTFS_EXT2=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y -BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.freescale.com/imx/linux-2.6-imx.git" -BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="rel_imx_2.6.35_11.09.01" +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.freescale.com/imx/linux-2.6-imx.git" +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="rel_imx_2.6.35_11.09.01" BR2_LINUX_KERNEL_DEFCONFIG="imx5"
configs/phy3250_defconfig +4 -4
@@ -27,8 +27,8 @@ BR2_TARGET_UBOOT=y BR2_TARGET_UBOOT_BOARDNAME="phy3250" BR2_TARGET_UBOOT_CUSTOM_GIT=y BR2_TARGET_UBOOT_VERSION="master" -BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx" -BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="master" +BR2_TARGET_UBOOT_CUSTOM_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx" +BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="master" BR2_TARGET_UBOOT_FORMAT_BIN=y BR2_TARGET_LPC32XXCDL=y BR2_TARGET_LPC32XXCDL_BOARDNAME="phy3250"
@@ -39,8 +39,8 @@ BR2_TARGET_LPC32XXCDL_BOARDNAME="phy3250 # BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y -BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx" -BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="master" +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx" +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="master" BR2_LINUX_KERNEL_VERSION="master" BR2_LINUX_KERNEL_PATCH="" BR2_LINUX_KERNEL_USE_DEFCONFIG=y
configs/rpi_defconfig +2 -2
@@ -16,8 +16,8 @@ BR2_DEFAULT_KERNEL_VERSION="3.6.11" BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y -BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://github.com/raspberrypi/linux.git" -BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="0006326" +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://github.com/raspberrypi/linux.git" +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="0006326" BR2_LINUX_KERNEL_USE_DEFCONFIG=y BR2_LINUX_KERNEL_DEFCONFIG="bcmrpi" BR2_LINUX_KERNEL_ZIMAGE=y
PATCH v4 1/1 linux: mention 3.x.y kernels in 'custom version' help
In reply to Thomas De Schampheleire(also fix grammatical error versions -> version)
---
v4: no changes
v3: no changes
(v2): new patch in series, although only loosely related.
linux/Config.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
linux/Config.in +2 -2
@@ -37,8 +37,8 @@ config BR2_LINUX_KERNEL_SAME_AS_HEADERS config BR2_LINUX_KERNEL_CUSTOM_VERSION bool "Custom version" help - This option allows to use a specific 2.6.x or 2.6.x.y - official versions, as available on kernel.org + This option allows to use a specific official version from + kernel.org, like 2.6.x, 2.6.x.y, 3.x.y, ... config BR2_LINUX_KERNEL_CUSTOM_TARBALL bool "Custom tarball"
PATCH v4 1/1 linux: mention 3.x.y kernels in 'custom version' help
Dear Thomas De Schampheleire,
Quoted 3 lines · Thomas De Schampheleire
(also fix grammatical error versions -> version)
Signed-off-by Thomas De Schampheleire <[email protected]>
Peter, I believe this one can be committed now.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 1/1 linux/uboot: add support for custom Mercurial repositories
In reply to Thomas De SchampheleireDear Thomas De Schampheleire,
Quoted 5 lines · Thomas De Schampheleire
This series adds support for custom Mercurial repositories in uboot and linux packages.
This version is rebased with the 2013.08 master, there are only a few real changes.
Since it seems we have issues deciding what to do with the Config.in.legacy handling for string options, I was thinking: can't we just avoid the problem altogether? Instead of having separate Config.in options for each of Git, Mercurial, SVN and so on, what about just adding an option "BR2_TARGET_LINUX_CUSTOM_REPO_METHOD" which allows the user to select git, hg, svn or cvs, and keep the other option names unchanged. I admit it's a bit funky to keep options such as BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL to store the location of a Mercurial repository, but well, since we can't make up your mind on the Config.in.legacy stuff, maybe that's a way of at least getting your feature merged.
I'm just thinking of a way to move forward, not sure it's the right solution.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 1/1 linux/uboot: add support for custom Mercurial repositories
Hi Thomas,
Thanks for coming back to this...
Quoted 22 lines · Thomas Petazzoni
Dear Thomas De Schampheleire,
Quoted 5 lines · Thomas De Schampheleire
This series adds support for custom Mercurial repositories in uboot and linux packages.
This version is rebased with the 2013.08 master, there are only a few real changes.
Since it seems we have issues deciding what to do with the Config.in.legacy handling for string options, I was thinking: can't we just avoid the problem altogether? Instead of having separate Config.in options for each of Git, Mercurial, SVN and so on, what about just adding an option "
BR2_TARGET_LINUX_CUSTOM_REPO_METHOD" which allows the user to select git, hg, svn or cvs, and keep the other option names unchanged. I admit it's a bit funky to keep options such asBR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URLto store the location of a Mercurial repository, but well, since we can't make up your mind on the Config.in.legacy stuff, maybe that's a way of at least getting your feature merged.
Quoted 3 lines
I'm just thinking of a way to move forward, not sure it's the right solution.
Currently, both for Linux and Uboot, the choice between Git and Hg is done via the 'Version' choice (which provides the choice between a number of real versions, custom tarball, and git and hg). So there is already a choice and no real separate option for each version control system.
What my patches did was avoid adding extra options for Mercurial, by re-using (and renaming) the git options to specify the URL and revision. Not renaming the git options is indeed possible, but pretty funky indeed. I'm not a big fan of this, to be honest.
It's true that it seems difficult to reach a decision in the legacy questions. From the top of my head, the main questions are:
1. Do we want that legacy options are automatically propagated to their new options, when possible, or should the user do this?
2. Do we accept that the user needs to save-and-reopen menuconfig in case we opt for automatic propagation.
I see three ways out:
a. we reach a consensus
b. a decision is taken by the maintainer, possibly without consensus c. we leave the current situation (for now)
Note that my patchset does not _change_ the current situation. Rather, it merely documents how you should handle legacy options in this current situation, both to the user and the developer. The Mercurial support just follows the existing approach.
This provides a good way forward in my opinion, if a and b turn out to be impossible: we accept the patchset as it is, knowing that it just follows the same route as we were going, and if we want to change something about the legacy handling we can do that later.
Note also that regardless of how we proceed, I really want this to be part of 2013.11, because this series is already circulating for a long time.
Best regards,
Thomas
PATCH v4 1/1 linux/uboot: add support for custom Mercurial repositories
All,
Quoted 63 lines · Thomas De Schampheleire
Hi Thomas,
Thanks for coming back to this...
Quoted 22 lines · Thomas Petazzoni
Dear Thomas De Schampheleire,
Quoted 5 lines · Thomas De Schampheleire
This series adds support for custom Mercurial repositories in uboot and linux packages.
This version is rebased with the 2013.08 master, there are only a few real changes.
Since it seems we have issues deciding what to do with the Config.in.legacy handling for string options, I was thinking: can't we just avoid the problem altogether? Instead of having separate Config.in options for each of Git, Mercurial, SVN and so on, what about just adding an option "
BR2_TARGET_LINUX_CUSTOM_REPO_METHOD" which allows the user to select git, hg, svn or cvs, and keep the other option names unchanged. I admit it's a bit funky to keep options such asBR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URLto store the location of a Mercurial repository, but well, since we can't make up your mind on the Config.in.legacy stuff, maybe that's a way of at least getting your feature merged.Quoted 3 lines
I'm just thinking of a way to move forward, not sure it's the right solution.
Currently, both for Linux and Uboot, the choice between Git and Hg is done via the 'Version' choice (which provides the choice between a number of real versions, custom tarball, and git and hg). So there is already a choice and no real separate option for each version control system.
What my patches did was avoid adding extra options for Mercurial, by re-using (and renaming) the git options to specify the URL and revision. Not renaming the git options is indeed possible, but pretty funky indeed. I'm not a big fan of this, to be honest.It's true that it seems difficult to reach a decision in the legacy questions. From the top of my head, the main questions are:
1. Do we want that legacy options are automatically propagated to their new options, when possible, or should the user do this?
2. Do we accept that the user needs to save-and-reopen menuconfig in case we opt for automatic propagation.I see three ways out:
a. we reach a consensus
b. a decision is taken by the maintainer, possibly without consensus c. we leave the current situation (for now)Note that my patchset does not _change_ the current situation. Rather, it merely documents how you should handle legacy options in this current situation, both to the user and the developer. The Mercurial support just follows the existing approach.
This provides a good way forward in my opinion, if a and b turn out to be impossible: we accept the patchset as it is, knowing that it just follows the same route as we were going, and if we want to change something about the legacy handling we can do that later.
Quoted 3 lines
Note also that regardless of how we proceed, I really want this to be part of 2013.11, because this series is already circulating for a long time.
ping?
Thanks,
Thomas