destroot and (build && destroot) yield different results
A few days ago, I submitted a ticket outlining situations in which it takes two runs of the port command for correct installation (http://trac.macosforge.org/projects/macports/ticket/14687 ). Is this a known behavior? I have attempted to track down the problem myself, but it has been slow going as I am not well versed in either Tcl or the MacPorts code base. Can anyone offer suggestions as to which parts of the MacPorts code to look at to determine why "port destroot" and "port build && port destroot" might have different results? Thank you, Marcus
Marcus Calhoun-Lopez wrote:
A few days ago, I submitted a ticket outlining situations in which it takes two runs of the port command for correct installation (http://trac.macosforge.org/projects/macports/ticket/14687 ).
Is this a known behavior?
Don't think so...
I have attempted to track down the problem myself, but it has been slow going as I am not well versed in either Tcl or the MacPorts code base.
Could you try to provide a minimal test Portfile which can be used to track this down? I don't want to test with mzscheme or boost. For example something like this should do (untested): build.env FOO='bar' destroot.env FOO='qux' build { system {echo "build: $FOO"} } destroot { system {echo "destroot: $FOO"} }
Can anyone offer suggestions as to which parts of the MacPorts code to look at to determine why "port destroot" and "port build && port destroot" might have different results?
Seems to be some problem with exporting build.env? Rainer
Rainer Müller wrote:
Could you try to provide a minimal test Portfile which can be used to track this down? I don't want to test with mzscheme or boost.
It is difficult to construct a small Portfile for this problem. MacPorts runs make, and make calls another program (jam for boost and a variant of mzscheme for mzscheme). It is in these secondary programs that the problem occurs. At the point of error in the boost code, the author has included the comment "# VP: I have no idea now 'native' can be empty here! But it can!" This is not an encouraging comment, but I shall continue to try to track down the problem. -Marcus
participants (2)
-
Marcus Calhoun-Lopez
-
Rainer Müller