diff options
author | Christopher Larson <chris_larson@mentor.com> | 2012-05-15 20:26:25 -0500 |
---|---|---|
committer | Saul Wold <sgw@linux.intel.com> | 2012-05-17 19:42:55 +0300 |
commit | dc7e4a79d9a1884b4c5705ef3173613958204b50 (patch) | |
tree | 64de9725f37fdf5614ff5477144438adcc4ae71e /meta/recipes-connectivity/dhcp/dhcp-4.2.3-P2 | |
parent | 3c18344e8a6a4a0b7aad1d1322d02ab8accc9db1 (diff) | |
download | openembedded-core-dc7e4a79d9a1884b4c5705ef3173613958204b50.tar.gz openembedded-core-dc7e4a79d9a1884b4c5705ef3173613958204b50.tar.bz2 openembedded-core-dc7e4a79d9a1884b4c5705ef3173613958204b50.tar.xz openembedded-core-dc7e4a79d9a1884b4c5705ef3173613958204b50.zip |
oe.types: give the regex type more sane semantics
Currently, if a variable is unset or has an empty value, the regex type
will return a match object which always matches. Not all variable types
will necessarily have the same behavior for handling defaults. I believe
that returning a match object which matches nothing when a variable is
unset is superior to returning one which matches anything, and the user
can always explicitly request anything via '.*', if that's what they
want.
This constructs a null pattern object which will never match, and uses
it when encountering an unset or empty variable (currently, these two
things are one and the same, as maketype is handling the default. we may
well want to shift that logic into the individual types, giving them
more control over default behavior, but currently the behavior is at
least relatively consistent -- no difference between unset and empty
variables).
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Diffstat (limited to 'meta/recipes-connectivity/dhcp/dhcp-4.2.3-P2')
0 files changed, 0 insertions, 0 deletions