compiler info in kernel identification string

Mateusz Guzik mjguzik at
Thu Nov 15 14:08:34 UTC 2012

On Tue, Nov 13, 2012 at 03:57:55PM -0800, David Wolfskill wrote:
> I like the idea, but I have long found the idea of putting this type of
> logic (including VCS-awareness) in itself something that is
> prone to turn what should be a rather simple script into a ... mess.

I don't think is a mess (yet) and I find current features
highly desirable.

> What I have been using for several months has been a modified
> that uses an externally-defined function (from a file that is sourced)
> to handle whatever VCS-specific things I think are appropriate.  (Thus,
> folks who want to use one VCS don't need to have test for
> VCSen they don't use; they could also provide a sample file that
> provides the function.  An installation could use a symlink to point to
> the function definition of choice....  We could even have a "kitchen
> sink" default, that goes through all the hoops & gyrations the current
> code does, if folks want that.) definitely should continue to work without hints on cvs/svn/git.

Moving checks to different files seems completely unnecessary for me as
I don't find current checks expensive. But if you do the work I see
nothing wrong with it. :) (but please note I'm in no position to accept
your changes)

Given that, low-cost support for custom version strings could look like
this: after all standard values are filled, prepare complete version
string, then source custom script if it exists.

This way your script has access to everything that was able to
determine and to complete version string, and you are free to change it
however you want using detected revision/compiler/whatever or completely
new data.

Mateusz Guzik <mjguzik>

More information about the freebsd-current mailing list