Re: make bin got dumb because of "Fix description in lily/include/smobs.hh"

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> until recently, 'make bin' was a very smart tool: it recompiled only
> necessary .cc files, not everything.  That was lifesaving: instead of
> having to wait for 5 minutes, i got the results of my changes in 5
> seconds.  Unfortunately, this is no longer the case: no matter how
> trivial the change, make bin always goes through all .cc files.  I've
> found that this behaviour was caused by commit
> 43fe858eb18418ae1d8867786ad873b7a4e2ae8a.  I have no idea why this
> happens, but i guess this isn't an intentional change?  I've checked
> that reverting this commit restores previous behaviour of make bin.
>
> commit 43fe858eb18418ae1d8867786ad873b7a4e2ae8a
> Author: David Kastrup <address@hidden>
> Date:   Sat Jun 30 15:06:44 2012 +0200
>
>     Fix description in lily/include/smobs.hh
>
> diff --git a/lily/include/smobs.hh b/lily/include/smobs.hh

This is a bit unlikely: the change is exclusively to comments, and the
comments don't look particularly magic.

> index cd28a29..fb4fa53 100644
> --- a/lily/include/smobs.hh
> +++ b/lily/include/smobs.hh
> @@ -46,7 +46,7 @@
>
>    The constructor for a complex smob should have 3 steps:
>
> -  * initialize all SCM members to a non-immediate value (like SCM_EOL)
> +  * initialize all SCM members to an immediate value (like SCM_EOL)
>
>    * call smobify_self ()
>
> @@ -67,7 +67,13 @@
>
>    Complex_smob *p = new Complex_smob;
>    list = scm_cons (p->self_scm (), list);
> -  scm_gc_unprotect_object (p->self_scm ());
> +  p->unprotect ();
> +
> +  Since unprotect returns the SCM object itself, this particular case
> +  can be written as
> +
> +  Complex_smob *p = new Complex_smob;
> +  list = scm_cons (p->unprotect (), list);
>
>    Complex smobs are made with DECLARE_SMOBS (Classname) in the class
>    declaration.

So obviously something else is wrong here.  Try removing
lily/out/smobs.dep and lily/out/smobs.o and see whether this helps.

To be expected is a large amount of recompilation _once_ since a lot of
files need smobs.hh.  If it occurs repeatedly, one has to suspect that
there is something like a read-only lily/out/smobs.o (perhaps written by
a different user), but then this should not work again after reverting
the file.  Reverting should actually pretty much do the same: touch the
comments and file date, but do nothing important otherwise.

-- 
David Kastrup