Re: [Vala] Rules for updating generated C files
- From: Jan Hudec <bulb ucw cz>
- To: Robert Powell <rob yorba org>
- Cc: vala-list <vala-list gnome org>
- Subject: Re: [Vala] Rules for updating generated C files
- Date: Tue, 8 Jun 2010 22:23:06 +0200
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 <bulb ucw cz>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]