On Fri, Aug 12, 2011 at 6:58 PM, Dave Reisner <d@falconindy.com> wrote:
> On Tue, Aug 09, 2011 at 12:56:41PM +0200, Sebastien Luttringer wrote:
>> Before this, cleaning is done when script exit with a value != 0.
>> If a build fail, directory remain unclean. The purpose of cleaning should
>> not be changed if build fail.
>
> I think this is intended behavior. One might want to investigate _why_ a
> build failed by looking in the $srcdir.
Someone who wants to investigate a build failure doesn't pass -c as argument ?

Same as you don't strip when you want to debug.
gcc -g toto.c -o toto; strip toto, have the same behaviour

When you call "makepkg", it will fail and don't remove content to make
investigation. If you call "makepkg -c", i suppose, you want do clean
(even it fail).

My idea was to be able to clean a directory without build package.
But i can implement something like -C which just clean content of the
current directory.

--
Sébastien Luttringer
www.seblu.net

On Fri, Aug 12, 2011 at 07:49:07PM +0200, Seblu wrote:
> On Fri, Aug 12, 2011 at 6:58 PM, Dave Reisner <d@falconindy.com> wrote:
> > On Tue, Aug 09, 2011 at 12:56:41PM +0200, Sebastien Luttringer wrote:
> >> Before this, cleaning is done when script exit with a value != 0.
> >> If a build fail, directory remain unclean. The purpose of cleaning should
> >> not be changed if build fail.
> >
> > I think this is intended behavior. One might want to investigate _why_ a
> > build failed by looking in the $srcdir.
> Someone who wants to investigate a build failure doesn't pass -c as argument ?

You're assuming that you know beforehand that the package will build
correctly. For any non-vcs package, I almost always want to use
`makepkg -risc'.

> Same as you don't strip when you want to debug.
> gcc -g toto.c -o toto; strip toto, have the same behaviour

I don't think how this is analogous. The behavior we have with -c is
more similar to:

make && make install && make clean

Note the conditional nature of this.

> When you call "makepkg", it will fail and don't remove content to make
> investigation. If you call "makepkg -c", i suppose, you want do clean
> (even it fail).

And as I mentioned above, you don't know that the package will be built
successfully, but you want the build directory cleaned IFF it does build.

> My idea was to be able to clean a directory without build package.
> But i can implement something like -C which just clean content of the
> current directory.
>

On Fri, Aug 12, 2011 at 8:06 PM, Dave Reisner <d@falconindy.com> wrote:
> On Fri, Aug 12, 2011 at 07:49:07PM +0200, Seblu wrote:
>> On Fri, Aug 12, 2011 at 6:58 PM, Dave Reisner <d@falconindy.com> wrote:
>> > On Tue, Aug 09, 2011 at 12:56:41PM +0200, Sebastien Luttringer wrote:
>> >> Before this, cleaning is done when script exit with a value != 0.
>> >> If a build fail, directory remain unclean. The purpose of cleaning should
>> >> not be changed if build fail.
>> >
>> > I think this is intended behavior. One might want to investigate _why_ a
>> > build failed by looking in the $srcdir.
>> Someone who wants to investigate a build failure doesn't pass -c as argument ?
>
> You're assuming that you know beforehand that the package will build
> correctly. For any non-vcs package, I almost always want to use
> `makepkg -risc'.
>
>> Same as you don't strip when you want to debug.
>> gcc -g toto.c -o toto; strip toto, have the same behaviour
>
> I don't think how this is analogous. The behavior we have with -c is
> more similar to:
>
> make && make install && make clean
>
> Note the conditional nature of this.
>
>> When you call "makepkg", it will fail and don't remove content to make
>> investigation. If you call "makepkg -c", i suppose, you want do clean
>> (even it fail).
>
> And as I mentioned above, you don't know that the package will be built
> successfully, but you want the build directory cleaned IFF it does build.
ok do you think a -C which clean inconditionnaly and let -c clean when success ?

Regards,

--
Sébastien Luttringer
www.seblu.net

On 13/08/11 04:34, Seblu wrote:

On Fri, Aug 12, 2011 at 8:06 PM, Dave Reisner<d@falconindy.com> wrote:

On Fri, Aug 12, 2011 at 07:49:07PM +0200, Seblu wrote:

On Fri, Aug 12, 2011 at 6:58 PM, Dave Reisner<d@falconindy.com> wrote:

