Michael Banck wrote:
On Mon, May 11, 2009 at 03:17:33PM +0200, Giacomo A. Catenazzi wrote:
So I would like to have a short log (e.g. what I put in stdout/stderr,
with "./configure --quiet"), so that people will have no excuses for
not be carefukll, but also to have access to configure.log (or/and
other build time log), on build failure.
OK, so I am not sure what this has to do with the thread. Are you
proposing a completely different way of how autoconf packages should get
configured in debian/rules? What does ./configure --quiet have to do
with compiler warnings or deprecated features? Does it print out
relevant parts of config.log on failure? If not, what is the point of
"configure.log", having the same information then than one has now in
general?
Is it to much to ask?
You can ask anything, the question is whether it gets picked up. If
what you ask for required changes in most source packages, it is likely
that it will not get picked up.
What I do think might make sense is changing dh7 and/or CDBS to print
out config.log if configure fails; that might help debug problems on the
autobuilders more quickly.
Ok, I was not so clear. I was replying to:
>> Goswin von Brederlow wrote:
Debuild already creates a build log. I think it would be nice to
include that file in the changes file and have DAK forward it to
buildd.debian.org for archival.
Thus: my request was more about our infrastructure then the
building tools.
In my experience, the ./configure script are usually too verbose
(whose created with autoconf in particulary). Maintainer tends
not to parse carefully the output of such script, e.g. ask my
sponsorees ;-) , missing important parts.
So, if we centrally save the logs, I would like to allow maintainer to
run configure with --quiet, but also to save extra informations for
late processing.
It is not only build failures, but the log (on file, which is much more
verbose then normal output) contains also other useful informations:
e.g. the compiler and other tool versions, etc.
E.g. if we saw a bug (secutity or also miscompilation) in one package
in the toolchain, we can found what package need to be recompiled (and
in what architecture).
I think such logs are more useful to archive, than the simple stdout/stderr.
BTW I just discovered dh_buildinfo, which unfortunately has no manpage.
ciao
cate
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
