|author||Arnout Vandecappelle <email@example.com>||2016-10-15 16:51:07 +0200|
|committer||Peter Korsgaard <firstname.lastname@example.org>||2016-10-15 23:14:45 +0200|
The BR2_DEPRECATED logic is a lot less useful than the legacy handling, because the symbols just disappears without warning to the user. For example, we had a few defconfigs that were using deprecated symbols (which were not actually used because BR2_DEPRECATED wasn't set) so these didn't build the expected code anymore. Also, the idea behind BR2_DEPRECATED is that you can easily revive it again if there is interest. However, it is relatively easy to revert the removal of a package as well. The deprecation is also more effort because it has to be removed twice: once when deprecating, and once when really removing. It doesn't make sense to add a legacy entry for BR2_DEPRECATED. Users who actually used it will get legacy warnings instead. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <email@example.com> Signed-off-by: Peter Korsgaard <firstname.lastname@example.org>
Diffstat (limited to 'Makefile.legacy')
1 files changed, 0 insertions, 3 deletions
diff --git a/Makefile.legacy b/Makefile.legacy
index 764cfcd117..800c08926c 100644
@@ -4,9 +4,6 @@
# This file contains placeholders to detect backward-compatibility problems.
# When a buildroot "API" feature is being deprecated, a rule should be added
# here that issues an error when the old feature is used.
-# This file is not included if BR2_DEPRECATED is selected, so it is possible
-# to bypass the errors (although that's usually a bad idea).
$(error "You have legacy configuration in your .config! Please check your configuration.")