> On Jul 27, 2016, at 12:09 AM, Ryan Schmidt <ryandes...@macports.org> wrote: > > I would like MacPorts to be extended so that it can be determined in advance, > from the command line, before running "port install", whether a port can be > installed (barring unexpected build failures and bugs). Currently, MacPorts > assumes any port can be installed on any system, which is not the case. Many > ports cannot be built on certain versions of macOS. Some require libc++. Some > require dependencies to be installed with a nondefault variant. Some have > other requirements. Some ports, like p5-graveyard or other ports that serve > as placeholders designed to inform the user of the discontinuation of a port, > are designed to fail. Being able to determine in advance whether a port is > supposed to be installable will let us skip those ports when triggering > builds on the buildbot. This will cut down on unnecessary work performed by > the buildbot, and will avoid unnecessary emails sent to maintainers who > already know the port will fail in those circumstances. > > How can we accomplish this? We currently use "return -code error" to trigger > these kinds of error messages from ports, but we do so within a phase, such > as pre-configure or pre-fetch, but that means that code doesn't run until > those phases are running, and I want to know before those phases run, indeed > even before dependencies are calculated and installed. > > One solution that occurs to me is to define a new "preflight" phase, to be > run before dependencies are computed. Ports can override that phase and do > whatever checks they need and exit with "return -code error" if needed. This > seems like the most straightforward and flexible solution. > > Another possible solution could be to define a new Boolean variable > "installable" to indicate if the port is installable, which would default to > "yes". If a port sets this to "no", MacPorts could print a generic failure > message. There could be a second variable which the port developer could set > to a custom failure message. > > A third possibility could be to codify each of the reasons why a build might > fail, and introduce new variables for each reason. For example, a variable to > indicate the supported C++ libraries, or a variable to indicate the supported > macOS versions. There might be some advantage to this, in that it could be > used to programmatically answer questions like what C++ libraries or macOS > versions a port supports, but it is the least flexible and most complicated > solution.
Could I submit that there may be two issues being conflated? 1) Some ports are known to crap out on our buildbots. 2) It is known that some ports cannot be installed on particular system configurations. For 1), I think we should simply add a keyword to the portfile that tells the buildbot not to attempt to build this port. “mp_buildbot_skip” or some such. Add this to the p5-graveyard and all other ports that we know the buildbot cannot or should not attempt to build. For 2), we already have a series of tools that provide information about the environment and let the port do the right thing. I like the idea of a preflight phase—a number of ports ‘abuse’ the pre-fetch phase to essentially do this. However I’m not sure how prevalent or serious the problem is in 2) that we’re trying to solve. Craig (And there is the -y flag to ‘dry-run’ the installation.) _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
