[MacPorts] SummerOfCode modified

MacPorts noreply at macports.org
Tue Sep 29 05:03:43 PDT 2009


Changed page "SummerOfCode" by ryandesign at macports.org from 70.113.104.73*
Page URL: <http://trac.macports.org/wiki/SummerOfCode>
Diff URL: <http://trac.macports.org/wiki/SummerOfCode?action=diff&version=119>
Revision 119
Comment: typo

-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: SummerOfCode
=========================================================================
--- SummerOfCode (version: 118)
+++ SummerOfCode (version: 119)
@@ -66,7 +66,7 @@
 
 ==== Logging ==== #logging
 
-Currently MacPorts has no notion of logging of build activities of a given port or sets of ports. When a a build is attempted but an error keeps it from completing, there's no way to track the problem other than the build progress that was output to the terminal, if verbose mode was requested in the first place. Otherwise, the build environment has to be pruned and the build attempted once again to even get a look at the precise error message. This is particularly problematic when automated builds are attempted, since there's usually no one around to have a look at the failure spew. An infrastructure to remedy this situation and endow MacPorts with a rich set of logging capabilities has to be developed to open up the door to true automated build runs of large sets of ports and thus to packaging of binaries, since with logging we'd have a fully reliable way of catching, reporting and processing of all sorts of fetch/configure/build/destroot/install/etc errors.
+Currently MacPorts has no notion of logging of build activities of a given port or sets of ports. When a build is attempted but an error keeps it from completing, there's no way to track the problem other than the build progress that was output to the terminal, if verbose mode was requested in the first place. Otherwise, the build environment has to be pruned and the build attempted once again to even get a look at the precise error message. This is particularly problematic when automated builds are attempted, since there's usually no one around to have a look at the failure spew. An infrastructure to remedy this situation and endow MacPorts with a rich set of logging capabilities has to be developed to open up the door to true automated build runs of large sets of ports and thus to packaging of binaries, since with logging we'd have a fully reliable way of catching, reporting and processing of all sorts of fetch/configure/build/destroot/install/etc errors.
 
 This could be extended with the interaction with a server side application like MPWA that could consume these logs (read MPWA proposal). A more detailed draft of this task can be found on the LoggingProposal page.
 

-------8<------8<------8<------8<------8<------8<------8<------8<--------

* The IP shown here might not mean anything if the user or the server is
behind a proxy.

--
MacPorts <http://www.macports.org/>
Ports system for Mac OS

This is an automated message. Someone at http://www.macports.org/ added your email
address to be notified of changes on SummerOfCode. If it was not you, please
report to .


More information about the macports-changes mailing list