On Mon, Jan 13, 2025 at 02:45:28PM +0100, Arsen Arsenović wrote:
> > So the former d/.deps/file.Po which handled both d/dmd/common/file.d and
> > d/dmd/root/file.d in your case would be d/.deps/d-common-file.o.d and
> > d/.deps/d-root-file.o.d while with the above DEPFILE it would be
> > d/.deps/common-file.d and d/.deps/root-file.d
> > There are no d/dmd/*-*.d files and among d/*-*.cc the only are just d-
> > prefixed ones, and there are no clashes between the *.cc and *.d filenames:
> > for i in gcc/d/*.cc; do j=`basename $i .cc`; find gcc/d -name $j.d; done
>
> Relying that is more error-prone, I think. While that is true today, it
> might not stay true forever, and such a change won't be caught until it
> fails again in the same way.
>
> $@ is necessarily unique (however, still, with the proposed approach
> d/foo.o and d-foo.o will collide).
We are talking about d/*.o object files and d/.deps/*.Po files corresponding
to that. As there are no subdirectories, the * must be necessarily unique.
And it already uses $(@D) in the directory name ($(@D)/$(DEPDIR) in
particular, so even if in the future some subdirectory for object files is
added, it would still be unique, say if there is
d/*.o and d/whatever/*.o, the deps files would be d/.deps/*.Po and
d/whatever/.deps/*.Po. There is no need to avoid clashes with files in
the gcc main build directory, those have their own gcc/.deps/ rather than
gcc/d/.deps/
> I might be overthinking it - I trust your judgment, so I'm okay with
> either.
Jakub
