Re: [Vala] Rules for updating generated C files

Please do.  "This bug affects me too."

On Thu, Jun 3, 2010 at 5:13 PM, Robert Powell <rob yorba org> wrote:


My understanding of the current rule for generating a C file from a vala
file is, if the contents of the C file has the same hash value, don't
rewrite the file.  When dealing with larger systems using libraries, this
rule may not be sufficient.

I've attached an example program that illustrates the problem I describe
below.  To exhibit the problem:
1. execute make
2. execute ./main.  Note the output.
3. comment out the variable comment_and_uncomment_me in file
BaseClass.vala.  Remember to save.
4. execute make
5. execute ./main.  Note the output is different and wrong.

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.
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.

I propose that if the C file (Derived.c in this instance) that is generated
has the same hash value as the existing C file BUT the corresponding vala
file (Derived.vala) imports anything from a vapi (BaseClass.vapi) that has
an earlier timestamp, the C file (Derived.c) should be touched.  Does valac
have enough of this information to perform this check?

For this simple system, it would be easy enough to update the makefile to
watch for this dependency.  For larger systems, however, I could see that
this could quickly get much more complex and error-prone.  I think that
the addition of this rule, it avoids this dependency problem.

Is this a reasonable request?  Shall I file a bug?



vala-list mailing list
vala-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]