svn commit: r437215 - in head/graphics: gbm libEGL libGL libglapi

[Matthew Rezny]

On Thursday 30 March 2017 05:36:03 Jan Beich wrote:
> Matthew Rezny <rezny at freebsd.org> writes:
> > On Wednesday 29 March 2017 19:51:55 Jan Beich wrote:
> >> Matthew Rezny <rezny at FreeBSD.org> writes:
> >> > -	@${REINPLACE_CMD} -e 's|x86_64|amd64|' \
> >> > +	@${REINPLACE_CMD} -e 's|x86_64|amd64|' -e 's|\\S\*//|[:space:]* 
//|'
> >> > \
> >> 
> >> [:space:] is invalid character class thus treated as a list of
> >> characters.
> >> \S corresponds to [^[:space:]], while \s to [[:space:]].
> >> 
> >>   $ man pcrepattern | col -b | fgrep -m1 \\S
> >>   
> >>            \S     any character that is not a white space character
> >> 
> >> This may break build given -march, etc. are no longer stripped.
> > 
> > I wish that information had been presented when I said "I guess it should
> > have been [:space:] instead of [:graph:] in the replacement." after you
> > stated [:graph:] was plain incorrect, although it is what had been
> > previously suggested to me and did seem to be working.
> 
> I didn't focus on pointing out every mistake with the existing hack
> because it was soon going away. Now that devel/libclc depends on llvm40
> the original motivation to hold out on 17.* (bug 217016) before 2017Q2
> has been weakened.
> 
Pointing out something is wrong without giving the correct solution is not 
helpful. The upstream change in the 17.1-dev branch was not directly 
applicable to 13.0.x, so the the 'hack' would remain unless I was going to 
change to change the configure.ac and patch-configure myself, which is certainly 
more work that to edit the post-patch and it would have been the same changes 
in either place lacking clearer input.

Nobody said anything to me about committing an update to libclc at this 
moment. I do not believe that has tested in combination with the rest of the 
graphics stack at the current versions in ports, the mix of LLVM versions 
almost certainly will be a problem, and it's a day before the quarterly 
branch. WTF? I've been holding off Mesa 17.x and LLVM4.0 for after that branch 
while attempting to get Xorg 1.19 ready in time for that. The latter won't 
happen because it took over a week to even start an exp-run on the bsd.xorg.mk 
changes. I just explained the reason for holding of an update of libclc 
yesterday in a PR that proposed a more recent snapshot for the transition to 
dependence on llvm40. I had not even gotten everything onto llvm39 yet; pocl 
0.14 should be compatible past 3.8, but it is not yet released and I had 
difficulties with rc1 as they switched to cmake so the build system needs to be 
redone. While I'm sure Mesa 17.0.x will be ok with llvm40 after appropriate 
patching (I had to add several patches for clover in Mesa 13), I cannot say 
the same for all the OpenCL ports, i.e. beignet which was only recently made 
compatible past llvm37 with the 1.3.0 update that allowed it to use llvm39.  
So I expect r438268 to be reverted, or someone else to handle all the fallout 
this causes on the quarterly branch during Q2. I realize multiple people want 
to help, but we need some coordination or else we are just wasting each 
other's time. Sorry to be brunt, but that was an ill timed commit.

> > To be sure there is no misunderstanding now, would you consider this
> > correct? @${REINPLACE_CMD} -e 's|x86_64|amd64|' -e
> > 's|\\S\*//|[^[:space:]]* //|' \
> Not quite, adding extra space after [] is unnecessary.
> 
>   -e 's|\\S\*|[^[:space:]]*|' \

It is interesting how many variations appear to produce the same result. You 
mention the space is not needed, so 's|\\S\*//|[^[:space:]]*//|' but then the 
example has the trailing // removed. Any reason why?