On Mon, 2011-02-28 at 18:53 -0800, Khem Raj wrote:
> On (23/02/11 16:51), Richard Purdie wrote:
> > The behaviour of "#" in multiline variables is established but very
> > confusing for people and can cause data to disappear unexpectedly.
> > 
> > Currently this construct would drop one of the patches:
> > 
> > SRC_URI = "http://z/ \
> >           # file://xxx.patch \
> >            file://yyy.patch"
> > 
> > which in that context makes sense and people do use this. On the other
> > hand people have done things like:
> > 
> > VARIABLE = "Some text which references the C code: \
> >             #include "config.h" \
> >             where we wanted to make some comment"
> > 
> > and then wondered why the line went missing. Since this is done
> > silently, it can be hard to even realise there was a problem.
> > 
> > I've applied a patch in Poky which triggers big warnings about doing
> > that and also changed the behaviour to include the line instead of
> > dropping it. I'm not sure whether this change is desirable or not. It
> > would certainly improve user experience if we didn't special case
> > commends in multi line strings as its not what people would expect
> > having used any other language.
> > 
> > Feedback welcome...
> 
> would it make sense to treat file:// http:// patch:// etc (SRC_URIs) 
> specially ? and treat # before it
> as comment but not otherwise and we may ask to escape special
> characters like # inside strings if they are not supposed to be
> interpreted by bitbake. If # appears in string and is not above case
> then we warn about it ?

I think it might be worth the effort to try and apply a bit of
"Principle of Least Astonishment" [1].  Having different handling of
characters in strings depending on which variables they are used in
certainly would seem surprising to some.

  [1] http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Going down that path, how would you handle use-cases where a variable is
appended to SRC_URI.  Which '#' handling should be applied to it then?
If the special SRC_URI handling should be applied, should the same
variable then result in a different value when applied to other (than
SRC_URI) variables?

Let's just stick to one way.

/Esben


_______________________________________________
Bitbake-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bitbake-dev

Reply via email to