[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-16 18:49:59
[Download RAW message or body]
The guy from Arch-Linux used something like this in the build()
build() {
./configure || return 1
make || return 1
}
You get the idea.
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.
i.e.
'configure' failures return 1: "Pkgmk failed during ./configure."
(./configure || return 1)
'make' failures return 2: "Pkgmk failed during make." (make || return 2)
'make install' failures return 3: "Pkgmk failed during make install."
(make install || return 3)
etc...then you could also have custom return codes that when reported,
would allow you to track down in the Pkgfile where the failure occurred.
Ideas?
Andrew
Markus Ackermann wrote:
>On Sat 15.06.2002, 14:53:11 +0200, Per Liden said in public:
>
>
>>On Sat, 15 Jun 2002, TobbY Nowack wrote:
>>
>>
>>>When I build some ports last days I had probles with some dependencies.
>>>It would be nice when the pkgmk tool would directly stop if an error acours.
>>>
>>>
>
>
>
>>The problem is that pkgmk doesn't have control over what build() does and
>>can not intercept errors from ./configure or any other program. A solution
>>
>>
>
>Right. I've been thinking about that problem too, and I'd like to have a
>make-like mechanism. This would mean significant changes to how the entire
>pkgmk mechanism works now... but one of the benefits is that the build
>process stops as soon as an error occurs, thus reducing wasted time and
>efforts.
>
>Markus.
>
>PS: another benefit is that it would allow for an easier recursive build
>process following build time dependencies.
>
>
>.
>
>
>
[Attachment #3 (text/html)]
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
The guy from Arch-Linux used something like this in the build()<br>
<br>
build() {<br>
./configure || return 1<br>
make || return 1<br>
}<br>
<br>
You get the idea.<br>
<br>
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.<br>
<br>
i.e. <br>
'configure' failures return 1: "Pkgmk failed during ./configure." (./configure
|| return 1)<br>
'make' failures return 2: "Pkgmk failed during make." (make || return 2)<br>
'make install' failures return 3: "Pkgmk failed during make install." (make
install || return 3)<br>
<br>
etc...then you could also have custom return codes that when reported, would
allow you to track down in the Pkgfile where the failure occurred.<br>
<br>
Ideas?<br>
<br>
Andrew<br>
<br>
<br>
<br>
Markus Ackermann wrote:<br>
<blockquote type="cite" cite="mid20020616110112.B29528@symlink.ch">
<pre wrap="">On Sat 15.06.2002, 14:53:11 +0200, Per Liden said in public:
</pre>
<blockquote type="cite">
<pre wrap="">On Sat, 15 Jun 2002, TobbY Nowack wrote:
</pre>
<blockquote type="cite">
<pre wrap="">When I build some ports last days I had probles with some dependencies.
It would be nice when the pkgmk tool would directly stop if an error acours.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">The problem is that pkgmk doesn't have control over what build() does and
can not intercept errors from ./configure or any other program. A solution
</pre>
</blockquote>
<pre wrap=""><!---->
Right. I've been thinking about that problem too, and I'd like to have a
make-like mechanism. This would mean significant changes to how the entire
pkgmk mechanism works now... but one of the benefits is that the build
process stops as soon as an error occurs, thus reducing wasted time and
efforts.
Markus.
PS: another benefit is that it would allow for an easier recursive build
process following build time dependencies.
.
</pre>
</blockquote>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic