On 11/14/13, 10:04 AM, Phil Blundell wrote:
On Thu, 2013-11-14 at 09:49 -0600, Mark Hatle wrote:
On 11/14/13, 7:42 AM, Phil Blundell wrote:
On Thu, 2013-11-14 at 06:27 -0700, Gary Thomas wrote:
Also, is "-" actually valid? I seem to recall having problems when my build
tree had the hyphen ("-") in the path.
Paths with "-" in certainly work for me. If there are any recipes which
break in that situation then we should just fix them.
We found an issue with paths that -start- with a '-', there are apparently many
places where paths are passed into various shell, and the initial '-' can be
read as an argument identifier.
Right, I can imagine that this would break fairly badly. But if we're
going to require TMPDIR to be an absolute path (which seems perfectly
reasonable) then by definition it can't start with - so this will
presumably become a non-issue.
Except there are a number of packages that try to parse pieces of strings
derived from TMPDIR.
Set your TMPDIR path to include "-Dmypath" some time. SVN will blow up.. :P
I don't believe Qi Chen sent it to the list, but we built path names with all of
the special characters and tried to run builds. The specific list is based on
the results of those tests. The other items are already broken, and we're
trying to be explicit with this for end users. (Note, it's really the TMPDIR
that matters.. the 'build' directory is a lot more flexible.)
Yeah, I saw the results of those tests. My slight reservation with that
methodology is that, if any single recipe fails with a given character
in TMPDIR, no matter how obscure that recipe might be, it seems that
this is enough to make that character verboten. For example, the
rationale for excluding "+" seems to be that it breaks tcl; if this is
the only recipe that fails then it seems like it might be worth at least
trying to fix tcl rather than excluding "+" from TMPDIRs for ever more.
I agree, in the case above, the SVN example I've asked our engineers to look
into trying to fix that case. But what they're finding is that once you fix one
case, then the next breaks.. and the next breaks.
But, clearly, there are some characters in the list that are "just
silly" to have in pathnames. I don't think anybody would be surprised
to learn that "*" and "$" cause problems and blacklisting those ones
does seem quite reasonable.
:)
I'd like to see us blacklist the bunch, and then turn around and start opening
the set backup. But I don't know how practical this actually is -- unless we
can get automated test machines running each odd-ball combination on a nightly
basis.
--Mark
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
