Re: [ccache] [PATCH] Potentially produce better relative pathnames when symlinks are
On 2011-03-14 12:03, Mike Crowe wrote: > > Well, that certainly is a problem that I would also like to resolve > > but you are correct in saying that the patch does not address it. I > > ended up deciding that the only way to solve it would be to invent > > CCACHE_BASEDIRS to support multiple base directories. I have a patch > > in development that does this. On Sun, Mar 20, 2011 at 09:23:17PM +0100, Joel Rosdahl wrote: > Right. I think that we in that case just should allow multiple > directories separated by colon in the existing CCACHE_BASEDIR variable. I shall do that instead then. > > Yes, this is the use case that is addressed by the patch. The reason > > it is a problem for me is that we share a ccache among multiple users > > and the rewritten path ends up being unique for each user (without the > > patch.) > > > > I'm open to suggestions if you think there is a better way to fix > > either or both problems. > > I can't think of a better solution for the moment, but one thing you > could do is to check whether current_working_dir and > x_realpath(current_working_dir) are different (only needed once) and > only then try the second get_relative_path. Also, I would be very happy > if you have opportunity to make a test case for this in test.sh. :-) OK. It might take me a while to produce another patch but I shall endeavour to do all of this. Thanks. Mike. ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] [PATCH] Potentially produce better relative pathnames when symlinks are
On 2011-03-14 12:03, Mike Crowe wrote: > Well, that certainly is a problem that I would also like to resolve > but you are correct in saying that the patch does not address it. I > ended up deciding that the only way to solve it would be to invent > CCACHE_BASEDIRS to support multiple base directories. I have a patch > in development that does this. Right. I think that we in that case just should allow multiple directories separated by colon in the existing CCACHE_BASEDIR variable. > Yes, this is the use case that is addressed by the patch. The reason > it is a problem for me is that we share a ccache among multiple users > and the rewritten path ends up being unique for each user (without the > patch.) > > I'm open to suggestions if you think there is a better way to fix > either or both problems. I can't think of a better solution for the moment, but one thing you could do is to check whether current_working_dir and x_realpath(current_working_dir) are different (only needed once) and only then try the second get_relative_path. Also, I would be very happy if you have opportunity to make a test case for this in test.sh. :-) -- Joel ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] [PATCH] Potentially produce better relative pathnames when symlinks are
On 2011-02-28 13:30, Mike Crowe wrote: >> When making relative pathnames try and do so both before and after >> calling realpath and pick the version that is the shortest. This helps >> if the build starts from a path that contains a symlink and a Makefile >> somewhere decides to use realpath to generate absolute paths. On Sun, Mar 13, 2011 at 11:20:07PM +0100, Joel Rosdahl wrote: > First I thought that your use case is this: There's a file named > /dir1/src/file.c, /dir2 is a symlink to /dir1 and CCACHE_BASEDIR=/dir2. > The Makefile in /dir1/src runs "gcc -c $(realdir file.c) -o file.o", so > when invoked in /dir2/src, make will execute "gcc -c /dir1/src/file.c -o > file.o", and ccache will thus not detect that /dir1/src/file.c should be > rewritten since it doesn't match CCACHE_BASEDIR. Well, that certainly is a problem that I would also like to resolve but you are correct in saying that the patch does not address it. I ended up deciding that the only way to solve it would be to invent CCACHE_BASEDIRS to support multiple base directories. I have a patch in development that does this. > But your patch doesn't address that problem, so that's not the use case. > Let's try again. There's a file named /dir/1/src/file.c, /dir/2 is a > symlink to /dir/1 and CCACHE_BASEDIR=/dir. The Makefile in /dir/1/src > runs "gcc -c $(realdir file.c) -o file.o", so when invoked in > /dir/2/src, make will execute "gcc -c /dir/1/src/file.c -o file.o" and > ccache will rewrite /dir/1/src/file.c to ../../2/src/file.c. With your > patch, /dir/1/src/file.c will instead be rewritten to file.c, thus in a > sense normalizing the path so that there will be a cache hit if you > later build in /dir/1/src. Is that the use case? Yes, this is the use case that is addressed by the patch. The reason it is a problem for me is that we share a ccache among multiple users and the rewritten path ends up being unique for each user (without the patch.) I'm open to suggestions if you think there is a better way to fix either or both problems. Thanks. Mike. ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] [PATCH] Potentially produce better relative pathnames when symlinks are
On 2011-02-28 13:30, Mike Crowe wrote: > When making relative pathnames try and do so both before and after > calling realpath and pick the version that is the shortest. This helps > if the build starts from a path that contains a symlink and a Makefile > somewhere decides to use realpath to generate absolute paths. (Sorry for the delayed reply.) First I thought that your use case is this: There's a file named /dir1/src/file.c, /dir2 is a symlink to /dir1 and CCACHE_BASEDIR=/dir2. The Makefile in /dir1/src runs "gcc -c $(realdir file.c) -o file.o", so when invoked in /dir2/src, make will execute "gcc -c /dir1/src/file.c -o file.o", and ccache will thus not detect that /dir1/src/file.c should be rewritten since it doesn't match CCACHE_BASEDIR. But your patch doesn't address that problem, so that's not the use case. Let's try again. There's a file named /dir/1/src/file.c, /dir/2 is a symlink to /dir/1 and CCACHE_BASEDIR=/dir. The Makefile in /dir/1/src runs "gcc -c $(realdir file.c) -o file.o", so when invoked in /dir/2/src, make will execute "gcc -c /dir/1/src/file.c -o file.o" and ccache will rewrite /dir/1/src/file.c to ../../2/src/file.c. With your patch, /dir/1/src/file.c will instead be rewritten to file.c, thus in a sense normalizing the path so that there will be a cache hit if you later build in /dir/1/src. Is that the use case? -- Joel ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
