>> This test result seems to show that it can make a significant difference >> if such a target was specified by a relative or absolute path. >> (I would expect that these specifications will refer to the same file.) > > Keep in mind that targets are opaque strings,
I would prefer a more convenient handling of build goals in some use cases. I noticed once more how relevant implicit make rules can become in this test case. > not references to files as such, and hence the exact path matters. The make software manages also a bit of extra background information. How interesting can it become to filter targets if they are phony (or not)? > E.g. "foo", "./foo", and "bar/../foo" are all different targets as far > as make is concerned, even if they all resolve to the same file on disk. Can the software situation be improved any more there? >> Do I need to extend the software build rules a bit more here? > > Yep, you need to fix your makefile if you want it to work with both > relative and absolute paths. I can adjust specific make scripts to some degree. Will it be better to avoid the duplication of corresponding build rules? > If you are doing complicated things, especially if you have > a modular build system with makefiles in different sub-directories > referring to the same files, you need to be careful how you use and > construct target paths so they are consistent. * Do you specify any extra explicit (non-pattern) make rules then? * How are the chances to reduce any inconveniences there? Regards, Markus _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
