Hello, 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. 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. 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 with the addition of this rule, it avoids this dependency problem. Is this a reasonable request? Shall I file a bug? Thanks Rob
Attachment:
vapi_example.tar.gz
Description: GNU Zip compressed data