[prev in list] [next in list] [prev in thread] [next in thread]
List: crux
Subject: Re: Errors during Compilation
From: Andrew Green <andrew.green () securetrendz ! com>
Date: 2002-06-17 0:12:26
[Download RAW message or body]
Markus Ackermann wrote:
>On Sun 16.06.2002, 12:49:59 -0600, Andrew Green said in public:
>
>
>>build() {
>> ./configure || return 1
>> make || return 1
>>}
>>
>>
>
>It's quite ugly. And the 'return 1' is only evaluated if the first
>statements exits with a non-zero return code, so the extra return 1
>statement is redundant anyway.
>
>
Not quite true. It's not _that_ ugly. :-) (but it is a little ugly)
Also, build() will continue even if *ANYTHING* inside fails, until it
reaches the end of the function. As it is, I don't think there are any
return codes making it back into the main pkgmk script. That's why
you'll run a pkgmk and end up with an empty package after all the errors
are done scrolling off your screen.
>>It doesn't really yield much info, but perhaps if Per extended the pkgmk
>>spec to evalute the return code it could be more powerful.
>>
>>
>>'configure' failures return 1: "Pkgmk failed during ./configure."
>>(./configure || return 1)
>>
>>
>[etc...]
>
>This is pretty impossible and would make pkgmk ugly as hell. The point about
>the build() function is that it can be run just as is. With your suggestion
>the entire function must be parsed first, extended to include the messages
>and control structure, and finally run. This would easily break if someone
>uses a for loop over several lines for example. GNU make offers all we'd
>ever want here, no need for Per to write his own f*cking complicated
>Make^H^H^H^HPkgfile parser.
>
>
You totally misunderstood my idea. Here is a script with a fake Pkgfile
that executes _exactly_ what I'm talking about.
# cat Pkgfile
build()
{
ls -l testfile* 2> /dev/null || return 1
cat testfile2 2> /dev/null || return 2
chmod +r testfile3 2>/dev/null || return 3
chmod -r testfile4 2>/dev/null || return 4
}
# cat mypkgmk
#!/bin/sh
. Pkgfile
build
RET=$?
if [ $RET -ne 0 ]
then
case $RET in
1) echo "First not found: $RET"; touch testfile;;
2) echo "Second not found: $RET"; cp testfile testfile2;;
3) echo "Third file not found: $RET"; cp testfile2
testfile3;;
*) echo "Fourth file not found: $RET"; rm testfile*;;
esac
fi
Run this script four times and it'll give you a different return result
each time.
Hope this clears things up.
Andrew
[Attachment #3 (text/html)]
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
<br>
<br>
Markus Ackermann wrote:<br>
<blockquote type="cite" cite="mid20020616211925.D29528@symlink.ch">
<pre wrap="">On Sun 16.06.2002, 12:49:59 -0600, Andrew Green said in public:
</pre>
<blockquote type="cite">
<pre wrap="">build() {
./configure || return 1
make || return 1
}
</pre>
</blockquote>
<pre wrap=""><!---->
It's quite ugly. And the 'return 1' is only evaluated if the first
statements exits with a non-zero return code, so the extra return 1
statement is redundant anyway.
</pre>
</blockquote>
Not quite true. It's not _that_ ugly. :-) (but it is a little \
ugly)<br> <br>
Also, build() will continue even if *ANYTHING* inside fails, until it reaches
the end of the function. As it is, I don't think there are any return codes
making it back into the main pkgmk script. That's why you'll run a pkgmk
and end up with an empty package after all the errors are done scrolling
off your screen.<br>
<br>
<blockquote type="cite" cite="mid20020616211925.D29528@symlink.ch">
<blockquote type="cite">
<pre wrap="">It doesn't really yield much info, but perhaps if Per extended the \
pkgmk spec to evalute the return code it could be more powerful.
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">'configure' failures return 1: "Pkgmk failed during ./configure."
(./configure || return 1)
</pre>
</blockquote>
<pre wrap=""><!---->[etc...]
This is pretty impossible and would make pkgmk ugly as hell. The point about
the build() function is that it can be run just as is. With your suggestion
the entire function must be parsed first, extended to include the messages
and control structure, and finally run. This would easily break if someone
uses a for loop over several lines for example. GNU make offers all we'd
ever want here, no need for Per to write his own f*cking complicated
Make^H^H^H^HPkgfile parser.
</pre>
</blockquote>
You totally misunderstood my idea. Here is a script with a fake Pkgfile
that executes _exactly_ what I'm talking about.<br>
<br>
# cat Pkgfile<br>
build()<br>
{<br>
ls -l testfile* 2> /dev/null || return 1<br>
cat testfile2 2> /dev/null || return 2<br>
chmod +r testfile3 2>/dev/null || return 3<br>
chmod -r testfile4 2>/dev/null || return 4<br>
}<br>
<br>
# cat mypkgmk<br>
#!/bin/sh<br>
<br>
. Pkgfile<br>
<br>
build<br>
RET=$?<br>
if [ $RET -ne 0 ]<br>
then<br>
case $RET in<br>
\
1) echo "First not found: $RET"; touch testfile;;<br> \
\
2) echo "Second not found: $RET"; cp testfile testfile2;;<br> \
\
3) echo "Third file not found: $RET"; cp testfile2 testfile3;;<br> \
\
*) echo "Fourth file not found: $RET"; rm testfile*;;<br> \
esac<br> fi<br>
<br>
Run this script four times and it'll give you a different return result each
time.<br>
<br>
Hope this clears things up.<br>
<br>
Andrew<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic