On Fri, 12 Feb 2021 at 14:15, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
>
> On 2/12/21 3:55 PM, Markus Mayer wrote:
> > On Fri, 12 Feb 2021 at 13:29, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> >>
> >> On 2/12/21 2:51 PM, Markus Mayer wrote:
> >>>> To prevent issues when the ".o" extension appears in a directory path,
> >>>> ensure that the ".o" -> ".lo" substitution is only performed for the
> >>>> final file extension.
> >>>
> >>> If the subject should be "[PATCH] xfsprogs: ...", please let me know.
> >>
> >> Nah, that's fine, I noticed it.
> >>
> >> So did you have a path component that had ".o" in it that got substituted?
> >> Is that what the bugfix is?
> >
> > Yes and yes.
> >
> > Specifically, I was asked to name the build directory in our build
> > system "workspace.o" (or something else ending in .o) because that
> > causes the automated backup to skip backing up temporary build
> > directories, which is what we want. There is an existing exclusion
> > pattern that skips .o files during backup runs, and they didn't want
> > to create specialized rules for different projects. Hence the request
> > for the oddly named directory to make it match the existing pattern.
> >
> > We also have a symlink without the ".o" extension (workspace ->
> > workspace.o) which is commonly used to access the work space, but
> > symlinks frequently get expanded when scripts run. In the end, the
> > xfsprogs build system saw the full path without the symlink
> > (".../workspace.o/.../xfsprogs-5.8.0/...") and started substituting
> > workspace.o with workspace.lo. And then the build died.
>
> haha, no comment on the strategy ;)
You won't hear an argument from me. *LOL* I had a sneaking suspicion
that the "workspace.o" strategy might trigger some fallout. Turns out
I wasn't wrong.
> But I agree that we should not be substituting anything but the root filename
> suffix, so the patch is fine by me.
Thanks,
-Markus
> -Eric
