I thought I understood this, but compiling the sketch below gives undefined reference to `syncInterval'. (syncInterval is a global variable defined in Time.cpp.)
syncInterval is a global variable defined in Time.cpp.
If syncInterval is in the cpp and not the h then you should note be trying access it , if its in the h file you don't need extern time_t syncInterval;.
I don't want to see what you thing the error message is I need to see the exact text of the error from the IDE use cut and paste!.
you just need to download and install the Time library in the "libraries" folder, restard IDE and it compiles without error
edit : oups, sorry, remove the 'extern' too
edit2 : and I think you can't use the 'extern' keyword, because, in time.cpp, syncInterval is defined as static, thus AFAIK, cannot be used in another file.
@alnath, that is indeed the reason, thank you very much!
@holmes4, that was the entire error message, although I did take the liberty of removing the directory structure, which was longer than the error message itself. Would this have told you a lot more?
C:\Users\Jack\Documents\arduino\arduino-1.0.5/sketch_dec08b.ino:7: undefined reference to `syncInterval'
syncInterval is not in a function, it is a global variable in the Time.cpp file as I said. In general, there is nothing wrong with an extern reference to a variable in another file. I suppose if the author doesn't want it diddled with, they can always make it static
The static keyword in the global scope forces a symbol (variable or function) to have local only linkage. This means that it only ever exists within the compilation unit it is defined in.
If you are writing a library or similar shared object which uses global variables it is good practice to make them static unless you really really really need to make them directly available outside your library. The same goes for functions - unless they are intended to be called by other external code it is good practice to make them static.
The reason for this is it means you can have other globals and functions in other compilation units with the same name and they wont conflict. Ideally you should treat the global variables in a library as private member functions in a class and provide getters and setters for manipulating them.