I think it probably makes sense to require a real boost install to build IMP since - Dina's application uses program-options - I use file system a bit in kernel and it would make things much simpler (and, perhaps, more reliable on windows), not to have to work around its absence if it is not there - it would simplify various scripts - it is, in general, easier to get a full install of boost than a headers only one (all normal platforms have some variant of rpm, mac ports, the windows installer etc). We are telling mac people to install mac ports as it is.
Comments?
On 2/26/10 8:37 AM, Daniel Russel wrote: > I think it probably makes sense to require a real boost install to > build IMP since > - Dina's application uses program-options > - I use file system a bit in kernel and it would make things much > simpler (and, perhaps, more reliable on windows), not to have to work > around its absence if it is not there > - it would simplify various scripts > - it is, in general, easier to get a full install of boost than a > headers only one (all normal platforms have some variant of rpm, mac > ports, the windows installer etc). We are telling mac people to install > mac ports as it is.
I agree with all points except the last. With Windows you have the problem of multiple C runtimes - last time I checked the installer was unusable because the DLLs installed were linked against a different runtime than the one we link against. We would have to rebuild the DLLs ourselves. This would be a hassle and I don't think it's wise to make such a change this close to release. My assumption is that you don't consider Solaris to be a "normal platform", but building Boost libraries on Solaris is non-trivial too. We can certainly look into it post-release though.
Ben
>> > I agree with all points except the last. With Windows you have the problem of multiple C runtimes - last time I checked the installer was unusable because the DLLs installed were linked against a different runtime than the one we link against. We would have to rebuild the DLLs ourselves. This would be a hassle and I don't think it's wise to make such a change this close to release. Windows DLL joy. What are the runtime differences? I thought there was just the debug/release split. Or are there more? We don't have the same issue with everything else that is loaded into python? Or is python careful enough not to care?
> My assumption is that you don't consider Solaris to be a "normal platform", Indeed :-)
> but building Boost libraries on Solaris is non-trivial too. It looks like they have mostly worked that out http://shoaibmir.wordpress.com/2009/08/12/building-boost-under-solaris/
> We can certainly look into it post-release though. OK, I'll make foxs fail better when program options is not found.
I'll also add a check that the boost versions match with builds.
On 2/26/10 9:24 AM, Daniel Russel wrote: > Windows DLL joy. What are the runtime differences? I thought there was > just the debug/release split. Or are there more? We don't have the same > issue with everything else that is loaded into python? Or is python > careful enough not to care?
Oh yes, you have the same issue with Python as soon as you start trying to pass around more complex structures that are handled by the C runtime (FILE* is the most common): http://www.python.org/doc/faq/windows/#pyrun-simplefile-crashes-on-windows-b...
(That's a really old link, for Python 1.5, but applies to recent versions too.)
Generally we don't notice this of course since we don't pass FILE* around much. But in IMP this means the C++/Python streams support can't use the (faster) underlying file descriptor on Windows when the Python stream is a simple wrapper around a FILE* (it has to go through the higher level Python API instead). You can see an #ifdef for that in kernel/pyext/IMP_streams.i.
In order for things to work "properly" on Windows you have to compile everything with the same version of MSVC, with the same debug/release flags, and the same single-threaded/multi-threaded options. Or you have to carefully audit and test your code to make sure it doesn't ever use the troublesome parts of the API. It's a big mess.
Ben
participants (2)
-
Ben Webb -
Daniel Russel