Hi Dmitry

On 8/21/22 05:52, Dmitry Goncharov wrote:
On Sat, Aug 20, 2022 at 8:28 PM Masahiro Yamada <masahi...@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/>

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to