Boost logo

Boost-Build :

Subject: Re: [Boost-build] [Boost-commit] svn:boost r79780 - trunk/tools/build/v2/engine
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-08-02 10:38:54


AMDG

On 08/02/2012 01:12 AM, Jurko Gospodnetić wrote:
> Hi.
>
>>> Updated Boost Jam to know how to report its minimum supported
>>> file modification timestamp resolution (currently reported as
>>> part of Boost Jam's version information). This allows external
>>> tools using Boost Jam to adapt to Boost Jam's potential ignorance
>>> of fine file modification timestamp changes.
>>
>> I don't think the version output is the correct
>> place to put this. Please find a better way.
>
> Do you have any suggestions?
>
> I see the '-v' option as asking Boost Jam to 'tell me things about
> itself that might be important to me as a user'. And this information is
> important to me 'as a user' as it tells me how long I have to wait to
> have the Build system recognize a touched/modified file as such.
>

Version flags have never meant that. This would be
like a compiler that said

> g++ -v
4.9.2
class template partial specialization: yes
rvalue references: yes
lambdas: yes
...1000 more features...

which is ridiculous.

> I looked into adding this as a separate command-line option but there
> is already a mess of those, the existing ones did not seem to fit the
> purpose other than '-v' and there were no unused letters available that
> seemed to fit either.
>
> YMMV, but at the moment, I really do not see a place where this
> information would be better presented. '-v' option reports Boost Jam's
> version information including the version identifier, the OS and some
> arbitrary list of copyright holders. Whether a specific implementation
> supports finer grained path modification timestamp resolution seems like
> another implementation detail information token at the same level as those.
>

It's totally different. A version flag
normally indicates enough to identify
the tool. Copyright information is
a common extra. Specific features are
a totally different affair.

If you really need to test it, something
like this would be reasonable:

timestamp-resolution.jam:
EXIT $(TIMESTAMP_RESOLUTION) : 0 ;

resolution = `b2 -ftimestamp-resolution.jam`

> Confusingly, we also have a different '--version' option handled by
> Boost Build code and reporting a bit different information, but I see
> that as a separate issue.
>
>
>>> Log:
>>> Boost Jam version information output cleaned up a bit to make it
>>> easier to update it with additional information.
>>
>> /Really/? If you want some kind of key/value
>> feature testing, it doesn't belong under the
>> regular version flag. Please revert this.
>> I just find it ugly.
>
> If you do not like the formatting - please suggest a better one. Or,
> if you /Really/ feel that strong about the current one and can give no
> alternate suggestions, I can just revert the whole shabang, but please
> first confirm explicitly whether this is needed as I'm not really happy
> with that course of action...
>

I'm strongly in favor of reverting this entirely.
I do not believe that the -v flag is an
appropriate choice for presenting this information.

In Christ,
Steven Watanabe


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk