Date: Thu, 31 Jan 2002 05:43:45 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: "."@babolo.ru Cc: joe@tao.org.uk, sheldonh@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, bde@zeta.org.au Subject: Re: conf/6346: Kernel version strings need to relate to the source not the build Message-ID: <C8AC5466-163F-11D6-8673-0003930737AC@dataplex.net> In-Reply-To: <200201310401.HAA01299@aaz.links.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, January 30, 2002, at 10:01 PM, "."@babolo.ru wrote: > Richard Wackerbarth writes: >> On Wednesday, January 30, 2002, at 06:26 PM, "."@babolo.ru wrote: >> >>> Richard Wackerbarth writes: >>>> It can also be done by playing games on a special file in the master >>>> cvs archive (but not the copies thereof) >>> Exactly. >>> What about do >>> date +'#define LAST_MOD "%Y-%m-%d %H:%M:%S"' > /path/last_mod_date.h >>> on any CVS tree update? > Sorry, commit > >>> And #include <last_mod_date.h> >> >> That won't work. It produces the time of the cvs checkout/update and >> not >> the time of the source modification. >> That is little better than the time of the compile that we have now. > I think about commit time (my mistake, not checkout) > But I understand, it is slightly complex to generate > last_mod_date.h,v then last_mod_date.h, > but there no need in tags in it, so it can be whole > overwritten by every commit Rather than computing the source date from the sources as Joe's algorithm does, you could compute that result at commit time and commit that time to the master cvs tree. The problem with that approach is that such a file would grow at an unacceptable rate. Your suggestion to simplify if to the extreme doesn't work either. Consider what happens if I check out any version other than the "HEAD". By your approach, I would get a recent time stamp and not the one which reflects the true age of the sources that I am using. Now, I do think your idea has some merit. For example, we could override the checkout/update procedure for this special file to produce a time stamp when checking out the head of a branch and to produce some other identifier when another tag is used. Other approaches which approximate the true source time stamp can also be considered. It might be reasonable to trade time granularity for accuracy. For example, you might update the source time stamp only once a day. That leaves some uncertainty in the result (Was that Thursday before xxx was corrected, or after? However, it would still be clear that it was before Saturday's change.) As Joe notes in another message, having the option to suppress the recalculation might be a good approach. Power users who are most impacted by the added complexity of the build time probably don't need the same level of source identification. Another approach is to integrate the searching with the build process. Instead of examining each source file directly, you can partition the files into subsets and compute a time stamp for each subset. The global time stamp can then be computed by examining only the limited number of collective time stamps. Modification of a file would trigger the computation of the time stamp for its subset, and hence the global time stamp, but not involve the other subsets. -- Richard Wackerbarth The Digital Dataplex (512) 346-5772 8801 Camelia Ln rkw@dataplex.net Austin, TX 78759 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C8AC5466-163F-11D6-8673-0003930737AC>