On Tue, 2011-03-01 at 12:47 +0100, Esben Haabendal wrote:
> 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.

I agree, either we accept comments in multiline variables or we don't
but making it conditional upon some context is just going to make things
worse.

Cheers,

Richard

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

Reply via email to