> So that could possibly be used for the build and destroot phases. For the > build phase, some trickery would have to be used when parallel building to > match things up.
On the scale of things I'm not sure there'd be a significant difference. If there may then the extent of the trickery would be looking at what percentage of the items remain to be completed (remove from list as done?). Then you can just do count on the vector or array. > I wonder how long a dry run would take for a very large program, like qt4-mac. I'll actually run this for you this evening. > These methods would only work for ports that build using a Makefile. Granted > that's most of them, but it's not all of them. > > How would we handle the configure phase? There's a lot of variation there. > Some use autoconf-generated configure scripts, some use homegrown ones, some > use cmake, some kick off long builds in the configure phase (like cmake > itself)... There's always going to be exceptions. I would just disable this progress bar where needed, and perhaps print out a little warning about not knowing how to track this phase. If we want to avoid disabling the progress bar then we could have the maintainers actually set markers, where if "x" is encountered in the output put the progress bar at a specific percentage. This allows us be correct where possible, and degrade where needed.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
