failing configure => dump config.log in the log

[Rainer Müller]

On 2013-11-13 16:14, Ryan Schmidt wrote:
> We do have the problem that the config.log often holds the key to
> understanding a configure failure, and that users usually have to be
> asked to attach it, and be told how to locate it.
> 
> I worry that the config.log can be very large—and some ports like
> gettext have multiple configure scripts and thus multiple very large
> config.logs—and that including these in the main.log might make the
> main.log even more unwieldy.

Agreed, it's often already quite large.

> Instead of printing the config.logs’ contents we could just print
> their locations and advise users to attach them to tickets, but that
> would be more work for users and wouldn’t help when we need to see
> the config.logs from a buildbot.
> 
> If we decide to do this for autotools config.logs, there’s probably a
> similar file we could use for when cmake is used instead of
> autotools.

I remember that in the original plan for logging in the GSoC 2009
project by enl@, there should have been a separate log file for each
phase instead of one large monolithic log file. Mainly due to time
constraints and some other unsolved problems, it is now just a single
main.log, but with markers to identify which phase the message
originated from.

Splitting this up would have allowed to get a full log even if phases
are ran one after another. A problem that we still have today, we often
have to ask for the main.log of a clean build. But it had problems: what
if a phase failed first and then would be run again successfully? Should
we have multiple log files per phase? In the end it was simpler with a
single log file. Also, we wanted to have a format that would be suitable
to be attached to tickets.

Another idea was to eventually have a working MPWA which would accept
bug reports from a simple port command for automatic submission and
server-side aggregation of error reports, but that never happened.

The latter mechanism would also have included config.log files. As a
starting point, the copy_log_files option already exists and if set, the
specified files are copied into the ${prefix}/var/macports/logs/...
directory.

So much for the history... let's talk about what we can do about it.

If a build fails, we should just automatically copy any config.log or
the equivalent for cmake to the logs directory. Maybe we could even
expose that with the buildbot in some way as a separate file. Would it
only be helpful in case of a configure failure or should we always
advice to attach this to a ticket?

We could also create a compressed tarball of all these files for easy
submission by the reporter. However, reading such logs would be more
complicated as you would need to unpack the tarball first (although you
already have to download it now if it is too large for Trac's inline
view). For log files attached to a ticket, this could be eased by some
tools like the trac-get/trac-patch [1] shell functions I use. Maybe
finally create a port-trac tool in contrib that would handle that among
other often used tasks? Maybe make 'port log' handle this itself?

Rainer

[1]
http://trac.macports.org/wiki/CommittersTipsAndTricks#ApplypatchesdirectlyfromTracURL