On Wed, 2020-08-12 at 15:05 -0500, Segher Boessenkool wrote: > > As usual I've built my own version of GCC, and then I check it into > > Git so that all builds can use this one canonical compiler > > regardless of operating system, etc. > > There's your problem. Git is not an archiver. Git does not track > directories at all, including empty directories. Git is a "stupid > content tracker", and empty directories are contentless ;-)
Yes, I'm aware of Git's shortcomings in this area but... the advantages of using it over other alternatives are simply too great to overcome, at least in my environment. It provides branching (which I need, since older versions of our software need to build with older versions of these tools), it allows for tracking of changes, reversion, it provides a single interface across all platforms including multiple GNU/Linux distributions, Windows, and MacOS (and possibly others in the future), without users having to learn new tools. And it's available both online and offline for developers working remotely, which is critical. Yes, it's not as efficient as it could be for binary files, and it has this "issue" with empty directories (which is not really a big deal, most of the time). But it supports symbolic links, tracks executable permissions, handles moved files and created/deleted directories, etc. Also, an installation of a package like GCC has some binary files, yes, but it also has a LOT of text files. Combined with worktrees so we can share the same repo across different builds on the same system, to reduce the overhead of cloning, it works very well for the most part. At some point this may become too unwieldy and I'll have to look more carefully into git-lfs or similar. But that day has not arrived. > > Of course, I can force the lib directory to exist by adding a dummy > > file there and I will do so. However, it seems to me that it would > > be better if GCC would apply a simplifying function to pathnames to > > reduce all the "/.." elements, before it starts looking for > > directories, to avoid failing if some unnecessary element doesn't > > exist. > > It would be nice if this could be done (where possible -- see Jakub's > reply) before install already, so people looking at your install do > not have to look at ../../../../.. and remove five path components by > hand. There shouldn't be a problem doing it at file open time as you > say (unless we wand to support users putting .. in the paths > themselves, instead of just our make system doing that :-) ) I confess I didn't really follow all of that :) I'll file a bug tonight/tomorrow, then possible solutions can be discussed there.
