Andrea Denzler
Sorry. Generally I have no problems linking (Debug executables) to Release libraries.
Then you are lucky, or your executables are smaller than 2MB. I have internal compiler/linker errors every day (nice to see VS is built below drive F:), not only crashing Visual Studio 2005, but sometimes also forcing me to reboot. If only this mad behaviour was reproducible. It starts to remind me of gcc-3.0 on hpux-10.2 (2 alpha systems in unholy combination)
For example in the linker options I specify icuuc.lib or icuucd.lib to link boost::regex to the ICU Debug or Release Library. Both cases works well in Debugging.
How can you debug into the library, if the library has no debug symbols?
So the idea to force the debug python libraries is a overkill.
I strongly disagree. It is the normal thing to do. If I debug, I debug and if I run release code I run release lib versions. Also it is not about forcing anyone, but about the fact that it is impossible due to the symbol incompatibility.
Now, when using boost::python in _DEBUG then it is better to use python too in _DEBUG or it's standard release version? I think it's better to use the release version because else as you said you have to download and rebuild the python library only because I want boost in _DEBUG.
This is what it is all about. Boost.Python tries to fix the broken release scheme of Python and by this introduces silent breaks and endless headache with uninituitive behaviour. What is wrong with downloading python sources, clicking on a predefined .sln file, pressing the key combination SHIFT-B, waiting 3 minutes, opening the explorer and copyying the libs to the correct place?
Of course the best would be to modify boost::python so that we can choose if to use python debug or release,
This is excatly what I want. I am looking forward to comments whether my solution idea of moving init calls to a header is OK or not.
even better if we can choose this at link time like I do with other libraries.
Yes. Markus