pyste, gccxml and boost ublas, random number generator etc
Hi, Has anybody used pyste to expose C++ code that contained boost code from the random number generator libraries, ublas, shared_ptr? It seems when pyste compiles my code the gccxml cannot compile the libraries. I think this happens because the boost libraries that I have in windows are setup to compile with VC 7.1 and gccxml is based on another compiler so compiling the templates gets messed up. Example of compiler errors are: C:\Development\PyStatATA>pyste.py --module=PyStatATA -I c:\opt\Bayes++ -I ..\Sta tATA -I c:\usr\local\include -I C:\Boost\include\boost-1_32 -I C:\opt\newmat ..\ StatATA\pystatata.pyste In file included from C:/Boost/include/boost-1_32/boost/numeric/ublas/config.hpp :29, from C:/Boost/include/boost-1_32/boost/numeric/ublas/vector.hpp :22, from c:/opt/Bayes++/BayesFilter/matSupSub.hpp:41, from c:/opt/Bayes++/BayesFilter/bayesFlt.hpp:21, from c:/opt/Bayes++/BayesFilter/UDFlt.hpp:28, from c:/opt/Bayes++/BayesFilter/allFilters.hpp:19: C:/Boost/include/boost-1_32/boost/mpl/and.hpp:32:13: operator "defined" requires an identifier C:/Boost/include/boost-1_32/boost/mpl/and.hpp:32:13: ("and" is an alternative to ken for "&&" in C++) C:/Boost/include/boost-1_32/boost/mpl/and.hpp:32:16: missing '(' in expression C:/Boost/include/boost-1_32/boost/mpl/and.hpp:43:13: operator "defined" requires an identifier C:/Boost/include/boost-1_32/boost/mpl/and.hpp:43:13: ("and" is an alternative to ken for "&&" in C++) C:/Boost/include/boost-1_32/boost/mpl/and.hpp:43:16: missing '(' in expression In file included from C:/Boost/include/boost-1_32/boost/numeric/ublas/returntype _deduction.hpp:15, from C:/Boost/include/boost-1_32/boost/numeric/ublas/traits.hpp :27, from C:/Boost/include/boost-1_32/boost/numeric/ublas/storage.hp p:29, from C:/Boost/include/boost-1_32/boost/numeric/ublas/vector.hpp :23, from c:/opt/Bayes++/BayesFilter/matSupSub.hpp:41, from c:/opt/Bayes++/BayesFilter/bayesFlt.hpp:21, from c:/opt/Bayes++/BayesFilter/UDFlt.hpp:28, from c:/opt/Bayes++/BayesFilter/allFilters.hpp:19: C:/Boost/include/boost-1_32/boost/mpl/or.hpp:33:13: operator "defined" requires ... In file included from C:/Boost/include/boost-1_32/boost/random/linear_congruential.hpp:25, from C:/Boost/include/boost-1_32/boost/random.hpp:36, from ../StatATA/random_number_generator.h:6: C:/Boost/include/boost-1_32/boost/random/detail/const_mod.hpp: In static member function `static IntType boost::random::const_mod<IntType, m>::invert_euclidian(IntType)': C:/Boost/include/boost-1_32/boost/random/detail/const_mod.hpp:152: error: conflicting types for `typedef struct boost::static_assert_test<sizeof (boost::STATIC_ASSERTION_FAILURE<(bool)(boost::integer_traits<T>::is_signed)>)> boost_static_assert_typedef___COUNTER__' C:/Boost/include/boost-1_32/boost/random/detail/const_mod.hpp:148: error: previous declaration as `typedef struct boost::static_assert_test<sizeof (boost::STATIC_ASSERTION_FAILURE<(bool)((m > 0))>)> ... C:/Boost/include/boost-1_32/boost/shared_ptr.hpp:247: error: invalid conversion from `void*' to `const char*' ... The guys from gccxml think it's because they define their compiler as __GCCXML__ and boost doesn't recognize this. Has anybody run into this? Thanks, Alexis Programming Tutorial: In Python: To do this, do this In Perl: To do this, do this or this or this or this... In C: To do this, do this, but be careful In C++: To do this, do this, but don't do this, be careful of this, watch out for this, and whatever you do, don't do this __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi Alexis, Alexis H. Rivera-Rios wrote:
It seems when pyste compiles my code the gccxml cannot compile the libraries. I think this happens because the boost libraries that I have in windows are setup to compile with VC 7.1 and gccxml is based on another compiler so compiling the templates gets messed up.
I always had the same problem, and unfortunatelly it seems there is nothing you can do about it. :( That's the problem mentioned by Petrucio in another thread: standard headers and even boost itself upset GCCXML on Windows. One solution would be to generate your bindings on Linux, and them compile them on windows (that seems to work fine, at least in simple cases). Another option would be to get your headers "clean", only with the code to wrap, but that may be harder to accomplish, specially if you're wrapping a 3rd party library. Best Regards, Nicodemus.
Nicodemus wrote:
That's the problem mentioned by Petrucio in another thread: standard headers and even boost itself upset GCCXML on Windows.
Could anybody with gccxml and windows experience detail the problem a bit ? While I plan to look into a new synopsis-based pyste frontend, I don't quite understand the problem, as the compiler emulation code synopsis uses was to a certain degree inspired by gccxml, and so I would assume that gccxml does the right thing, no matter the platform. Thanks, Stefan
Stefan Seefeld wrote:
Could anybody with gccxml and windows experience detail the problem a bit ? While I plan to look into a new synopsis-based pyste frontend, I don't quite understand the problem, as the compiler emulation code synopsis uses was to a certain degree inspired by gccxml, and so I would assume that gccxml does the right thing, no matter the platform.
I will quote Brad King, the creator of GCCXML, from the gccxml list in a thread regarding this problem (hope he does not mind): "As I said the GCC parser cannot always handle the results of preprocessing as if using VC7.1. In the case of system headers the GCC-XML installation copies and patches them to fix the problems. In this case all the VC-specific hacks in boost are confusing GCC-XML." Hopefully Brad can shed some more light in a possible workaround. :) Best Regards, Nicodemus.
Nicodemus wrote:
I will quote Brad King, the creator of GCCXML, from the gccxml list in a thread regarding this problem (hope he does not mind):
"As I said the GCC parser cannot always handle the results of preprocessing as if using VC7.1. In the case of system headers the GCC-XML installation copies and patches them to fix the problems. In this case all the VC-specific hacks in boost are confusing GCC-XML."
Hopefully Brad can shed some more light in a possible workaround. :)
I can indeed see the problem if you preprocess for CV++ and are then exposed to non-standard extensions during the parsing. While gcc packages contain system headers / wrappers to solve this, the above suggests that gccxml itself does not, i.e. it is assuming a sane and sufficiently standard-conformant development environment. Is that right ? I did adjust the synopsis parser to handle some of the VC++ specific extensions, and I expect boost in general to be parsable with it, even on windows (though I only checked with boost.python and its dependencies). I'll look into a synopsis-frontend for pyste, though I can't make any promise as to when I'll get to it, sorry. Regards, Stefan PS: Needless to say: Any help is of course highly appreciated !
On 8/1/05, Stefan Seefeld <seefeld@sympatico.ca> wrote:
I'll look into a synopsis-frontend for pyste, though I can't make any promise as to when I'll get to it, sorry.
Regards, Stefan
PS: Needless to say: Any help is of course highly appreciated !
I am interested in this project. I'd like to add an other back-end to my project - pygccxml. pyplusplus is based on it. Could you provide small example or introduction how you build front-end based on synopsis? Thanks Roman Yakovenko.
[Please let's move this discussion to the synopsis list.] Roman Yakovenko wrote:
PS: Needless to say: Any help is of course highly appreciated !
I am interested in this project. I'd like to add an other back-end to my project - pygccxml. pyplusplus is based on it. Could you provide small example or introduction how you build front-end based on synopsis?
I'm not sure yet, as I don't know how much information is needed, and thus, what representations to use for the code generation. Parse Tree and Type Repository, or AST ? Regards, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
Nicodemus wrote:
I will quote Brad King, the creator of GCCXML, from the gccxml list in a thread regarding this problem (hope he does not mind):
"As I said the GCC parser cannot always handle the results of preprocessing as if using VC7.1. In the case of system headers the GCC-XML installation copies and patches them to fix the problems. In this case all the VC-specific hacks in boost are confusing GCC-XML."
Hopefully Brad can shed some more light in a possible workaround. :)
I can indeed see the problem if you preprocess for CV++ and are then exposed to non-standard extensions during the parsing.
Yeah, but why would you do that when you could preprocess for GCC? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Stefan Seefeld <seefeld@sympatico.ca> writes:
Nicodemus wrote:
I will quote Brad King, the creator of GCCXML, from the gccxml list in a thread regarding this problem (hope he does not mind):
"As I said the GCC parser cannot always handle the results of preprocessing as if using VC7.1. In the case of system headers the GCC-XML installation copies and patches them to fix the problems. In this case all the VC-specific hacks in boost are confusing GCC-XML."
Hopefully Brad can shed some more light in a possible workaround. :)
I can indeed see the problem if you preprocess for CV++ and are then exposed to non-standard extensions during the parsing.
Yeah, but why would you do that when you could preprocess for GCC?
Because that would require a separate gcc to be installed first ? (The gccxml tarball I unpacked on my linux box doesn't appear to contain anything related to a complete development environment such as system headers.) Regards, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
David Abrahams wrote:
Stefan Seefeld <seefeld@sympatico.ca> writes:
Nicodemus wrote:
I will quote Brad King, the creator of GCCXML, from the gccxml list in a thread regarding this problem (hope he does not mind):
"As I said the GCC parser cannot always handle the results of preprocessing as if using VC7.1. In the case of system headers the GCC-XML installation copies and patches them to fix the problems. In this case all the VC-specific hacks in boost are confusing GCC-XML."
Hopefully Brad can shed some more light in a possible workaround. :)
I can indeed see the problem if you preprocess for CV++ and are then exposed to non-standard extensions during the parsing.
Yeah, but why would you do that when you could preprocess for GCC?
Because that would require a separate gcc to be installed first ?
(The gccxml tarball I unpacked on my linux box doesn't appear to contain anything related to a complete development environment such as system headers.)
Well, that doesn't seem like it ought to be a significant obstacle. It seems unreasonable to expect GCCXML to process nonstandard MSVC constructs correctly. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Stefan Seefeld <seefeld@sympatico.ca> writes:
Yeah, but why would you do that when you could preprocess for GCC?
Because that would require a separate gcc to be installed first ?
(The gccxml tarball I unpacked on my linux box doesn't appear to contain anything related to a complete development environment such as system headers.)
Well, that doesn't seem like it ought to be a significant obstacle. It seems unreasonable to expect GCCXML to process nonstandard MSVC constructs correctly.
May be. The problem is that developers have a particular platform with a system compiler, and they want to process code that is written in and for that environment. So the only two options for a windows developer are a) to install a second compiler that is more standard compliant or b) to change the processing tool to understand the MSVC-specific constructs. Right ? And if, in particular, they want to 'look' at the code from the system compiler's perspective, they don't have a choice but to pursue option b). Regards, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
David Abrahams wrote:
Stefan Seefeld <seefeld@sympatico.ca> writes:
Yeah, but why would you do that when you could preprocess for GCC?
Because that would require a separate gcc to be installed first ?
(The gccxml tarball I unpacked on my linux box doesn't appear to contain anything related to a complete development environment such as system headers.)
Well, that doesn't seem like it ought to be a significant obstacle. It seems unreasonable to expect GCCXML to process nonstandard MSVC constructs correctly.
May be. The problem is that developers have a particular platform with a system compiler, and they want to process code that is written in and for that environment. So the only two options for a windows developer are a) to install a second compiler that is more standard compliant
Won't necessarily help. Even a perfectly compliant compiler can include nonstandard extensions.
or b) to change the processing tool to understand the MSVC-specific constructs. Right ?
c) Use #ifdefs where necessary to make their code "portable" to the processing tool.
And if, in particular, they want to 'look' at the code from the system compiler's perspective, they don't have a choice but to pursue option b).
Yeah I guess so. But how important is that? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Nicodemus wrote:
Stefan Seefeld wrote:
Could anybody with gccxml and windows experience detail the problem a bit ? While I plan to look into a new synopsis-based pyste frontend, I don't quite understand the problem, as the compiler emulation code synopsis uses was to a certain degree inspired by gccxml, and so I would assume that gccxml does the right thing, no matter the platform.
I will quote Brad King, the creator of GCCXML, from the gccxml list in a thread regarding this problem (hope he does not mind):
"As I said the GCC parser cannot always handle the results of preprocessing as if using VC7.1. In the case of system headers the GCC-XML installation copies and patches them to fix the problems. In this case all the VC-specific hacks in boost are confusing GCC-XML."
Hopefully Brad can shed some more light in a possible workaround. :)
The easiest way to deal with this is to think of GCC-XML as yet another compiler. Just like code has #ifdef directives to deal with differences between compilers it can also test for the definition of __GCCXML__. This macro is the only way to tell apart GCC-XML from the simulated compiler at preprocessing time. You can use it in cases when the intended work-around is for the parser and not the standard library: #if defined(_MSC_VER) && _MSC_VER < 1300 // MSVC 6 extension syntax #else // Standard syntax #endif might become #if defined(_MSC_VER) && _MSC_VER < 1300 && !defined(__GCCXML__) // MSVC 6 extension syntax #else // Standard syntax #endif -Brad
On 8/1/05, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Nicodemus wrote:
That's the problem mentioned by Petrucio in another thread: standard headers and even boost itself upset GCCXML on Windows.
Could anybody with gccxml and windows experience detail the problem a bit ? While I plan to look into a new synopsis-based pyste frontend, I don't quite understand the problem, as the compiler emulation code synopsis uses was to a certain degree inspired by gccxml, and so I would assume that gccxml does the right thing, no matter the platform.
It is very simple to reproduce the problem. Take for example boost.filesystem library. This is cross-platform library. Also it could be compiled under cygwin. But still you can't parse it with GCC-XML. I can send you the output of such compilation.
Thanks, Stefan
Roman Yakovenko
Hi Roman, Roman Yakovenko wrote:
Could anybody with gccxml and windows experience detail the problem a bit ? While I plan to look into a new synopsis-based pyste frontend, I don't quite understand the problem, as the compiler emulation code synopsis uses was to a certain degree inspired by gccxml, and so I would assume that gccxml does the right thing, no matter the platform.
It is very simple to reproduce the problem. Take for example boost.filesystem library. This is cross-platform library. Also it could be compiled under cygwin. But still you can't parse it with GCC-XML. I can send you the output of such compilation.
Sorry for not being clear. I don't doubt that it is easily reproducible, but as I'm rarely booting my laptop into windows and I don't have gccxml installed on that platform I thought someone could send a precise description of the failure so we wouldn't need to speculate about its exact cause. Thanks, Stefan
On 8/2/05, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Hi Roman,
Sorry for not being clear. I don't doubt that it is easily reproducible, but as I'm rarely booting my laptop into windows and I don't have gccxml installed on that platform I thought someone could send a precise description of the failure so we wouldn't need to speculate about its exact cause.
I will send you compilation output tomorrow. The Brad King is right, source code should be ported to GCCXML compiler. This is the main problem.
Thanks, Stefan
Roman Yakovenko
Roman Yakovenko wrote:
The Brad King is right, source code should be ported to GCCXML compiler. This is the main problem.
I don't agree with that. From a user's perspective, gccxml itself is not a compiler, but a compiler emulator. Users want to 'see' the code as it is seen by a particular compiler (such as gcc or VC++), for whatever reason. It is one thing to say that the emulator doesn't support any particular compiler, but another that the emulator just turned into a compiler which the user (i.e. library developer) has to special-case for. But we are getting way off-topic. May be we should continue on the synopsis list ? Regards, Stefan
participants (6)
-
Alexis H. Rivera-Rios -
Brad King -
David Abrahams -
Nicodemus -
Roman Yakovenko -
Stefan Seefeld