Skip to contentSkip to conversation

local.conf.sample: Cleanup and improve

PATCH In review Richard Purdie 3 participants 5 messages Aug 12, 2011

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 local.conf.sample: Cleanup and improve

local.conf is the first thing anyone new to the project sees. Over time it has built up a ton cruft and isn't even accurate in places.

This patch:

* Moves things to local.conf.sample.extended if a new user is unlikely to need to immediately care about the options
* Reorders the file to be more intuitive to a new user
* Moves certain default values to default-distrovars.inc in cases where most users wouldn't want to change the value
* Adds large blocks of text to explain what an option does. There have been too many cases of a user not realising what some of these settings do and how they can use them to their advantage (like DL_DIR for example).

meta/conf/distro/include/default-distrovars.inc +6 -0
index 2ef25e4..c2fd77e 100644
@@ -41,3 +41,9 @@ COMMERCIAL_QT ?= ""
 COMMON_LICENSE_DIR ??= "${COREBASE}/meta/files/common-licenses"
 
 BB_GENERATE_MIRROR_TARBALLS ??= "0"
+
+NO32LIBS ??= "1"
+
+# Default to emitting logfiles if a build fails.
+BBINCLUDELOGS ??= "yes"
+
meta/conf/local.conf.sample +167 -161

367 lines not on this page · raw message

meta/conf/local.conf.sample.extended new file +116 -0

116 lines not on this page · raw message

#1 lore raw
Quoted 21 lines · Richard Purdie

local.conf is the first thing anyone new to the project sees. Over time it has built up a ton cruft and isn't even accurate in places.

This patch:

* Moves things to local.conf.sample.extended if a new user is unlikely to need to immediately care about the options
* Reorders the file to be more intuitive to a new user
* Moves certain default values to default-distrovars.inc in cases where most users wouldn't want to change the value
* Adds large blocks of text to explain what an option does. There have been too many cases of a user not realising what some of these settings do and how they can use them to their advantage (like DL_DIR for example).

meta/conf/distro/include/default-distrovars.inc +0 -0
index 2ef25e4..c2fd77e 100644

...

meta/conf/distro/include/default-distrovars.inc

Quoted 13 lines
meta/conf/distro/include/default-distrovars.inc +13 -0
+#
+# Package Management configuration
+#
+# This variable lists which packaging formats to enable. Multiple package backends 
+# can be enabled at once and the first item listed in the variable will be used 
+# to generate the root filesystems.
+# Options are:
+#  - 'package_deb' for debian style deb files
+#  - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
+#  - 'package_rpm' for rpm style packages
+# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
+# We default to rpm:
+PACKAGE_CLASSES ?= "package_rpm"

While I certainly advocate package_rpm usage, should we be changing from the default of ipk to rpm here? I'm tempted to say we need to stick w/ ipk for the time being...

...

Quoted 15 lines
meta/conf/distro/include/default-distrovars.inc +11 -2
+#
+# Interactive shell configuration
+#
+# Under certain circumstances the system may need input from you and to do this it 
+# can launch an interactive shell. It needs to do this since the build is 
+# multithreaded and needs to be able to handle the case where more than one parallel
+# process may require the user's attention. The default is to use xterm.
+#
+# Examples of the occasions this may happen are when resolving patches which cannot
+# be applied, to use the devshell or the kernel menuconfig
+#
 # If you do not use (or have installed) xterm you will need to
 # uncomment these variables and set them to the terminal you wish to use
-# when resolving patches which cannot be applied
-# Supported shell prefixes for *_TERMCMD and *_TERMCMDRUN ARE:

meta/conf/distro/include/default-distrovars.inc

Quoted 10 lines
meta/conf/distro/include/default-distrovars.inc +3 -1
+# 
+# Supported shell prefixes for *_TERMCMD and *_TERMCMDRUN are:
 # GNOME, SCREEN, XTERM and KONSOLE
 # Note: currently, Konsole support only works for KDE 3.x due to the way
 # newer Konsole versions behave
 #TERMCMD = "${XTERM_TERMCMD}"
 #TERMCMDRUN = "${XTERM_TERMCMDRUN}"
-# Alternatively, if you prefer you can disable patch resolution:
+# You can disable interactive patch resolution (tasks will just fail instead) with:
 #PATCHRESOLVE = "noop"

Should patch resolution be noop by default? (I suspect due to my above concern w/ ipkg, changing the behavior now is likely a bad idea.)

...

Quoted 6 lines
meta/conf/local.conf.sample.extended new file +0 -0
new file mode 100644
index 0000000..a42774c
@@ -0,0 +1,116 @@

...

Quoted 17 lines
meta/conf/local.conf.sample.extended new file +17 -0
+# The following are used to control options related to debugging.
+#
+# Uncomment this to change the optimization to make debugging easer, at the 
+# possible cost of performance.
+# DEBUG_BUILD = "1"
+#
+# Uncomment this to disable the stripping of the installed binaries
+# INHIBIT_PACKAGE_STRIP = "1"
+#
+# Uncomment this to disable the split of the debug information into -dbg files
+# INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
+#
+# When splitting debug information, the following controls the results of the
+# file splitting.
+#
+#  .debug (default):
+#    When splitting the debug information will be placed into

meta/conf/local.conf.sample.extended line 60

Quoted 10 lines
meta/conf/local.conf.sample.extended new file +10 -0
+#    a .debug directory in the same dirname of the binary produced:
+#      /bin/foo -> /bin/.debug/foo
+#
+#  debug-file-directory:
+#    When splitting the debug information will be placed into
+#    a central debug-file-directory, /usr/lib/debug:
+#      /bin/foo -> /usr/lib/debug/bin/foo.debug
+#
+#    Any source code referenced in the debug symbols will be copied
+#    and made available within the /usr/src/debug directory

