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
[ccache] Could ccache handle the input as .o file as well as source file.
Hi: I've been using ccache recently, in order to decline the compilation time for a certain module. In this module, with the help of the greatest ccache, the time could be shorten to 5 mins from 40 mins without any modification. However, even if the output of all the source files are cached, we have to take about the 5 mins mainly in the linking action, eg: a.o -> test_a(exetuable). Since I have noticed that ccache do not take the .o file as a input to be cached. The actions as linking would certainly not be ccached, and thus the time for linking would not significant reduced. Given this background, I have a few questions to talk about. Have anyone ever considered to build up a mapping between .o file and its output? If so, why ccache did not provide such feature. If not, do you think it is a reasonable feature for ccache to reduce the time for linking in a compilation? Thanks Sean ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Could ccache handle the input as .o file as well as source file.
On Mon, Mar 14, 2011 at 23:17, xiaoxiao wrote: > I've been using ccache recently, in order to decline the compilation > time for a certain module. In this module, with the help of the greatest > ccache, the time could be shorten to 5 mins from 40 mins without any > modification. However, even if the output of all the source files are > cached, we have to take about the 5 mins mainly in the linking action, > eg: a.o -> test_a(exetuable). Since I have noticed that ccache do not > take the .o file as a input to be cached. The actions as linking would > certainly not be ccached, and thus the time for linking would not > significant reduced. > Given this background, I have a few questions to talk about. Have anyone > ever considered to build up a mapping between .o file and its output? If > so, why ccache did not provide such feature. If not, do you think it is > a reasonable feature for ccache to reduce the time for linking in a > compilation? try switching to gold -mike ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Could ccache handle the input as .o file as well as source file.
于 2011/3/15 11:33, Mike Frysinger 写道: Sorry, but what do you mean? Sean On Mon, Mar 14, 2011 at 23:17, xiaoxiao wrote: I've been using ccache recently, in order to decline the compilation time for a certain module. In this module, with the help of the greatest ccache, the time could be shorten to 5 mins from 40 mins without any modification. However, even if the output of all the source files are cached, we have to take about the 5 mins mainly in the linking action, eg: a.o -> test_a(exetuable). Since I have noticed that ccache do not take the .o file as a input to be cached. The actions as linking would certainly not be ccached, and thus the time for linking would not significant reduced. Given this background, I have a few questions to talk about. Have anyone ever considered to build up a mapping between .o file and its output? If so, why ccache did not provide such feature. If not, do you think it is a reasonable feature for ccache to reduce the time for linking in a compilation? try switching to gold -mike ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Could ccache handle the input as .o file as well as source file.
On Mon, Mar 14, 2011 at 23:56, xiaoxiao wrote: > 于 2011/3/15 11:33, Mike Frysinger 写道: >> try switching to gold > > Sorry, but what do you mean? please dont top post get latest binutils and use `ld.gold` instead of just `ld`. there is also some gcc flag to control which one is invoked, but i forget what it is. -mike ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
