I backup all the source files using source control on every build..., but I presently had no way to connect a data file to the exact source that was used to make it... I'm sure this has been done a thousand times... before but I reinvented the wheel last night...
I wrote a simple header file...
call it FileList.h
//A Class to make a static linked list of ALL files included in the project....
static FileList * pHead;
FileList * m_pNext;
const char * m_pName;
//The constructor will add the name to the global static linked list...
FileList(const char * name)
static void ShowList();
//A Static opbject that does the real work...
//__BASE_FILE__ is the name of the file being compiled rather thatn this header file
static FileList FL(__DATE__ "," __TIME__ "," __BASE_FILE__);
If you #include "filelist.h"
in every single C++ file in your project... this will make a linked list of
all the file names, dates and times..... a list I can prepend to the data log on startup...
so now the whole code set and its date time are included in the data log on every start...
Maybe this is common knowledge, but the __BASE__FILE__ macro was a new one to me...
If the problem being solved is "given a log file, how can I get the source that will interpret it correctly", I'd find it much easier to:
a) never use a binary to collect data that was built from uncommited code (necessary in any scheme that allows you to get the original source)
b) inject the revision/hashtag, into your code
The final step is always going to be "checkout revision/hashtag" so you've got the actual source that matches. I'd think trying to translate "such and such a date, such and such a filename" into a revision/hash so you can checkout would be quite tedious.
 this is much easier if using a version control system that makes it trivially easy to manage branches and commits (e.g. git) so there isn't inherent overhead related to the committing.
 if you're using dependency builds, make sure this info is stored in a symbol in a lib that gets rebuilt every build and linked implicitly -- otherwise you'll get stale data stuck in your old object files.
Easy extension to add the GIT maintained tags/revs for each file in the file list prepended to the log data....
Indeed. What would be interesting (if space weren't a concern) is if there were a __FILE_CONTENTS__. No external dependencies at all. As a work-around, heavily compressing a tarball of the source dir, bin2c, link to program and dump that blob first in your log could also work.
P.S. been reading your progress for years and enjoy your updates
valentine quotes for girlfriend
valentine day wishes for girlfriend
valentine day poems for girlfriend
christian louboutin outlet
christian louboutin outlet
coach outlet sale
air max 270
Thanks for sharing the info. I located the information very useful. That’s a brilliant story you posted. I will come back to read some more. Feel free to visit my website;
Very useful post. This is my first time i visit here. I found so many interesting stuff in your blog especially its discussion. Really its great article. Keep it up Feel free to visit my website; 일본야동
Hi there, after reading this remarkable paragraph i am too happy to share my experience here with friends. Feel free to visit my website; 일본야동
Post a Comment