Re: When can we retire V1

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: When can we retire V1

Vladimir Prus
David Abrahams wrote:

>
> Happy New Year, everyone!

Happy New Year!

>
> It's a brand new year; Boost should switch to a "brand new" build
> system, ASAP.  How close are we to being able to make that switch?

Good question. The absolutely fair answer is that we don't know until we
try. I can get the ball rolling, but we really need to decide on the steps
to be made, and work on them together to push this to completion. Here are
the steps that I'd propose:

1. I set up a script that will run all Boost regressions with V1 and V2 and
compare results, and adjust V2 Jamfiles to get zero differences on
Linux/gcc.

2. Somebody else with Linux/gcc run the same script to verify the results
are the same for him too.

3. Somebody with Windows/msvc compares V1 and V2 results too, coordinating
with me to get them equal.

4. We adjust the regression.py script to have "--v2" switch and ask some of
the current regression runners to test it.

5. We post to Boost mailing list, explaining that we're technically ready to
move to V2, and if anybody has any arguments against.

6. Regression runners switch to V2 and "bjam" in Boost starts to use V2 by
default, with V1 invoked by "--v1" option.

7. Any issues are ironed out.


There are two issues that are likely to arise along the way:
1. I still haven't tried to port serialization tests to V2, and they are
pretty contrived.

2. The auto-configuration of toolsets works with msvc only, so we need to
add auto-configuration to gcc, at least.


- Volodya

 


_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: When can we retire V1

Bugzilla from markus.schoepflin@comsoft.de
Vladimir Prus wrote:

> 7. Any issues are ironed out.

Some things which come to my mind:

1. Quite a number of test jam files contain workarounds for specific
compilers or platforms. Most look something like this (just as an example):

local rule special-requirements ( toolset variant : properties * )
{
     if $(UNIX) && $(OS) = OSF
     {
         switch $(toolset)
         {
             case gcc* : properties += <cflags>-mfp-rounding-mode=d ;
             case tru64cxx* : properties += <cflags>-fprm <cflags>d ;
         }
     }

     return $(properties) ;
}

local rule local-run ( sources + : args * : input-files * : requirements *
     : name ? : default-build * : args2 * )
{
     return [ run $(sources) : $(args) : $(input-files)
         : $(requirements) special-requirements
         : $(name) : $(default-build) : $(args2) ] ;
}

How does the corresponding V2 code look like?

2. I use customized tool sets for all of my regression runs. For V1, one
such file looks like this:

{
     extends-toolset tru64cxx65 ;

     flags tru64cxx65 CFLAGS : -version V6.5-042 -ieee ;
     flags tru64cxx65 LINKFLAGS : -version V6.5-042 -ieee ;
}

How will these customized tool sets work under V2?

3. Some jam files use internal V1 functions when calculating the local
requirements. For example, expressive uses "properties = [ difference
$(properties) : <debug-symbols>on ] <debug-symbols>off ;", multi_index uses
"properties = [ replace-properties $(properties) : <debug-symbols>off ] ;"
How will this have to look in V2?

Markus

_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: When can we retire V1

Martin Wille
Markus Schöpflin wrote:

> 2. I use customized tool sets for all of my regression runs. For V1, one
> such file looks like this:
>
> {
>      extends-toolset tru64cxx65 ;
>
>      flags tru64cxx65 CFLAGS : -version V6.5-042 -ieee ;
>      flags tru64cxx65 LINKFLAGS : -version V6.5-042 -ieee ;
> }

Same here. A reasonably idiot-proof transition guide for the testers
would be helpful (at least in my case). That guide must not require
putting files into the runners home directory since that would interfere
with other boost-related activities.


Regards,
m
Send instant messages to your online friends http://au.messenger.yahoo.com 
_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: When can we retire V1

Vladimir Prus
In reply to this post by Bugzilla from markus.schoepflin@comsoft.de
On Friday 13 January 2006 13:19, Markus Schöpflin wrote:

> Some things which come to my mind:
>
> 1. Quite a number of test jam files contain workarounds for specific
> compilers or platforms. Most look something like this (just as an example):
>
> local rule special-requirements ( toolset variant : properties * )
> {
>      if $(UNIX) && $(OS) = OSF
>      {
>          switch $(toolset)
>          {
>              case gcc* : properties += <cflags>-mfp-rounding-mode=d ;
>              case tru64cxx* : properties += <cflags>-fprm <cflags>d ;
>          }
>      }
>
>      return $(properties) ;
> }
>
> local rule local-run ( sources + : args * : input-files * : requirements *
>
>      : name ? : default-build * : args2 * )
>
> {
>      return [ run $(sources) : $(args) : $(input-files)
>
>          : $(requirements) special-requirements
>          : $(name) : $(default-build) : $(args2) ] ;
>
> }
>
> How does the corresponding V2 code look like?

