Gentoo Archives: gentoo-dev

From: Mike Frysinger <vapier@g.o>
To: gentoo-dev@l.g.o
Cc: Donnie Berkholz <dberkholz@g.o>
Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild
Date: Thu, 27 Sep 2007 06:50:53
Message-Id: 200709270237.42552.vapier@gentoo.org
In Reply to: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild by Donnie Berkholz
1 On Wednesday 26 September 2007, Donnie Berkholz wrote:
2 > On 17:53 Wed 26 Sep , Doug Goldstein wrote:
3 > > Mike Frysinger wrote:
4 > > > Donnie Berkholz wrote:
5 > > > also, ebuilds do change over time, so what line # may be correct one
6 > > > day may not be relevant the next ...
7 > >
8 > > True. I will concede this point. I could attempt to argue this is why
9 > > it's important to know the version and revision of the package you are
10 > > emerging. But the counter point is evident, times when the ebuild is
11 > > changed without a bump pose a problem.
12 > >
13 > > Which could bring up a point of would it be useful to see if we can
14 > > print out the actual line that caused the die. Now, I don't know if this
15 > > feasible or something the Portage devs want to do. But again, in the
16 > > effort to streamline this might be something to consider.
17 >
18 > The backtrace code is in ebuild.sh:dump_trace(). If you can find a way
19 > in bash to print the source line, that would be great. I took another
20 > glance through the bash man page and didn't see much from that end. But
21 > since we do have the source file and line number, we could just grab it
22 > with some hack like:
23 >
24 > sed -ne "${lineno}p" ${filename}
25 >
26 > Anyone got something better?
27
28 how about this:
29 + eerror "The specific snippet of code:"
30 + # This scans the file that called die and prints out the logic that
31 + # ended in the call to die. This really only handles lines that end
32 + # with '|| die' and any preceding lines with line continuations (\).
33 + # This tends to be the most common usage though, so let's do it.
34 + # Due to the usage of appending to the hold space (even when empty),
35 + # we always end up with the first line being a blank (thus the 2nd sed).
36 + sed -n \
37 + -e "# When we get to the line that failed, append it to the
38 + # hold space, move the hold space to the pattern space,
39 + # then print out the pattern space and quit immediately
40 + ${BASH_LINENO[0]}{H;g;p;q}" \
41 + -e '# If this line ends with a line continuation, append it
42 + # to the hold space
43 + /\\$/H' \
44 + -e '# If this line does not end with a line continuation,
45 + # erase the line and set the hold buffer to it (thus
46 + # erasing the hold buffer in the process)
47 + /[^\]$/{s:^.*$::;h}' \
48 + ${BASH_SOURCE[1]} \
49 + | sed -e '1d' \
50 + | (OFS=${IFS} IFS=$'\n'; while read -r n ; do (IFS=${OFS}; eerror "
51 ${n}") ; done)
52 -mike

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies