On Thu, Jun 03, 2010 at 14:13:01 -0700, Robert Powell wrote:
> What is going on here
> -------------------------------
> We have a library BaseClass.vapi that is generated from BaseClass.vala.
> This defines the class BaseClass. We also have Derived.vala, which defines
> a class that derives from BaseClass.
>
> If a member variable is added to BaseClass, BaseClass.vapi will change. The
> C file that is generated from Derived.vala will be identical, but it needs
> to be recompiled because the base class has changed. valac will not
> regenerate Derived.c because it hasn't changed.
The Makefile in your example is hopelessly broken. Derived.c has not changed,
but it certainly includes BaseClass.h which must have had. The makefile fails
to see that Derived.o depends on BaseClass.h and the fix should be to make
the makefile directly aware of the fact.
That way it can detect when not-vala-generated headers change which vala
can't, because not every significant change in the header needs to be
reflected in the corresponding .vapi (e.g. changing symbolic constants
won't).
It is different matter for the case where valac itself calls the C compiler.
If it fails to do the dependency resolution right (and I expect it would
fail), it's a bug. That's not what your example demonstrated, though.
Note that automake automatically considers dependency on (directly or
indirectly) included headers by asking the preprocessor to generate the
additional make rules as side-effect of the compilation and most non-make
build systems (like cons, scons, cmake, makepp,...) have special parsers to
look for include dependencies.
--
Jan 'Bulb' Hudec <[email protected]>
_______________________________________________
vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
