I would like to see an option switch added to emerge that keeps it from nuking an existing work directory. The reason I would like this is so I can take advantage of gcc's profile-arcs feature. This would allow gentoo users to get better compiler optimization of their executables and therefore have faster execution of their programs. When a program exits and it was compiled with profile arcs, it leaves a file in the directory where the source files were that it was built from. This file contains data on on the number of times a branch was or was not taken and maybe other data. Gcc then can take this data and optimize the program better when it is compiled again. Reproducible: Always
You can probably use /etc/portage/bashrc to accomplish what you need. There are 2 different ways to trigger code at a specific phase: 1) Make the code conditional on the ${EBUILD_PHASE} variable if [ "${EBUILD_PHASE}" == install ] ; then # do something with ${WORKDIR} before it's removed fi 2) Define a pre_ or post_ phase hooks such as post_src_compile() post_src_compile() { # do something with ${WORKDIR} before it's removed }
Will a bashrc hook as suggested in comment #1 suit your needs? I think we should provide some documentation/examples on bashrc since users are often unaware of what can be done with it.
(In reply to comment #2) > I think we should provide some documentation/examples on bashrc since users are often unaware of what can be done with it. ++ I was told off ont the forums for not realising that USE cannot be changed so it would be great to see a simple doc with some example code snippets and caveats.
A bash hook would suit my needs, but it might be nice to have something more straight forward. We have an option to keep the work done after an emerge. It seems like it would make sense to have an option to leave whats there alone. As for as documenting and examples of an existing work around thats always a good thing.
(In reply to comment #4) > We have an option to keep the work done after an emerge. It > seems like it would make sense to have an option to leave whats there alone. There is FEATURES=keepwork, but leaving that enabled can cause problems (see bug #177763). The reason that I suggested a hook is that you probably want to get whatever you need out of the build directory immediately since that's portage's build space and you don't want interference between yourself and portage.
(In reply to comment #5) > > There is FEATURES=keepwork, but leaving that enabled can cause problems (see > bug #177763). The reason that I suggested a hook is that you probably want to > get whatever you need out of the build directory immediately since that's > portage's build space and you don't want interference between yourself and > portage. > I'm not certain you understand how profile arcs works. Profile arcs stores the profile data in the same directory the source for the executable is created from. The data is created when the executable exits not after the compiling is done. If the directory structure is not there the executable creates it first. If it is made using emerge its going to put the profile data where the emerge command put the source like it or not. To utilize the profile arc data gcc needs it at compile time in the same directory that the source files reside. I would need some way to first read the profile arcs data out of the source directory, then let portage clobber it, then put the profile data back, and finally allow portage to resume the build process. It seems like it would just be easier to give the emerge command a switch to not nuke the directory first.
(In reply to comment #6) > Profile arcs stores the profile data in the same directory the source for the > executable is created from. The data is created when the executable exits not > after the compiling is done. So you just some way to prevent those files from being removed at the beginning of a build but you want everything removed at the end of a build? Maybe you'd be interested in integrating this together with FEATURES=installsources, so that the profile data will be stored in /usr/src/debug/ instead of the original build directory?
Like FEATURES=keepwork, this option to prevent the pre-cleaning is something that most people should probably not be using. Perhaps we should have separate clean_pre and clean_post phases and provide some way for you to override them.
I'm pondering various ways that we can expose this type of feature to users. For now, you can probably use something like this in /etc/portage/bashrc: [ "${EBUILD_PHASE}" == "clean" ] && \ ! [ -f "${PORTAGE_BUILDDIR}/.compiled" ] && exit 0 That will cause the clean phase will execute only if it detects that the compile phase has been run since the last cleaning.
(In reply to comment #7) > (In reply to comment #6) > > So you just some way to prevent those files from being removed at the beginning Yes > of a build but you want everything removed at the end of a build? What ever happens to the stuff at the end of a build is of no concern. > > Maybe you'd be interested in integrating this together with > FEATURES=installsources, so that the profile data will be stored in > /usr/src/debug/ instead of the original build directory? > The profile data will be generated and placed wherever the source was compiled from. It also must be used from that location. So moving its location isn't going to work.
If the bashrc way works I think we can close this. As for a more straightforward way to use that particular gcc feature, I don't think the approach of keeping $WORKDIR is really viable, that location is IMO way too fragile for such stuff. A better way would be IMO to teach gcc to store that information in a location of our choice, but that's beyond our area of expertise.
