[Build-common-hackers] Bug#521711: Bug#521711: Looks fixed.

[Raúl Sánchez Siles]

  Hello all, Jonas:

El Lunes 08 Junio 2009, Jonas Smedegaard escribió:
>
> Hi Raúl,
>
> On Sat, Jun 06, 2009 at 12:06:38AM +0200, Raúl Sánchez Siles wrote:
> >  The issue seems solved now.
>
> I am confused: What changed since you filed the bugreport?
>
>
[..]
> Therefore: Please elaborate on what you believe has changed - either in
> your packaging or with the cdbs tool - that resolved this issue.
>

  Yes, I can't doubt you are since this close was caused by a terrible mess on 
my side. When I read your e-mail I decided to test your solution and I did: 
modifying the real makefile.mk file. I did a copy of the original one, but after 
some time, when I revisited the issue, I totally forgot what I had done and I 
understood you already applied the fix to the cdbs package.

  In short, your patch works and should be applied IMHO.

> >  So this is ok, IMHO. Only remark here is that if you are using
> >out-of-tree builds with cmake a rm -r on the build tree result would be
> >the same, unless there's some evil build step that places files out of
> >the build tree. Like I happen to have. :)
>
> I am new to CMake - could you please elaborate on above remark too?  Do
> you say that the cmake.mk snippet perhaps could be improved somehow?
>
>
  Sure. When you use cmake you usually do out of tree builds which means that 
you create a dir typically inside the source tree where are the modified or 
created files during the build stage will be stored. Once you build the 
package, the source tree is supposed to be in the very same state as you got 
it, so doing:

rm -r <build-tree>

should be idempotent to:

make -C <build-tree> clean
rm -r <build-tree>

  It's only that formally, IMHO, the latter is more correct.

  Besides this, if the build system creates, modifies or removes files from the 
source not restoring them after the clean, the out-of-tree method is not 
totally implemented and I consider this a bug, probably in the build system or 
its configuration.

  Since both methods detailed above are idempotent, I'm not sure how to mix 
all this information together to get a right approach. I think both approaches 
(yours and mine) would address the 2nd method, point here is which one should 
be definitely used: the one that is being deployed now or the latter which is 
the one your patch define.

Hope this time is clearer.

> Kind regards,
>
>   - Jonas

  Regards,
-- 
     Raúl Sánchez Siles
----->Proud Debian user<-----
Linux registered user #416098
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20090608/480e53b3/attachment.pgp>