"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> --- David Abrahams <[EMAIL PROTECTED]> wrote:
>> Seems to me a special version of the code for
>>
>> BOOST_WORKAROUND(__GNUC__, == 2 && __GNUC_MINOR__ == 96)
>>
>> is in order.
>
> We know that the special code works with 2.95.3 (ac
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> Seems to me a special version of the code for
>
> BOOST_WORKAROUND(__GNUC__, == 2 && __GNUC_MINOR__ == 96)
>
> is in order.
We know that the special code works with 2.95.3 (according to Gottfried), so
I've made this:
# elif BOOST_WORKAROUND
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> --- "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote:
>> I've checked in the patch and we will restart the tests as soon as the
>> Sourceforge server is cooperating.
>
> This patch breaks the Tru64/cxx and IRIX/CC (MIPSpro) compilations
--- "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote:
> I've checked in the patch and we will restart the tests as soon as the
> Sourceforge server is cooperating.
This patch breaks the Tru64/cxx and IRIX/CC (MIPSpro) compilations :-(
tru64cxx65-C++-action
../../../libs/python/test/bin/opaque
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> OK, checked into RC_1_30_0. I don't have vc7.1. Could someone please try it
> out?
The opaque test works on 7.1 now. I'm running all the other tests,
but you should assume they work unless I say otherwise.
--
Dave Abrahams
Boost Consulti
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> should be:
>
>
> # if BOOST_WORKAROUND(BOOST_MSVC, <= 1300)
> // MSC works without this workaround, but needs another one ...
> -# define BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(Pointee) \
> +# define BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(Pointe
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> --- David Abrahams <[EMAIL PROTECTED]> wrote:
>> > Beman, here is an idea: I could check in the patch now and restart our
>> > multi-platform Boost.Python regression tests. When we hear back from David
>> we
>> > have the results already. Th
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> > Beman, here is an idea: I could check in the patch now and restart our
> > multi-platform Boost.Python regression tests. When we hear back from David
> we
> > have the results already. Then we can decide what to do based on all the
> > information t
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> I have the patch ready to go and it fixes the gcc 2.96 problem. However, I am
> in limbo because I am waiting for a word from David. I don't think his concern
> above is valid, but I am not certain.
I'd like to know why you don't think it's
--- Beman Dawes <[EMAIL PROTECTED]> wrote:
> At 09:48 AM 3/18/2003, David Abrahams wrote:
>
> >[EMAIL PROTECTED] writes:
> >
> >>> it seems to me that these aren't actually legal specializations
> >>> (though I've never specialized functions before so I could be wrong).
> >>> Shouldn't that b
Beman Dawes <[EMAIL PROTECTED]> writes:
> >Beman, can we get this in under the wire? It only affects
> >Boost.Python and then only a new feature of Boost.Python.
>
> Yes, if it is ready in the next couple of hours. Please let me know
> when it is committed.
OK, this is up to Ralf and Gottfried
Thomas Witt <[EMAIL PROTECTED]> writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> David Abrahams wrote:
> | [EMAIL PROTECTED] writes:
> |
> | I think we need to keep the argument for VC6 at least; the problem is
> | one that shows up at link time because VC6 seems to distinguish
> | fu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Abrahams wrote:
| [EMAIL PROTECTED] writes:
|
| I think we need to keep the argument for VC6 at least; the problem is
| one that shows up at link time because VC6 seems to distinguish
| function template instantiations only by the types of the arg
[EMAIL PROTECTED] writes:
>> it seems to me that these aren't actually legal specializations
>> (though I've never specialized functions before so I could be wrong).
>> Shouldn't that be:
>>
>> template <>
>> inline type_info type_id(boost::type*) {
>> return type_info(typeid(Poin
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
>
> > That change does not seem to make a difference. The compiler errors are
> still
> > exactly the same.
>
> Does 2.96 want the default argument (=0) to be repeated?
Is this what you mean?
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> That change does not seem to make a difference. The compiler errors are still
> exactly the same.
Does 2.96 want the default argument (=0) to be repeated?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
>
> > There are gcc 2.96 (Redhat 7.3) compilation error for
> > boost/libs/python/test/opaque.cpp:
> >
> > http://cci.lbl.gov/~rwgk/tmp/rc_1_30_0_opaque_fail.txt
> >
> > More recent gcc's don't s
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> There are gcc 2.96 (Redhat 7.3) compilation error for
> boost/libs/python/test/opaque.cpp:
>
> http://cci.lbl.gov/~rwgk/tmp/rc_1_30_0_opaque_fail.txt
>
> More recent gcc's don't seems to suffer from this problem.
> I am not sure this is impo
18 matches
Mail list logo