May have been a bug in the original. The "Any source code ..." comment refers to both of the above. It should likely lose two spaces in the indent...

meta/conf/local.conf.sample.extended line 64

Quoted 4 lines
meta/conf/local.conf.sample.extended new file +4 -0
+#
+#PACKAGE_DEBUG_SPLIT_STYLE = '.debug'
+# PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'
+

--Mark

#2 lore raw
Quoted 33 lines · Mark Hatle
Quoted 21 lines · Richard Purdie

local.conf is the first thing anyone new to the project sees. Over time it has built up a ton cruft and isn't even accurate in places.

This patch:

* Moves things to local.conf.sample.extended if a new user is unlikely to need to immediately care about the options
* Reorders the file to be more intuitive to a new user
* Moves certain default values to default-distrovars.inc in cases where most users wouldn't want to change the value
* Adds large blocks of text to explain what an option does. There have been too many cases of a user not realising what some of these settings do and how they can use them to their advantage (like DL_DIR for example).

meta/conf/distro/include/default-distrovars.inc +0 -0
index 2ef25e4..c2fd77e 100644

...

Quoted 9 lines
meta/conf/distro/include/default-distrovars.inc +9 -0
+#
+# Package Management configuration
+#
+# This variable lists which packaging formats to enable. Multiple package backends 
+# can be enabled at once and the first item listed in the variable will be used 
+# to generate the root filesystems.
+# Options are:
+#  - 'package_deb' for debian style deb files
+#  - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
Quoted 8 lines

meta/conf/distro/include/default-distrovars.inc

Quoted 4 lines
meta/conf/distro/include/default-distrovars.inc +4 -0
+#  - 'package_rpm' for rpm style packages
+# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
+# We default to rpm:
+PACKAGE_CLASSES ?= "package_rpm"

While I certainly advocate package_rpm usage, should we be changing from the default of ipk to rpm here? I'm tempted to say we need to stick w/ ipk for the time being...

Sorry, this was intended to be ipk in the OE-Core version and I've just messed up that difference. I'll fix, thanks.

Quoted 9 lines
Quoted 9 lines

# If you do not use (or have installed) xterm you will need to

 # uncomment these variables and set them to the terminal you wish to use
meta/conf/distro/include/default-distrovars.inc +2 -2
-# when resolving patches which cannot be applied
-# Supported shell prefixes for *_TERMCMD and *_TERMCMDRUN ARE:
+# 
+# Supported shell prefixes for *_TERMCMD and *_TERMCMDRUN are:
 # GNOME, SCREEN, XTERM and KONSOLE
 # Note: currently, Konsole support only works for KDE 3.x due to the way
 # newer Konsole versions behave
Quoted 8 lines

meta/conf/distro/include/default-distrovars.inc

Quoted 5 lines

#TERMCMD = "${XTERM_TERMCMD}"
#TERMCMDRUN = "${XTERM_TERMCMDRUN}"

meta/conf/distro/include/default-distrovars.inc +1 -1
-# Alternatively, if you prefer you can disable patch resolution:
+# You can disable interactive patch resolution (tasks will just fail instead) with:
 #PATCHRESOLVE = "noop"

Should patch resolution be noop by default? (I suspect due to my above concern w/ ipkg, changing the behavior now is likely a bad idea.)

Good question. I suspect most people prefer noop and it would make more sense for unattended builds...

Quoted 22 lines
Quoted 22 lines
meta/conf/distro/include/default-distrovars.inc +22 -0
+# The following are used to control options related to debugging.
+#
+# Uncomment this to change the optimization to make debugging easer, at the 
+# possible cost of performance.
+# DEBUG_BUILD = "1"
+#
+# Uncomment this to disable the stripping of the installed binaries
+# INHIBIT_PACKAGE_STRIP = "1"
+#
+# Uncomment this to disable the split of the debug information into -dbg files
+# INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
+#
+# When splitting debug information, the following controls the results of the
+# file splitting.
+#
+#  .debug (default):
+#    When splitting the debug information will be placed into
+#    a .debug directory in the same dirname of the binary produced:
+#      /bin/foo -> /bin/.debug/foo
+#
+#  debug-file-directory:
+#    When splitting the debug information will be placed into
Quoted 8 lines

meta/conf/distro/include/default-distrovars.inc

Quoted 5 lines
meta/conf/distro/include/default-distrovars.inc +5 -0
+#    a central debug-file-directory, /usr/lib/debug:
+#      /bin/foo -> /usr/lib/debug/bin/foo.debug
+#
+#    Any source code referenced in the debug symbols will be copied
+#    and made available within the /usr/src/debug directory

May have been a bug in the original. The "Any source code ..." comment refers to both of the above. It should likely lose two spaces in the indent...

Ok, this was just a cut and paste :)

Cheers,

Richard

#3 lore raw
Quoted 5 lines · Richard Purdie
Quoted 2 lines

Should patch resolution be noop by default? (I suspect due to my above concern w/ ipkg, changing the behavior now is likely a bad idea.)

Good question. I suspect most people prefer noop and it would make more sense for unattended builds...

Agreed, I think noop is probably the best/least surprising default behaviour.

p.

#4 lore raw
Quoted 9 lines · Phil Blundell
Quoted 5 lines · Richard Purdie
Quoted 2 lines

Should patch resolution be noop by default? (I suspect due to my above concern w/ ipkg, changing the behavior now is likely a bad idea.)

Good question. I suspect most people prefer noop and it would make more sense for unattended builds...

Agreed, I think noop is probably the best/least surprising default behaviour.

My suggestion then is a separate commit that sets noop as the default behavior..

(I almost always run w/ noop set.)

--Mark

Quoted 8 lines

p.

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core