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.
_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users
