On 09/04/2010 03:07 PM, Kinkie wrote:
On Sat, Sep 4, 2010 at 8:50 PM, Alex Rousskov
<[email protected]> wrote:
On 09/03/2010 11:37 AM, Kinkie wrote:
Hi all,
a followup to yesterday's and today's IRC discussion.
This patch adds a configure option --enable-build-info[=text]
If text is specified, it will print it on the second line of "squid -v".
If the option is given but no text is specified, configure will
attempt to determine whether we are in a bzr checkout and locate the
bzr executable. If both succeed, it will automatically build a text
string containing the branch nickname and revno.
If no option is given, nothing will happen.
This patch serves two purposes:
- help those who closely trail trunk or some other bzr branch to
easily pinpoint good revisions
How would this change helps those who closely trail trunk to easily pinpoint
good revisions?
If a bleeding edge trailer just specifies --enable-build-info to his
builds, he'll know what revno he's running by simply asking the
executable about it. Otherwise he'll have to use other means (textual
conventions, usually).
I usually have a "known-good" binary, and a "testing" binary. Often I
forget what version is either. My need is to have a simple way to
tell.
I would document this part of the rationale differently then: "help
those who build binaries from multiple bzr sources to associate the
binary with the bzr source it was based on".
I would also either warn if bzr sources contain uncommitted changes
and/or add "with changes" or "+changes" to the build info line. Without
that, it is easy to be mislead by the version information, especially
when it comes from a 3rd party or was included long (i.e., a few days) ago.
- help those who develop custom builds (e.g. for a specific customer)
explicitly mark it as such.
* Would not the printf below add an empty line by default, due to \n after
the new %s?
printf("Squid Cache: Version %s\n%s\nconfigure options: %s\n",
version_string, SQUID_BUILD_INFO, SQUID_CONFIGURE_OPTIONS);
We should not add an empty line, IMO.
It's minor, I'll change it.
Thank you,
Alex.