Date: Thu, 30 Mar 2017 07:26:45 +0200 From: Matthew Rezny <rezny@freebsd.org> To: Jan Beich <jbeich@freebsd.org> Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org, Johannes M Dieterich <jmd@freebsd.org> Subject: Re: svn commit: r437215 - in head/graphics: gbm libEGL libGL libglapi Message-ID: <19694803.doR80QHWTi@workstation.reztek> In-Reply-To: <8tnn-5tcs-wny@FreeBSD.org> References: <201703291657.v2TGvrpM076369@repo.freebsd.org> <1824022.AbFPd1OJUh@workstation.reztek> <8tnn-5tcs-wny@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 30 March 2017 05:36:03 Jan Beich wrote:
> Matthew Rezny <rezny@freebsd.org> writes:
> > On Wednesday 29 March 2017 19:51:55 Jan Beich wrote:
> >> Matthew Rezny <rezny@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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19694803.doR80QHWTi>