Hi, On Thu, Jul 28, 2016 at 03:21:56AM -0500, Ryan Schmidt wrote: > However, as I've said, there are other reasons why a port might not be > able to install. Should we really modify MacPorts base and create new > variables to accommodate each of those reasons? Is there a specific > objection to what I consider the easiest and most flexible of the > options I suggested: implement a new preflight phase, in which the > port can run any logic to determine if the port can be installed?
I have a specific objection: If this is a phase and does not use declarative syntax, you absolutely must open and run the code in the Portfile to determine whether a port will build on your OS. Opening a running Portfiles is (a) already where our dependency management spends most time, (b) hard to optimize in the absence of a interpreter-fork-like behavior in Tcl with our current approach, (c) completely breaks the idea of using SAT-solving for dependency resolution or any other modern method, because those methods depend on having accurrate information about *all* available ports (which would mean we'd have to run all ports). So in short: The phase cannot be put in the port index, which is a bad idea in my opinion. Declarative approaches like the platform statement can. On Thu, Jul 28, 2016 at 01:02:15PM +0200, Rainer Müller wrote: > On 2016-07-28 09:06, Artur Szostak wrote: > > macosx >= 10.9 > > macosx < 10.10 > > https://trac.macports.org/ticket/15712 I like this approach. Remember the brew uses a similar approach to blacklisting, which is basically platforms >= :lion (please excuse any butchering of Ruby syntax). This is very simple to get right, and I'd prefer a similar approach. Ryan: Which other cases can you think of? I think we can handle most of them with a similar approach. Why not have a field that contains identifiers which reference well-known tests for a feature? Here's an idea: > constraints java-1.0 uses _resources/port1.0/constraints/java-1.0.tcl to determine whether the constraint is fulfilled, but does this once for all ports, rather than once per port. Similarly, we could have > constraints {platform-1.0 >= lion} which could load _resources/port1.0/constraints/platform-1.0.tcl and run a proc from there with the ">=" "lion" arguments (again, without running the complete Portfile and loading all files in port1.0). That would also allow you to implement manual download checks: > constraints {manual-download-1.0 "${targetfile}" "${downloadurl}"} Whether that field is now called "platform" or "constraints" doesn't really matter. We could make them aliases. What do you think? -- Clemens _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
