redo destroot after tweaking build?

[Ryan Schmidt]

On Aug 4, 2014, at 3:28 AM, René J.V. Bertin wrote:

> On Sunday August 03 2014 21:11:08 Ryan Schmidt wrote:
> 
>> If the destroot phase was not successfully completed, removing the destroot directory is all you need to do before trying again. If you've edited the portfile between attempts, but don't want the work directory to be automatically deleted, use the "-o" flag to keep it even though it is now older than the portfile (e.g. "sudo port -o destroot").
> 
> Well, using -o mostly has the effect (for me at least) that the port command spends a considerable time to decide to do ... nothing :-/

Normally, if a state file exists, MacPorts compares the checksum of the portfile with the checksum previously stored in the state file, and if they don't match, it cleans the work directory first. "-o" means don't do that, so if anything it should be very slightly faster.


>> If the destroot phase was completed successfully but you want to do it again anyway, in addition to removing the destroot directory, edit the statefile (the file named ".macports.${subport}.state" in the port's work directory) and remove the last line, referencing the destroot phase.
> 
> Ahhh, now we're in business. /meStupid for not looking for hidden files in said directory ... I feared state was saved in some (now huge, around 115Mb) binary database).
> 
> In a sense, I think that `port destroot -f`, `port build -f` (etc.) should rewind the state 1 level because right now -f has only limited scope ...

Remember that single-letter flags like "-f" must go immediately after the word "port" (e.g. "sudo port -f destroot", "sudo port -f build") and have no effect if placed elsewhere on the command line.

Rewinding 1 level seems to be an odd behavior to add. What if, for example, you had already completed the destroot, and then ran "sudo port -f extract"?