You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@stdcxx.apache.org by fa...@apache.org on 2007/11/22 13:40:35 UTC
svn commit: r597396 -
/incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp
Author: faridz
Date: Thu Nov 22 04:40:33 2007
New Revision: 597396
URL: http://svn.apache.org/viewvc?rev=597396&view=rev
Log:
2007-11-22 Farid Zaripov <fa...@epam.com>
* 26.valarray.cassign.cpp (run_test): Corrected condition in preprocessor directive.
Modified:
incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp
Modified: incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp
URL: http://svn.apache.org/viewvc/incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp?rev=597396&r1=597395&r2=597396&view=diff
==============================================================================
--- incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp (original)
+++ incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp Thu Nov 22 04:40:33 2007
@@ -805,7 +805,7 @@
TEST (int);
TEST (double);
-#if 0x04020000 <= _RWSTD_VER
+#if 0x04020000 >= _RWSTD_VER
// test fails to compile with stdcxx 4.2.0 and prior due to
// STDCXX-512: http://issues.apache.org/jira/browse/STDCXX-512
RE: _RWSTD_VER value on trunk
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Wednesday, December 19, 2007 7:17 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: _RWSTD_VER value on trunk
>
I like the idea to #define _RWSTD_VER macro in config.h.
This solution will helps in the implementing the STDCXX-610 issue
(#include <config.h> instead of a bit complex <rw/_defs.h>).
Also I'd like to #define _RWSHARED there, because at the moment
the user should explicitly #define this macro in user's project settings
(like as the build infrastructure defines this macro when building the
examples and tests in shared builds).
Actually _RWSHARED is required only on Windows, and we can
avoid this macro if we will check the __declspec(dllexport/dllimport)
at the configure step (the DLL_EXPORT.cpp test from
https://issues.apache.org/jira/secure/attachment/12371951/dllexport.patc
h
will fail in static builds).
And, possibly, the _RWSTDDEBUG. Because what the sence to
link the some project, compiled without _RWSTDDEBUG #defined,
with the library, built with _RWSTDDEBUG #defined? And vice versa.
Farid.
Re: _RWSTD_VER value on trunk
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
> Martin Sebor wrote:
>> Travis Vitek wrote:
>>>
>>> Martin Sebor wrote:
>>>> This has been bugging me -- when someone checks out trunk, does a build
>>>> and sends
>>>> us build results, we have no way of telling that the build results are,
>>>> in
>>>> fact, for trunk and
>>>> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is
>>>> the same. I
>>>> think we should change it so that the value is unique for each branch,
>>>> or
>>>> at least distinct
>>>> from any release.
>>>>
>>>> Any suggestions for what would be a good value?
>>>>
>>> Martin,
>>>
>>> If all you care about is detecting what branch the results are for, why
>>> can't we just dump $HeadURL$ of the GNUmakefile to the top of the build
>>> results?
>> Yes, I think that's what Mark meant. I like the idea I just wasn't
>> sure I wasn't missing some downside since we'd be taking the macro
>> out of $TOPDIR/include/rw/_config.h and moving it to the generated
>> config header in $BUILDDIR. I.e., it won't be possible to grep for
>> the macro in the freshly downloaded/extracted sources to find the
>> version -- see my comments below:
>> http://www.nabble.com/Re%3A-_RWSTD_VER-value-on-trunk-p14340222.html
>>
>> But unless someone does come up with a problem I'll go ahead and
>> cook up something along these lines.
>>
>> Martin
>>
>
> I think you are taking this a bit further than I am talking about. In your
> original post you say we don't really have no way to tell which branch the
> user did their build from. I'm saying just add a target to the GNUmakefile
> that dumps the expanded $HeadURL$ string, and then use it in the build
> process.
We also need to #define the _RWSTD_VER macro so that users can use it
in preprocessor conditionals. But the idea is essentially the same:
GNUmakefile.cfg would take the value of $HeadURL$, extract the part
that contains the version if it's there or "trunk," and append the
result to the generate config.h in the form of a couple of macro
#definitions, one for _RWSTD_VER and one for _RWSTD_VER_STR (in
addition to using it in the name of the [shared] library). Or is
this not what you're talking about?
>
> It sounds like you are trying to establish a strict mapping between the
> library version and where the sources are kept in subversion.
That's right. The version reported by a checkout of branches/4.2.x
would be "4.2.x" (and _RWSTD_VER & 0xff00 would have to be something
like 0xff00, to borrow Andrew's convention). Which would reinforce
the guideline that a branch should never be released (tags are).
The version reported by a checkout of tags/4.2.1 would be 4.2.1.
> What do other
> subversion projects do about this?
Good question! Let's find out. I know gcc uses macros defined in
its makefiles but I don't know how the macro values are derived.
>
> It seems that this wouldn't be a problem if we had a 4.2.1 branch and we
> could 'encourage' users to leave the intermediate branches [the ones used
> for merging] alone.
Exactly. Except it's not called a branch but a tag.
Martin
Re: _RWSTD_VER value on trunk
Posted by Travis Vitek <vi...@roguewave.com>.
Martin Sebor wrote:
>
> Travis Vitek wrote:
>>
>>
>> Martin Sebor wrote:
>>> This has been bugging me -- when someone checks out trunk, does a build
>>> and sends
>>> us build results, we have no way of telling that the build results are,
>>> in
>>> fact, for trunk and
>>> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is
>>> the same. I
>>> think we should change it so that the value is unique for each branch,
>>> or
>>> at least distinct
>>> from any release.
>>>
>>> Any suggestions for what would be a good value?
>>>
>>
>> Martin,
>>
>> If all you care about is detecting what branch the results are for, why
>> can't we just dump $HeadURL$ of the GNUmakefile to the top of the build
>> results?
>
> Yes, I think that's what Mark meant. I like the idea I just wasn't
> sure I wasn't missing some downside since we'd be taking the macro
> out of $TOPDIR/include/rw/_config.h and moving it to the generated
> config header in $BUILDDIR. I.e., it won't be possible to grep for
> the macro in the freshly downloaded/extracted sources to find the
> version -- see my comments below:
> http://www.nabble.com/Re%3A-_RWSTD_VER-value-on-trunk-p14340222.html
>
> But unless someone does come up with a problem I'll go ahead and
> cook up something along these lines.
>
> Martin
>
I think you are taking this a bit further than I am talking about. In your
original post you say we don't really have no way to tell which branch the
user did their build from. I'm saying just add a target to the GNUmakefile
that dumps the expanded $HeadURL$ string, and then use it in the build
process.
It sounds like you are trying to establish a strict mapping between the
library version and where the sources are kept in subversion. What do other
subversion projects do about this?
It seems that this wouldn't be a problem if we had a 4.2.1 branch and we
could 'encourage' users to leave the intermediate branches [the ones used
for merging] alone.
Travis
--
View this message in context: http://www.nabble.com/Re%3A-svn-commit%3A-r597396----incubator-stdcxx-branches-4.2.x-tests-numerics-26.valarray.cassign.cpp-tp13905517p14410574.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: _RWSTD_VER value on trunk
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
> Martin Sebor wrote:
>> This has been bugging me -- when someone checks out trunk, does a build
>> and sends
>> us build results, we have no way of telling that the build results are, in
>> fact, for trunk and
>> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is
>> the same. I
>> think we should change it so that the value is unique for each branch, or
>> at least distinct
>> from any release.
>>
>> Any suggestions for what would be a good value?
>>
>
> Martin,
>
> If all you care about is detecting what branch the results are for, why
> can't we just dump $HeadURL$ of the GNUmakefile to the top of the build
> results?
Yes, I think that's what Mark meant. I like the idea I just wasn't
sure I wasn't missing some downside since we'd be taking the macro
out of $TOPDIR/include/rw/_config.h and moving it to the generated
config header in $BUILDDIR. I.e., it won't be possible to grep for
the macro in the freshly downloaded/extracted sources to find the
version -- see my comments below:
http://www.nabble.com/Re%3A-_RWSTD_VER-value-on-trunk-p14340222.html
But unless someone does come up with a problem I'll go ahead and
cook up something along these lines.
Martin
Re: _RWSTD_VER value on trunk (was: Re: svn commit: r597396 -
/incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp)
Posted by Travis Vitek <vi...@roguewave.com>.
Martin Sebor wrote:
>
> This has been bugging me -- when someone checks out trunk, does a build
> and sends
> us build results, we have no way of telling that the build results are, in
> fact, for trunk and
> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is
> the same. I
> think we should change it so that the value is unique for each branch, or
> at least distinct
> from any release.
>
> Any suggestions for what would be a good value?
>
Martin,
If all you care about is detecting what branch the results are for, why
can't we just dump $HeadURL$ of the GNUmakefile to the top of the build
results?
Travis
--
View this message in context: http://www.nabble.com/Re%3A-svn-commit%3A-r597396----incubator-stdcxx-branches-4.2.x-tests-numerics-26.valarray.cassign.cpp-tp13905517p14408307.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: _RWSTD_VER value on trunk
Posted by Martin Sebor <se...@roguewave.com>.
Mark Brown wrote:
> Have you considered what it's going to mean for merges between branches?
I confess I had not. What is it going to mean? (That we might
inadvertently overwrite the hardcoded value as we merge changes
from a branch to trunk or between two branches?)
> Wouldn't letting the Makefile figure out the version from the pathname of one
> of the files be more reliable? If Subversion is like CVS and understands the
> $Source$ keyword you could even use it.
AFAICT from the manual, Subversion doesn't support the $Source$
keyword. It does have something similar, though: $HeadURL$ which
expands to "the full URL to the latest version of the file in the
repository:"
http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.advanced.props.special.keywords
If I understand correctly what you're suggesting, we could use it
in GNUMakefile.cfg to extract the name of the branch (or trunk)
and #define _RWSTD_VER in the generated config header. This would
(obviously) imply that we would need to remove the macro from the
library sources, and also that there would be no way to tell the
version of the library by simply grepping for the value of the
macro in the headers. One would either need to configure the
library first, or extract it from the name of $TOPDIR. For
maintenance branches like 4.2.x, we would also lose the ability
to #define _RWSTD_VER to the next version (e.g., 4.2.1, as it
is now). But we'd lose this ability if we were to adopt Andrew's
scheme as well.
I very much like the idea of storing the version in just one place
(i.e., the branch name) and automatically extracting it from there
but I'm not 100% sure I understand all the ramifications of this
solution to be completely sold on it yet.
What do others think? Does anyone see any significant downsides
to Mark's idea?
Martin
>
> -- Mark
>
> On Dec 13, 2007 2:24 PM, Martin Sebor <se...@roguewave.com> wrote:
>> Andrew Black wrote:
>>> Martin Sebor wrote:
>>>> This has been bugging me -- when someone checks out trunk, does a build and
>>>> sends
>>>> us build results, we have no way of telling that the build results are, in
>>>> fact, for trunk and
>>>> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is the
>>>> same. I
>>>> think we should change it so that the value is unique for each branch, or at
>>>> least distinct
>>>> from any release.
>>>>
>>>> Any suggestions for what would be a good value?
>>> The following is my suggestion for a scheme for _RWSTD_VER:
>>> Trunk: 0xFFFFFFFF
>>> Trunk feature branch: 0xFFFFFFxx
>>> Major branch: 0xMMFF0000
>>> Maintenance branch: 0xMMmmFF00
>> Thanks, this is an interesting idea that I hadn't thought of.
>> At first I didn't think 0xFF made sense but I'm slowly starting
>> to warm up to it.
>>
>>> A trunk feature branch is a branch in subversion used for developing a
>>> specific feature, which isn't ready for inclusion in trunk, but is major
>>> enough that incremental testing is required. An example could be the
>>> implementation of concepts. The placeholder 'xx' is a non-FF value,
>>> unique to a feature branch. If the number of feature branches exceeds
>>> 255, it will be necessary to reuse numbers, but this isn't a likely
>>> occurrence in the near term. These numbers should be issued in the
>>> order the branches are created.
>> We'd have to find a way to avoid conflicts. I.e., How would one go
>> about finding the next available value of xx to grab for their new
>> feature branch? (It wouldn't be too hard to do today but if we had
>> as many feature branches as gcc, as unlikely as it is, it could be
>> a challenge.)
>>
>>> A major branch is a branch in subversion used for ongoing development of
>>> a source compatible lineage. The placeholder MM represents the major
>>> version. An example would be ongoing maintenance of the 4.x version of
>>> stdcxx beyond 4.3, after the 5.0 release has been made. In the case of
>>> a 4.x maintenance branch, the version would be 0x04FF0000
>> Makes sense.
>>
>>> Maintenance branches are an established concept, with the 4.2.x branch
>>> being an example. The placeholder MM represents the major version, with
>>> the placeholder mm representing the minor version. In the case of
>>> 4.2.x, the version would be 0x0402FF00.
>> Same here.
>>
>>> Justification:
>>> My primary reason for using the 0xFF value as a placeholder (generally)
>>> is because it is greater than any particular released version number.
>>> This should allow checks which look for a specific version of the
>>> library (either older or newer) to function correctly. If someone
>>> wanted to exclude the trunk from these checks, it would be possible to
>>> simply perform a bitwise negation, and if the value of that negation is
>>> 0, it means the token references a trunk version.
>> I think I like this idea quite a bit, actually Using a fixed value
>> also makes it easy to test for it in release scripts and catch
>> releases where the macro isn't set correctly (because the value
>> would either be 0xFF or fail to match the version in the name of
>> the tag).
>>
>> Is everyone else happy with this scheme?
>>
>> Martin
>>
Re: _RWSTD_VER value on trunk
Posted by Mark Brown <ma...@gmail.com>.
Have you considered what it's going to mean for merges between branches?
Wouldn't letting the Makefile figure out the version from the pathname of one
of the files be more reliable? If Subversion is like CVS and understands the
$Source$ keyword you could even use it.
-- Mark
On Dec 13, 2007 2:24 PM, Martin Sebor <se...@roguewave.com> wrote:
> Andrew Black wrote:
> > Martin Sebor wrote:
> >> This has been bugging me -- when someone checks out trunk, does a build and
> >> sends
> >> us build results, we have no way of telling that the build results are, in
> >> fact, for trunk and
> >> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is the
> >> same. I
> >> think we should change it so that the value is unique for each branch, or at
> >> least distinct
> >> from any release.
> >>
> >> Any suggestions for what would be a good value?
> >
> > The following is my suggestion for a scheme for _RWSTD_VER:
> > Trunk: 0xFFFFFFFF
> > Trunk feature branch: 0xFFFFFFxx
> > Major branch: 0xMMFF0000
> > Maintenance branch: 0xMMmmFF00
>
> Thanks, this is an interesting idea that I hadn't thought of.
> At first I didn't think 0xFF made sense but I'm slowly starting
> to warm up to it.
>
> >
> > A trunk feature branch is a branch in subversion used for developing a
> > specific feature, which isn't ready for inclusion in trunk, but is major
> > enough that incremental testing is required. An example could be the
> > implementation of concepts. The placeholder 'xx' is a non-FF value,
> > unique to a feature branch. If the number of feature branches exceeds
> > 255, it will be necessary to reuse numbers, but this isn't a likely
> > occurrence in the near term. These numbers should be issued in the
> > order the branches are created.
>
> We'd have to find a way to avoid conflicts. I.e., How would one go
> about finding the next available value of xx to grab for their new
> feature branch? (It wouldn't be too hard to do today but if we had
> as many feature branches as gcc, as unlikely as it is, it could be
> a challenge.)
>
> >
> > A major branch is a branch in subversion used for ongoing development of
> > a source compatible lineage. The placeholder MM represents the major
> > version. An example would be ongoing maintenance of the 4.x version of
> > stdcxx beyond 4.3, after the 5.0 release has been made. In the case of
> > a 4.x maintenance branch, the version would be 0x04FF0000
>
> Makes sense.
>
> >
> > Maintenance branches are an established concept, with the 4.2.x branch
> > being an example. The placeholder MM represents the major version, with
> > the placeholder mm representing the minor version. In the case of
> > 4.2.x, the version would be 0x0402FF00.
>
> Same here.
>
> >
> > Justification:
> > My primary reason for using the 0xFF value as a placeholder (generally)
> > is because it is greater than any particular released version number.
> > This should allow checks which look for a specific version of the
> > library (either older or newer) to function correctly. If someone
> > wanted to exclude the trunk from these checks, it would be possible to
> > simply perform a bitwise negation, and if the value of that negation is
> > 0, it means the token references a trunk version.
>
> I think I like this idea quite a bit, actually Using a fixed value
> also makes it easy to test for it in release scripts and catch
> releases where the macro isn't set correctly (because the value
> would either be 0xFF or fail to match the version in the name of
> the tag).
>
> Is everyone else happy with this scheme?
>
> Martin
>
Re: _RWSTD_VER value on trunk
Posted by Martin Sebor <se...@roguewave.com>.
Andrew Black wrote:
> Martin Sebor wrote:
>> This has been bugging me -- when someone checks out trunk, does a build and
>> sends
>> us build results, we have no way of telling that the build results are, in
>> fact, for trunk and
>> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is the
>> same. I
>> think we should change it so that the value is unique for each branch, or at
>> least distinct
>> from any release.
>>
>> Any suggestions for what would be a good value?
>
> The following is my suggestion for a scheme for _RWSTD_VER:
> Trunk: 0xFFFFFFFF
> Trunk feature branch: 0xFFFFFFxx
> Major branch: 0xMMFF0000
> Maintenance branch: 0xMMmmFF00
Thanks, this is an interesting idea that I hadn't thought of.
At first I didn't think 0xFF made sense but I'm slowly starting
to warm up to it.
>
> A trunk feature branch is a branch in subversion used for developing a
> specific feature, which isn't ready for inclusion in trunk, but is major
> enough that incremental testing is required. An example could be the
> implementation of concepts. The placeholder 'xx' is a non-FF value,
> unique to a feature branch. If the number of feature branches exceeds
> 255, it will be necessary to reuse numbers, but this isn't a likely
> occurrence in the near term. These numbers should be issued in the
> order the branches are created.
We'd have to find a way to avoid conflicts. I.e., How would one go
about finding the next available value of xx to grab for their new
feature branch? (It wouldn't be too hard to do today but if we had
as many feature branches as gcc, as unlikely as it is, it could be
a challenge.)
>
> A major branch is a branch in subversion used for ongoing development of
> a source compatible lineage. The placeholder MM represents the major
> version. An example would be ongoing maintenance of the 4.x version of
> stdcxx beyond 4.3, after the 5.0 release has been made. In the case of
> a 4.x maintenance branch, the version would be 0x04FF0000
Makes sense.
>
> Maintenance branches are an established concept, with the 4.2.x branch
> being an example. The placeholder MM represents the major version, with
> the placeholder mm representing the minor version. In the case of
> 4.2.x, the version would be 0x0402FF00.
Same here.
>
> Justification:
> My primary reason for using the 0xFF value as a placeholder (generally)
> is because it is greater than any particular released version number.
> This should allow checks which look for a specific version of the
> library (either older or newer) to function correctly. If someone
> wanted to exclude the trunk from these checks, it would be possible to
> simply perform a bitwise negation, and if the value of that negation is
> 0, it means the token references a trunk version.
I think I like this idea quite a bit, actually Using a fixed value
also makes it easy to test for it in release scripts and catch
releases where the macro isn't set correctly (because the value
would either be 0xFF or fail to match the version in the name of
the tag).
Is everyone else happy with this scheme?
Martin
Re: _RWSTD_VER value on trunk
Posted by Andrew Black <ab...@roguewave.com>.
Martin Sebor wrote:
> This has been bugging me -- when someone checks out trunk, does a build and
> sends
> us build results, we have no way of telling that the build results are, in
> fact, for trunk and
> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is the
> same. I
> think we should change it so that the value is unique for each branch, or at
> least distinct
> from any release.
>
> Any suggestions for what would be a good value?
The following is my suggestion for a scheme for _RWSTD_VER:
Trunk: 0xFFFFFFFF
Trunk feature branch: 0xFFFFFFxx
Major branch: 0xMMFF0000
Maintenance branch: 0xMMmmFF00
A trunk feature branch is a branch in subversion used for developing a
specific feature, which isn't ready for inclusion in trunk, but is major
enough that incremental testing is required. An example could be the
implementation of concepts. The placeholder 'xx' is a non-FF value,
unique to a feature branch. If the number of feature branches exceeds
255, it will be necessary to reuse numbers, but this isn't a likely
occurrence in the near term. These numbers should be issued in the
order the branches are created.
A major branch is a branch in subversion used for ongoing development of
a source compatible lineage. The placeholder MM represents the major
version. An example would be ongoing maintenance of the 4.x version of
stdcxx beyond 4.3, after the 5.0 release has been made. In the case of
a 4.x maintenance branch, the version would be 0x04FF0000
Maintenance branches are an established concept, with the 4.2.x branch
being an example. The placeholder MM represents the major version, with
the placeholder mm representing the minor version. In the case of
4.2.x, the version would be 0x0402FF00.
Justification:
My primary reason for using the 0xFF value as a placeholder (generally)
is because it is greater than any particular released version number.
This should allow checks which look for a specific version of the
library (either older or newer) to function correctly. If someone
wanted to exclude the trunk from these checks, it would be possible to
simply perform a bitwise negation, and if the value of that negation is
0, it means the token references a trunk version.
--Andrew Black
_RWSTD_VER value on trunk (was: Re: svn commit: r597396 -
/incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp)
Posted by Martin Sebor <se...@roguewave.com>.
This has been bugging me -- when someone checks out trunk, does a build and
sends
us build results, we have no way of telling that the build results are, in
fact, for trunk and
not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is the
same. I
think we should change it so that the value is unique for each branch, or at
least distinct
from any release.
Any suggestions for what would be a good value?
Martin Sebor wrote:
>
> faridz@apache.org wrote:
>> Author: faridz
>> Date: Thu Nov 22 04:40:33 2007
>> New Revision: 597396
>>
>> URL: http://svn.apache.org/viewvc?rev=597396&view=rev
>> Log:
>> 2007-11-22 Farid Zaripov <fa...@epam.com>
>>
>> * 26.valarray.cassign.cpp (run_test): Corrected condition in
>> preprocessor directive.
>
> Good catch, thanks!
>
> We should probably bump up _RWSTD_VER on trunk. To what, though?
>
> It might also be a good idea to always set the macro so that it can't
> match that of any branch. Any ideas how to do that?
>
> Martin
>
>>
>> Modified:
>>
>> incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp
>>
>> Modified:
>> incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp
>> URL:
>> http://svn.apache.org/viewvc/incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp?rev=597396&r1=597395&r2=597396&view=diff
>> ==============================================================================
>> ---
>> incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp
>> (original)
>> +++
>> incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp
>> Thu Nov 22 04:40:33 2007
>> @@ -805,7 +805,7 @@
>> TEST (int);
>> TEST (double);
>>
>> -#if 0x04020000 <= _RWSTD_VER
>> +#if 0x04020000 >= _RWSTD_VER
>>
>> // test fails to compile with stdcxx 4.2.0 and prior due to
>> // STDCXX-512: http://issues.apache.org/jira/browse/STDCXX-512
>>
>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/Re%3A-svn-commit%3A-r597396----incubator-stdcxx-branches-4.2.x-tests-numerics-26.valarray.cassign.cpp-tp13905517p14289920.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: svn commit: r597396 - /incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp
Posted by Martin Sebor <se...@roguewave.com>.
faridz@apache.org wrote:
> Author: faridz
> Date: Thu Nov 22 04:40:33 2007
> New Revision: 597396
>
> URL: http://svn.apache.org/viewvc?rev=597396&view=rev
> Log:
> 2007-11-22 Farid Zaripov <fa...@epam.com>
>
> * 26.valarray.cassign.cpp (run_test): Corrected condition in preprocessor directive.
Good catch, thanks!
We should probably bump up _RWSTD_VER on trunk. To what, though?
It might also be a good idea to always set the macro so that it can't
match that of any branch. Any ideas how to do that?
Martin
>
> Modified:
> incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp
>
> Modified: incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp
> URL: http://svn.apache.org/viewvc/incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp?rev=597396&r1=597395&r2=597396&view=diff
> ==============================================================================
> --- incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp (original)
> +++ incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp Thu Nov 22 04:40:33 2007
> @@ -805,7 +805,7 @@
> TEST (int);
> TEST (double);
>
> -#if 0x04020000 <= _RWSTD_VER
> +#if 0x04020000 >= _RWSTD_VER
>
> // test fails to compile with stdcxx 4.2.0 and prior due to
> // STDCXX-512: http://issues.apache.org/jira/browse/STDCXX-512
>
>
>