redo destroot after tweaking build?

[Ryan Schmidt]

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

> On Aug 04, 2014, at 11:28, Ryan Schmidt wrote:
> 
>> 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.
> 
> It is, more than just slightly in fact. Without -o it takes about the same time to decide ... and then starts from scratch. O:-)
> 
>> 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.
> 
> Eh? Then why is it that `port activate -f` that I have to use sometimes to override files already present works?

As far as I know, that does not work, and it behaves as I described. Single-letter flags, which are preceded by a single "-", are "global" and must appear immediately after the "port" command name. Longer flags, which are preceded by "--", are local to the specific command and must appear after that command (e.g. "sudo port upgrade --enforce-variants"). I think this is distinction and pickiness is unexpected and undesirable and we should change it (c.f. the "svn" command, which accepts most arguments in any order) but as far as I know we haven't changed it yet.


>> 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"?
> 
> I suppose the same thing as would happen without rewinding. I.e. nothing. I meant rewinding 1 level above the current level, not above the requested level:

Right. So hypothetical situation where destroot has already been completed and recorded in the state file:

sudo port -f extract --> rewinds state to end of build phase; does nothing else
sudo port -f extract --> rewinds state to end of configure phase; does nothing else
sudo port -f extract --> rewinds state to end of patch phase; does nothing else
sudo port -f extract --> rewinds state to end of extract phase; does nothing else
sudo port -f extract --> extracts again, possibly encountering errors due to already existing files

I would consider this behavior confusing.

Phases cannot necessarily be repeated without undesired side effects occurring; this would vary by port. Imagine a destroot phase that copies a directory. The behavior of the unix "cp" command, and the tcl "file copy" command and its MacPorts alias "copy", is that if a directory does not exist, the directory is copied there; if the directory already exists, the directory is copied into it, unless an item of that name already exists in it. So a destroot that does:

file mkdir ${destroot}${prefix}/share/doc
copy ${worksrcdir}/doc ${destroot}${prefix}/share/doc/${subport}

(which is a pretty common pattern) will, the first time it's run, copy ${worksrcdir}/doc to ${destroot}${prefix}/share/doc/${subport}, and the second time it's run, will copy ${worksrcdir}/doc to ${destroot}${prefix}/share/doc/${subport}/${subport}, and the third time it's run, will issue an error that ${destroot}${prefix}/share/doc/${subport}/${subport} already exists. These kinds of errors resulting from unexpectedly repeating phases are why it's so important for users to clean and try again before reporting problems to us (as it says to do first thing on the ticket filing instructions), and why I'm ok with not modifying MacPorts base to make it easier to repeat phases.