All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1 of 6 v2] Config.in.legacy: update description
Date: Mon, 12 Aug 2013 07:59:37 +0200	[thread overview]
Message-ID: <520879C9.8000000@mind.be> (raw)
In-Reply-To: <2942a6d3dd9f0f3fd864.1374650578@BEANTN0L019720>

On 24/07/13 09:22, Thomas De Schampheleire wrote:
> 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, I have added an example of how to handle the renaming of a string
> config option. Because a string option cannot 'select' something else, a wrapper
> symbol is needed of type bool.
>
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

  Note, however, that when you change a string option, it is quite 
difficult to propagate the old value to the new symbol automatically 
(you'd have to add a default to the new option). So renaming string 
options should be avoided.

  Regards,
  Arnout

>
> ---
> (v2): new patch in this series
>
>   Config.in.legacy |  22 +++++++++++++++++-----
>   1 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/Config.in.legacy b/Config.in.legacy
> --- a/Config.in.legacy
> +++ b/Config.in.legacy
> @@ -3,11 +3,10 @@
>   #
>   # 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.
> +# there is an equivalent (set of) new symbols, these should be select'ed by
> +# the old symbol. This will make the transition for the user more convenient.
> +# The old symbol should select BR2_LEGACY, so that the user is informed at
> +# build-time about selected legacy options.
>   #
>   # 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 +14,19 @@
>   # 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.
> +# If the old symbol is of type string, and the symbol has been renamed, you
> +# should add it as a bool with another name (BR2_<foo>_WRAP), that defaults
> +# to y if the old string is not set at its default value. For example:
> +#     config BR2_FOO_STRING
> +#             string "Some foo string"
> +# would become:
> +#     config BR2_FOO_STRING_WRAP
> +#             bool "Foo string option has been renamed."
> +#             default y if BR2_FOO_STRING != ""
> +#             depends on BR2_LEGACY
> +#             help
> +#               <suitable help text>
> +#
>
>   config BR2_LEGACY
>   	bool
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>


-- 
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

  parent reply	other threads:[~2013-08-12  5:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-24  7:22 [Buildroot] [PATCH 0 of 6 v2] linux/uboot: add support for custom Mercurial repositories Thomas De Schampheleire
2013-07-24  7:22 ` [Buildroot] [PATCH 1 of 6 v2] Config.in.legacy: update description Thomas De Schampheleire
2013-07-27 13:50   ` Thomas Petazzoni
2013-08-12  5:59   ` Arnout Vandecappelle [this message]
2013-08-13 16:31   ` Arnout Vandecappelle
2013-08-14 16:27     ` Thomas De Schampheleire
2013-07-24  7:22 ` [Buildroot] [PATCH 2 of 6 v2] linux: don't take HEAD as default for git repositories Thomas De Schampheleire
2013-08-12  6:02   ` Arnout Vandecappelle
2013-08-13 10:00   ` Thomas Petazzoni
2013-07-24  7:23 ` [Buildroot] [PATCH 3 of 6 v2] linux: add support for custom Mercurial repository Thomas De Schampheleire
2013-08-12  6:12   ` Arnout Vandecappelle
2013-08-12 10:54     ` Thomas De Schampheleire
2013-08-12 11:01       ` Arnout Vandecappelle
2013-08-13  9:09     ` Thomas Petazzoni
2013-08-13 16:30       ` Arnout Vandecappelle
2013-08-14 17:06         ` Thomas De Schampheleire
2013-08-17  8:13           ` Thomas De Schampheleire
2013-08-19 16:05             ` Arnout Vandecappelle
2013-08-20  8:36               ` Thomas De Schampheleire
2013-08-21  5:40                 ` Arnout Vandecappelle
2013-08-27 12:29                   ` Thomas De Schampheleire
2013-08-27 14:14                   ` Thomas De Schampheleire
2013-07-24  7:23 ` [Buildroot] [PATCH 4 of 6 v2] u-boot: " Thomas De Schampheleire
2013-07-24  7:23 ` [Buildroot] [PATCH 5 of 6 v2] linux/uboot: line-up repository-related configuration options Thomas De Schampheleire
2013-07-24  7:23 ` [Buildroot] [PATCH 6 of 6 v2] linux: mention 3.x.y kernels in 'custom version' help Thomas De Schampheleire

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=520879C9.8000000@mind.be \
    --to=arnout@mind.be \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

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

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