On 06 February, 2015 - Lubomir I. Ivanov wrote: > hello, > > in terms of our current scheme for updating ssrf-version.h, with each > git HEAD change one potential small issue is present where the macros > from the file itself are used on compile time by a number of files. > this forces recompilation of said files into object code even if they > effectively search for the same literals in the pool of the > executable. > > to solve the issue, i suggest the introduction of a version.c / > version.h pair which is a simple abstraction layer on top of the > generated ssrf-version.h. (more files, i know...) > > by changing the git HEAD, version.c will be the only object code that > has to be recompiled and the file itself will hold a simple API in the > lines of: > > const char *get_version(); > const char *get_version_git(); > const char *get_version_canonical(); > > it will be exposed via version.h and such that all the affected files > can use instead of the macros. the macros will be still available via > ssrf-version.h, but should not be used directly, especially in > complicated C++/Qt files. > > what this will do is to ensure that a version string is only retrieved > via a controlled branch (i.e. one of the 3 functions above). such > branches will be the only direct access points to the literal pool and > thus the recompilation process will be simplified. > > will such a patch be accepted? comments? >
I've thought about attacking the same problem myself, so I'm really happy that someone else have started to think about it to. My thought was just a: extern const char *version; extern const char *git_version; extern const char *canonical_version; Any up/down-sides towards using a extern or a function? //Anton -- Anton Lundin +46702-161604 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