In the simplest form:

    return [ run .....
         : $(requirements) <os>OSF,<toolset>gcc>:<cflags>-mfp-rounding=mode=d
         ....

That's provided that <os>OSF is property set on that OS, and if not that can
be fixed.

> 2. I use customized tool sets for all of my regression runs. For V1, one
> such file looks like this:
>
> {
>      extends-toolset tru64cxx65 ;
>
>      flags tru64cxx65 CFLAGS : -version V6.5-042 -ieee ;
>      flags tru64cxx65 LINKFLAGS : -version V6.5-042 -ieee ;
> }
>
> How will these customized tool sets work under V2?

Something like:
 
   using tru64cxx65 : : <cflags>"-version V6.5-042 -ieee" ;

> 3. Some jam files use internal V1 functions when calculating the local
> requirements. For example, expressive uses "properties = [ difference
> $(properties) : <debug-symbols>on ] <debug-symbols>off ;", multi_index uses
> "properties = [ replace-properties $(properties) : <debug-symbols>off ] ;"
> How will this have to look in V2?

Can't tell right now, I'll have to look at those Jamfile in detail.

- Volodya

_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: When can we retire V1

Bugzilla from markus.schoepflin@comsoft.de
Vladimir Prus wrote:

> On Friday 13 January 2006 13:19, Markus Schöpflin wrote:
>
>> Some things which come to my mind:
>>
>> 1. Quite a number of test jam files contain workarounds for specific
>> compilers or platforms. Most look something like this (just as an example):
>>
>> local rule special-requirements ( toolset variant : properties * )
>> {
>>      if $(UNIX) && $(OS) = OSF
>>      {
>>          switch $(toolset)
>>          {
>>              case gcc* : properties += <cflags>-mfp-rounding-mode=d ;
>>              case tru64cxx* : properties += <cflags>-fprm <cflags>d ;
>>          }
>>      }
>>
>>      return $(properties) ;
>> }
>>
>> local rule local-run ( sources + : args * : input-files * : requirements *
>>
>>      : name ? : default-build * : args2 * )
>>
>> {
>>      return [ run $(sources) : $(args) : $(input-files)
>>
>>          : $(requirements) special-requirements
>>          : $(name) : $(default-build) : $(args2) ] ;
>>
>> }
>>
>> How does the corresponding V2 code look like?
>
> In the simplest form:
>
>     return [ run .....
>          : $(requirements) <os>OSF,<toolset>gcc>:<cflags>-mfp-rounding=mode=d
>          ....
>
> That's provided that <os>OSF is property set on that OS, and if not that can
> be fixed.

Can this do pattern matching as well? Because this is why local rules are
used in the first place. The actual tool set name will be something like
gcc-4.0.2-osf, or tru64cxx65-042, or something similar.


>> 2. I use customized tool sets for all of my regression runs. For V1, one
>> such file looks like this:
>>
>> {
>>      extends-toolset tru64cxx65 ;
>>
>>      flags tru64cxx65 CFLAGS : -version V6.5-042 -ieee ;
>>      flags tru64cxx65 LINKFLAGS : -version V6.5-042 -ieee ;
>> }
>>
>> How will these customized tool sets work under V2?
>
> Something like:
>  
>    using tru64cxx65 : : <cflags>"-version V6.5-042 -ieee" ;

Sounds easy.

[snip]

Markus

_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: When can we retire V1

Vladimir Prus
On Friday 13 January 2006 15:00, Markus Schöpflin wrote:


>> How does the corresponding V2 code look like?
> >
> > In the simplest form:
> >
> >     return [ run .....
> >
> >          : $(requirements)
> >          : <os>OSF,<toolset>gcc>:<cflags>-mfp-rounding=mode=d
> >
> >          ....
> >
> > That's provided that <os>OSF is property set on that OS, and if not that
> > can be fixed.
>
> Can this do pattern matching as well? Because this is why local rules are
> used in the first place. The actual tool set name will be something like
> gcc-4.0.2-osf, or tru64cxx65-042, or something similar.

No, there's no pattern matching. But in V2, toolset version is separate from
toolset name, so all versions of gcc on your system will have toolset=gcc,
thus

   <toolset>gcc:<clags>-mfp-rounding-mode=d

will match *all* versions of gcc.

- Volodya

_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: When can we retire V1

Victor A. Wagner Jr.
In reply to this post by Vladimir Prus
At 00:16 2006-01-13, Vladimir Prus wrote:

>David Abrahams wrote:
>
> >
> > Happy New Year, everyone!
>
>Happy New Year!
>
> >
> > It's a brand new year; Boost should switch to a "brand new" build
> > system, ASAP.  How close are we to being able to make that switch?
>
>Good question. The absolutely fair answer is that we don't know until we
>try. I can get the ball rolling, but we really need to decide on the steps
>to be made, and work on them together to push this to completion. Here are
>the steps that I'd propose:
>
>1. I set up a script that will run all Boost regressions with V1 and V2 and
>compare results, and adjust V2 Jamfiles to get zero differences on
>Linux/gcc.
>
>2. Somebody else with Linux/gcc run the same script to verify the results
>are the same for him too.
>
>3. Somebody with Windows/msvc compares V1 and V2 results too, coordinating
>with me to get them equal.

I volunteer for 7.1 and 8.0 (I also suggest we "drop" any msvc <7.1,
but I think everyone already knows that)


>4. We adjust the regression.py script to have "--v2" switch and ask some of
>the current regression runners to test it.
>
>5. We post to Boost mailing list, explaining that we're technically ready to
>move to V2, and if anybody has any arguments against.
>
>6. Regression runners switch to V2 and "bjam" in Boost starts to use V2 by
>default, with V1 invoked by "--v1" option.
>
>7. Any issues are ironed out.
>
>
>There are two issues that are likely to arise along the way:
>1. I still haven't tried to port serialization tests to V2, and they are
>pretty contrived.
>
>2. The auto-configuration of toolsets works with msvc only, so we need to
>add auto-configuration to gcc, at least.
>
>
>- Volodya
>
>
>
>
>_______________________________________________
>Boost-build mailing list
>[hidden email]
>http://lists.boost.org/mailman/listinfo.cgi/boost-build

Victor A. Wagner Jr.      http://rudbek.com
The five most dangerous words in the English language:
               "There oughta be a law"

_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: When can we retire V1

Vladimir Prus
Hi Victor,

> >3. Somebody with Windows/msvc compares V1 and V2 results too, coordinating
> >with me to get them equal.
>
> I volunteer for 7.1 and 8.0

Thank you! I'll then continue with getting test result in shape on Linux and
will announce when wider testing is needed.

> (I also suggest we "drop" any msvc <7.1,
> but I think everyone already knows that)

Yes ;-) Luckily, that's a separate issue.

While we're at it, can you look into Boost.Build V2 tests that you used to
run? I attach a prior email describing the problems I see.

Thanks!

- Volodya


Hi Victor,
I'm looking at ftp://rudbek.com/pub/boost/bjamv2.log,
and it seems like it's out of date (2005-09-17) , and there are some
configuration problems in the test result
   - even for msvc-7.1 tests, gcc is used. Maybe, "msvc-7.1" is not
     passed to the "test_all.py" script?
   - V2 reports that no toolsets are configured, which suggests you
     probably have nothing in your user-config.jam

If you have a bit of time to revive the tests, that would be great. I'm hoping
to have a new release, and testing on primary platform such as msvc is very
desirable.

Thanks,
Volodya

_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Regression tests configuration (Was: When can we retire V1)

Vladimir Prus
In reply to this post by Martin Wille
Hi Martin,

> Markus Schöpflin wrote:
> > 2. I use customized tool sets for all of my regression runs. For V1, one
> > such file looks like this:
> >
> > {
> >      extends-toolset tru64cxx65 ;
> >
> >      flags tru64cxx65 CFLAGS : -version V6.5-042 -ieee ;
> >      flags tru64cxx65 LINKFLAGS : -version V6.5-042 -ieee ;
> > }
>
> Same here. A reasonably idiot-proof transition guide for the testers
> would be helpful (at least in my case). That guide must not require
> putting files into the runners home directory since that would interfere
> with other boost-related activities.

Can you tell where do you place your customized files at the moment, with V1.
Do you place it to some directory that's in BOOST_BUILD_PATH? Or something
else.

Thanks,
Volodya

_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build