Re: CVS commit: src/usr.bin/make

[christos%astron.com@localhost (Christos Zoulas)]

In article <d52d558e-a039-40c3-b910-ab0aeed7fc1b%gmx.de@localhost>,
Roland Illig  <roland.illig%gmx.de@localhost> wrote:
>Am 18.11.2024 um 17:29 schrieb Christos Zoulas:
>> In article <20241110023915.09CD6F971%cvs.NetBSD.org@localhost>,
>> Simon J. Gerraty <source-changes-d%NetBSD.org@localhost> wrote:
>>> -=-=-=-=-=-
>>>
>>> Module Name:	src
>>> Committed By:	sjg
>>> Date:		Sun Nov 10 02:39:14 UTC 2024
>>>
>>> Modified Files:
>>> 	src/usr.bin/make: main.c make.1
>>>
>>> Log Message:
>>> make: allow -f .../Makefile
>>>
>>> If the arg to -f or an entry in .MAKE.MAKEFILE_PREFERENCE
>>> starts with ".../" look for the rest of the path in .CURDIR
>>> and above.
>>>
>>> Reviewed by: rillig
>>
>> I don't like these magical conventions that do not match filesystem
>> behavior. For example what happens if there actually is a "..." directory?
>> I can certainly make one... Why don't use a keyword instead to indicate
>> the operation?
>
>It's analogous to the existing '-m .../mk/sys.mk' option, therefore I
>don't see a big drawback.
>
>As you noted, a directory named '...' would interfere with this pattern.
>If the option had been '-f scan:custom.mk' instead, a file named
>'scan:custom.mk' would interfere in the same way. So I guess whatever
>the pattern, it will not be completely conflict-free.

Yes, but it could be something like search(.., custom.mk)

christos