Re: [Boost-build] [Boost-commit] svn:boost r79780 - trunk/tools/build/v2/engine

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