> I notice it flagged the mldonkey build as failed, but in fact it was one of > mldonkey's dependencies which failed. Perhaps there is a way that could be > made more clear in the interface.
Yes, it did mark mldonkey as failure, but take it as what it really is: a change event picked up in the subversion, which triggers a build of the package in question. If that gives you an error exit code, it is marked as failure. This is obviously not necessarily the maintainer's fault. The whole thing is targeted to an developer audience to give instant feedback on changes, and should not be misunderstood as a tool for MacPorts users in the broader sense. That said, from the user's perspective, it might not make much of a difference, because if you where to install your package and it fails, it is the exact same experience and consistent with what Portmill shows for it. > Juan (jmpp) had always said that a prerequisite for a build/test system was > implementing the port logging proposal: > > http://trac.macports.org/wiki/LoggingProposal I would disagree. This build system does what you would otherwise do manually: build a certain port for test reasons and watch the debug output and end result. If the output gets improved, all the better. I don't see much of a connection necessarily. It might be interesting, though, if the logging would include some kind of event API, then a build server would see more information that exit code and brittle regexping of output, to which one otherwise would have to resort. That would e.g. make it much easier to do what you asked for above, i.e. figure out more about the reason of the build failure, the build phase, and maybe a distant dependency which is really the culprit. > And this is the project Dmitry (enl) has been approved to work on for this > year's Google Summer of Code: > > http://trac.macports.org/wiki/enl > > http://trac.macports.org/browser/branches/gsoc09-logging > > Have you coordinated with him? We don't want duplication of effort. Your > work is clearly logging something because the logs are appearing on your web > site. If this is not integrated with the MacPorts Tcl code, perhaps you can > assist Dmitry in doing so. If you and Dmitry finish the logging task early > I'm sure there are other tasks we can have him do for the rest of the > summer. I think it can only help to have better output, but no problems really. I didn't read the proposal though. Florian -- Florian Ebeling Twitter: febeling florian.ebel...@gmail.com _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
