Re: False positive "doesn't match the target pattern" error

[Alejandro Colomar]

Hi Dmitry

On 8/21/22 05:52, Dmitry Goncharov wrote:
> On Sat, Aug 20, 2022 at 8:28 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> > build-dirs := . drivers sound net virt arch/x86/pci arch/x86/power lib
> > arch/x86/lib
> > subdir-modorder := $(addsuffix /.modules.order, $(build-dirs))
> > $(sort $(subdir-modorder)): %/.modules.order: %
>
> Can you remove . from build-dirs and add a dedicated rule for .module.order?
> E.g.
> build-dirs := drivers sound net virt arch/x86/pci arch/x86/power lib
> arch/x86/lib
> subdir-modorder := $(addsuffix /.modules.order, $(build-dirs))
> $(sort $(subdir-modorder)): %/.modules.order: %; @:
> .modules.order:; @:
>
>
> > Make considers 'foo/bar' and 'foo/./bar'
> > as different targets.
>
> This is a deficiency in make. i opened
> https://savannah.gnu.org/bugs/index.php?62929 and attached a fix.
> Thanks for your report.

I'm not sure it's a bug/deficiency.  I use that as a feature (I'm don't 
even remember the bug that made me workaround it like that, but I'd like 
to check again; maybe I don't need such workaround really).

Anyway, it'll be a hard bug to fix:

Should make normalize . by just removing them?

Then, should it go further and collapse // ?

Then, should make go further and normalize ..?

But if so, should it go even further and resolve symlinks (.. is just a 
link to the parent directory)?

And if symlinks are in the way, how to deal with ..?  Logically, or 
physically?  See realpath(1).


Of course symlinks and physically resolving .. are out of the table, 
because since make(1) deals with possibly-non-existent pathnames, 
realpath(1) can't be used on them.  So, are we sure everyone is happy 
with make(1) resolving .. logically?  Clearly not, so .. can't be resolved.

Then, why should make(1) resolve . or // if it can't resolve .. or 
symlinks?  Let's be consistent and treat everything as text strings, and 
let users make sure they use the correct string.  And if that bug may be 
useful to workaround some weird situation by having two rules foo and 
foo/.,  let's call it a feature! =)

Cheers,

Alex

--
Alejandro Colomar
<http://www.alejandro-colomar.es/>

OpenPGP_signature
Description: OpenPGP digital signature