8402 2015-09-25 19:06:54 +0000 LAYERDIR is used as-is in BBFILE_PATTERN, when it should be regex escaped 2016-05-19 16:32:33 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified x86 Multiple RESOLVED FIXED Medium minor 2.2 1 kergoth kergoth poky.bs.watcher poky.watcher ross.burton --- --- Don't know oldest_to_newest 54697 0 kergoth 2015-09-25 19:06:54 +0000 I think bitbake should set a variable which is just re.escape(LAYERDIR), for us to use in BBFILE_PATTERN, i.e. LAYERDIR_ESCAPED or LAYERDIR_RE or so. Doing it purely in layer.conf could be problematic since the re module isn't imported. This would avoid issues with regex special characters in paths causing breakage, at least at this level. Other parts of the build can hit problems in certain cases, but we should at least handle this correctly ourselves. 54698 1 kergoth 2015-09-25 19:13:45 +0000 (In reply to comment #0) > I think bitbake should set a variable which is just re.escape(LAYERDIR), for > us to use in BBFILE_PATTERN, i.e. LAYERDIR_ESCAPED or LAYERDIR_RE or so. > Doing it purely in layer.conf could be problematic since the re module isn't > imported. This would avoid issues with regex special characters in paths > causing breakage, at least at this level. Other parts of the build can hit > problems in certain cases, but we should at least handle this correctly > ourselves. Another option would be for bitbake to be a bit smarter about its LAYERDIR expansions. Assume that a LAYERDIR ref in BBFILE_PATTERN has to be escaped, whereas any other expansions don't, but that's likely too implicit / too much magic :) 60936 2 kergoth 2016-04-07 18:46:09 +0000 https://github.com/kergoth/poky/commit/14d521b is the implementation I proposed in comment #1, and https://github.com/kergoth/poky/commit/d24c6d5 the one from comment #2. Thoughts? I dislike how implicit the latter is, but trying to get every layer to modify their layer.conf seems like a losing proposition, and they'd need to add LAYERDIR_RE ?= "${LAYERDIR}" to be compatible with previous bitbake versions, so I'm inclined to say we should go with the latter instead. 60977 3 kergoth 2016-04-08 16:29:54 +0000 Having discussed this with Richard, we're on the same page on this, we should go with route #1 and just deal with the migration rather than adding more magic. I'll submit the patch for 2.2. 62340 4 ross.burton 2016-05-19 16:32:33 +0000 Fixed in bitbake 72900522778b6ff08b135bf8bb97dff3f1a20bd9.