View previous topic :: View next topic |
Author |
Message |
EzInKy Veteran
Joined: 11 Oct 2002 Posts: 1742 Location: Kentucky
|
Posted: Tue Dec 10, 2002 6:37 am Post subject: Can Portage Avoid Overwriting Object Files? |
|
|
Code: |
#man emerge
emerge normally cleans out the package-specific temporary
build directory before it starts the building a package.
|
Is there a switch to turn this off temporarily? I was thinking about it when trying to get OO to compile and all the previously successfully built object files got overwritten. |
|
Back to top |
|
|
dreamer3 Guru
Joined: 24 Sep 2002 Posts: 553
|
Posted: Tue Dec 10, 2002 7:34 am Post subject: Re: Can Portage Avoid Overwriting Object Files? |
|
|
EzInKy wrote: | Code: | emerge normally cleans out the package-specific temporary
build directory before it starts the building a package.
|
Is there a switch to turn this off temporarily? I was thinking about it when trying to get OO to compile and all the previously successfully built object files got overwritten. |
I don't think turning it off would have the result you are hoping for. OO would still compile EVERYTHING... it wouldn't automatically skip to where it left off... if only...
You might want to check out ccache (there is a package in portage) and search for it on the forums. It caches compiled files so that if you try to compile them again with the same options you won't need to... so you sort of start where you left off... (what I think you're wanting) |
|
Back to top |
|
|
EzInKy Veteran
Joined: 11 Oct 2002 Posts: 1742 Location: Kentucky
|
Posted: Tue Dec 10, 2002 8:00 am Post subject: |
|
|
Quote: | You might want to check out ccache (there is a package in portage) and search for it on the forums. It caches compiled files so that if you try to compile them again with the same options you won't need to... so you sort of start where you left off... (what I think you're wanting) |
Thanks for the input!
I was thinking along the lines of letting make do it's job of only compiling files that have been affected by a change or not been compiled yet. I'll look into ccache again (read a little about it before), but with OO iftself needing a couple of gigs for just it's files I'm not sure the additional space of a cache would be a good solution for many people. I've got a 40gb drive dedicated to Gentoo, but there are probably those who are using somewhat less. |
|
Back to top |
|
|
dreamer3 Guru
Joined: 24 Sep 2002 Posts: 553
|
Posted: Tue Dec 10, 2002 8:04 am Post subject: |
|
|
EzInKy wrote: | I was thinking along the lines of letting make do it's job of only compiling files that have been affected by a change or not been compiled yet. I'll look into ccache again (read a little about it before), but with OO iftself needing a couple of gigs for just it's files I'm not sure the additional space of a cache would be a good solution for many people. I've got a 40gb drive dedicated to Gentoo, but there are probably those who are using somewhat less. |
Hmmm, does make do that sort of thing? Pick up where it left off like? I wasn't aware of that... I didn't say ccache was for everyone... but I've had great luck since I installed it a few weeks ago... nothing borked yet and recompiling from CVS is faster since a lot of files stay the same... |
|
Back to top |
|
|
fuxored n00b
Joined: 29 May 2002 Posts: 71
|
Posted: Tue Dec 10, 2002 8:28 am Post subject: |
|
|
Yes make works off rules and targets. If a rule says it needs say, foo.o, to link with, make will look for a rule to make that object. If that object already exists, and none of the files that it made of are newer than the binary(?), it won't rebuild it.
That might not be 100% accurate, I'm just learning all the auto stuff my self. It should be at least on the right track though. |
|
Back to top |
|
|
rac Bodhisattva
Joined: 30 May 2002 Posts: 6553 Location: Japanifornia
|
Posted: Tue Dec 10, 2002 8:41 am Post subject: |
|
|
Vote of confidence for fuxored's post. _________________ For every higher wall, there is a taller ladder |
|
Back to top |
|
|
dreamer3 Guru
Joined: 24 Sep 2002 Posts: 553
|
Posted: Tue Dec 10, 2002 8:43 am Post subject: |
|
|
rac wrote: | Vote of confidence for fuxored's post. |
So what EzInKy was originally after could be a good thing for LARGE ebuilds that fail in the middle somwhere? |
|
Back to top |
|
|
rac Bodhisattva
Joined: 30 May 2002 Posts: 6553 Location: Japanifornia
|
Posted: Tue Dec 10, 2002 8:55 am Post subject: |
|
|
dreamer3 wrote: | So what EzInKy was originally after could be a good thing for LARGE ebuilds that fail in the middle somwhere? | It's hard to say. It sounds like EzInKy was having trouble with the OO compile breaking off in the middle. Under normal circumstances, that isn't supposed to happen. That's a bug. It's hard for me to justify pushing a new feature into Portage that is of use only for buggy ebuilds. Now there may be a case that you are trying to reuse object files from a previous build. ccache seems to be the solution that the Portage developers have chosen for this. It would be challenging to deal with the complications that might arise from having stale object files around, so the decision to wipe the build directories might make troubleshooting easier, by eliminating some sources of variation. _________________ For every higher wall, there is a taller ladder |
|
Back to top |
|
|
dreamer3 Guru
Joined: 24 Sep 2002 Posts: 553
|
Posted: Tue Dec 10, 2002 9:00 am Post subject: |
|
|
rac wrote: | It's hard to say. It sounds like EzInKy was having trouble with the OO compile breaking off in the middle. Under normal circumstances, that isn't supposed to happen. That's a bug. It's hard for me to justify pushing a new feature into Portage that is of use only for buggy ebuilds. |
Infallible logic, as always. I will let the issue rest in my mind no longer and continue to be content with ccache... |
|
Back to top |
|
|
EzInKy Veteran
Joined: 11 Oct 2002 Posts: 1742 Location: Kentucky
|
Posted: Wed Dec 11, 2002 9:44 am Post subject: |
|
|
<quote>It's hard to say. It sounds like EzInKy was having trouble with the OO compile breaking off in the middle. Under normal circumstances, that isn't supposed to happen. That's a bug. It's hard for me to justify pushing a new feature into Portage that is of use only for buggy ebuilds.</quote>
Bugs happen...that is part of using any software. What makes using source so fantistic is it puts the power in the users hand to fix problems when they occur, and even report back to developers what they did to fix the problem. Would it really be that hard to code something like:
Code: |
if (IF_DONT_ERASE_BUILD_DIRECTORY_FLAG_SET)
Portage.DontEraseBuildDirectory();
|
|
|
Back to top |
|
|
rac Bodhisattva
Joined: 30 May 2002 Posts: 6553 Location: Japanifornia
|
Posted: Wed Dec 11, 2002 10:07 am Post subject: |
|
|
Are you changing USE variables or CFLAGS or something? If so, then the object files should be wiped out. If not, then you could always try this: Code: | # cd /var/tmp/portage/<build-directory>
hack hack hack
# make
repeat previous two lines as necessary
# ebuild /path/to/ebuild install
# ebuild /path/to/ebuild qmerge |
_________________ For every higher wall, there is a taller ladder |
|
Back to top |
|
|
dreamer3 Guru
Joined: 24 Sep 2002 Posts: 553
|
Posted: Wed Dec 11, 2002 10:23 am Post subject: |
|
|
rac wrote: | hack hack hack |
Code: | jgoebel@integrity jgoebel $ hack hack hack
-bash: hack: command not found |
not working here |
|
Back to top |
|
|
EzInKy Veteran
Joined: 11 Oct 2002 Posts: 1742 Location: Kentucky
|
Posted: Wed Dec 11, 2002 9:47 pm Post subject: |
|
|
Code:
jgoebel@integrity jgoebel $ hack hack hack
-bash: hack: command not found
Quote: | not working here |
|
|
Back to top |
|
|
|