On Sat, Feb 1, 2014 at 1:07 AM, Ben Reser <ben_at_reser.org> wrote:
> Branko gave a perfectly reasonable answer. Beyond that I honestly don't get
> the point of these two emails. FreeBSD uses keywords because as an open source
> project they ship source. Even more importantly they have downstream projects
> (e.g. Apple uses their find command
> http://opensource.apple.com/source/shell_cmds/shell_cmds-175/find/main.c ). I
> can't think of a better way of tracking versioning for them once the source
> leaves their version control system and potentially goes into another. Yes
> there are all sorts of annoying bits about this.
If your build system has to rely on source control based fields,
process the code in your build system. Putting the keyword processing
in the source control itself certainly dates back ti RCS and CVS, and
has been the bane of comparing source trees in working copies, and of
of actually reviewing the source control that will be used for
building software. It profoundly interferes with generating
replicatable code in multiple build or test environments.
> Custom properties don't really make anything more difficult. Since custom
> properties are repository dictated configuration. In fact the custom property
> feature was written by the FreeBSD guys and then passed along upstream to ease
> this burden. They're not expecting Perforce to ever expand these. They stay
> literal in the source to show the base from upstream. The fact that Perforce
> doesn't expand it can be considered a feature.
I'd agree that Perforce's handling is correct. I'd also agree that
refusing the use of *any* keywords is, generally, correct.
> So if you're going to critique their technique, how about making a suggestion
> of a better technique. It's like a couple guys snickering in their Ferrari as
> a lorry goes by because he could have gotten there much faster in a Ferrari,
> even though the driver of the lorry only has the goal to get 10 tons of freight
> there not go fast.
Sorry if I sound cranky, I've been through this debate from various
angles. There are, indeed, short term conveniences in the legibility
of code when using keywords. But the long term consequences to stable
repositories of erratic disabling and re-enabling of keyword handling,
of cleaning up the accidental "diff" spew when it's handled
erratically, and the difficulty of code comparison in multiple platfom
projects continues to demonstrate its its awkwardness.
If you need to inject localized data in your source code, such as the
lat author or the upstream repository, that's what "filename.c.in" or
"filename.h.in" files are for. Process the files with local build or
copyright or whatever information as part of your software build
process, not in the basic source code. A commented "prepend" line, in
the relevant comment syntax, can be a savior and prevent internal
processing of text fields that happen to match the keyword
demarcations/
Received on 2014-02-02 04:14:37 CET