On Tue, Aug 09, 2011 at 12:56:41PM +0200, Sebastien Luttringer wrote:

Before this, cleaning is done when script exit with a value != 0.
If a build fail, directory remain unclean. The purpose of cleaning should
not be changed if build fail.


I think this is intended behavior. One might want to investigate _why_ a
build failed by looking in the $srcdir.

Someone who wants to investigate a build failure doesn't pass -c as argument ?


You're assuming that you know beforehand that the package will build
correctly. For any non-vcs package, I almost always want to use
`makepkg -risc'.


Same as you don't strip when you want to debug.
gcc -g toto.c -o toto; strip toto, have the same behaviour


I don't think how this is analogous. The behavior we have with -c is
more similar to:

make&& make install&& make clean

Note the conditional nature of this.


When you call "makepkg", it will fail and don't remove content to make
investigation. If you call "makepkg -c", i suppose, you want do clean
(even it fail).


And as I mentioned above, you don't know that the package will be built
successfully, but you want the build directory cleaned IFF it does build.

ok do you think a -C which clean inconditionnaly and let -c clean when success ?


Is it really necessary? "rm -rf pkg/ src/" does the job...

Allan

On Sat, Aug 13, 2011 at 12:53 AM, Allan McRae <allan@archlinux.org> wrote:
> On 13/08/11 04:34, Seblu wrote:
>>
>> On Fri, Aug 12, 2011 at 8:06 PM, Dave Reisner<d@falconindy.com> *wrote:
>>>
>>> On Fri, Aug 12, 2011 at 07:49:07PM +0200, Seblu wrote:
>>>>
>>>> On Fri, Aug 12, 2011 at 6:58 PM, Dave Reisner<d@falconindy.com> *wrote:
>>>>>
>>>>> On Tue, Aug 09, 2011 at 12:56:41PM +0200, Sebastien Luttringer wrote:
>>>>>>
>>>>>> Before this, cleaning is done when script exit with a value != 0.
>>>>>> If a build fail, directory remain unclean. The purpose of cleaning
>>>>>> should
>>>>>> not be changed if build fail.
>>>>>
>>>>> I think this is intended behavior. One might want to investigate _why_
>>>>> a
>>>>> build failed by looking in the $srcdir.
>>>>
>>>> Someone who wants to investigate a build failure doesn't pass -c as
>>>> argument ?
>>>
>>> You're assuming that you know beforehand that the package will build
>>> correctly. For any non-vcs package, I almost always want to use
>>> `makepkg -risc'.
>>>
>>>> Same as you don't strip when you want to debug.
>>>> gcc -g toto.c -o toto; strip toto, have the same behaviour
>>>
>>> I don't think how this is analogous. The behavior we have with -c is
>>> more similar to:
>>>
>>> make&& *make install&& *make clean
>>>
>>> Note the conditional nature of this.
>>>
>>>> When you call "makepkg", it will fail and don't remove content to make
>>>> investigation. If you call "makepkg -c", i suppose, you want do clean
>>>> (even it fail).
>>>
>>> And as I mentioned above, you don't know that the package will be built
>>> successfully, but you want the build directory cleaned IFF it does build.
>>
>> ok do you think a -C which clean inconditionnaly and let -c clean when
>> success ?
>
> Is it really necessary? *"rm -rf pkg/ src/" does the job...

ok


--
Sébastien Luttringer
www.seblu.net

On Sat, Aug 13, 2011 at 1:08 AM, Seblu <seblu@seblu.net> wrote:
> On Sat, Aug 13, 2011 at 12:53 AM, Allan McRae <allan@archlinux.org> wrote:
>> Is it really necessary? *"rm -rf pkg/ src/" does the job...
>
> ok
>

I have these functions in my .bashrc. Feel free to use or modify them.

cdp() {
local relpath="$HOME/abs" subdirs
if ! [[ "$PWD" == "$relpath"* ]]; then
echo "Error: this function is made for use in $relpath" >&2
return 1
fi
subdirs="${PWD:${#relpath}+1}"
cd "$relpath/${subdirs%%/*}"
}

nanop() {
if cdp; then
set -- -Ysh "PKGBUILD"
$(which nano) "$@"
cd -
fi
}

clearp() {
if cdp; then
. /etc/makepkg.conf
rm -rf src pkg *"$PKGEXT" *"$SRCEXT"
fi
}