- everything statically built (dynamically opened).
- OPAL, ORTE and OMPI static libraries and all the components
as dynamic files(DLL).
- everything as dynamic files (DLL).
This commit was SVN r11461.
opal_dirname have the same behavior all the time. It does not modify
the original string and it returns a freshly allocated string.
This commit was SVN r11443.
the BOOL type predefined on Windows in C does not match the C++ bool type
for the same compiler. One is an int when the other is a char.
Make sure we check for bool for all non C++ compilers.
This commit was SVN r11429.
versions of the thread lock functions to determine at runtime if a lock
is needed) to OMPI_ENABLE_PROGRESS_THREADS instead of
OMPI_HAVE_THREAD_SUPPORT. Opal only starts a thread when
OMPI_ENABLE_PROGRESS_THREADS is enabled, and ORTE never really starts
a thread that requires special locking considerations.
MPI_INIT would set opal_uses_threads to true if thread level was
greater than MPI_THREAD_SINGLE, but it would never decreast the
value of opal_uses_threads, meaning that we always enabled all that
locking if we did a threaded build, which isn't neccessary. Now
we do locking iff progress threads are enabled OR thread level
is above MPI_THREAD_SINGLE.
This commit was SVN r11390.
remaining changes are in event.c and event.h, plus everything in the
WIN32-Code directory. I still have to find a way to make it working on
Windows without these changes, but I have good hopes. However, the
the code in WIN32-Code will have to stay there as it's more stable
than the one provided by the libevent project.
This commit was SVN r11386.
as we can have multiple threads in the event library if there are multiple
MPI threads. Well, we could, once I fix the need for the lock in
opal_progress(), which should happen shortly. Anyway, we need to use the
same locking scheme throughout the code, and the device support was
already using the OPAL_THREAD__{lock,unlock} macros, which only go
active when we think there are multiple threads we care about.
Also, stop duplicating the OPAL_THREAD_SCOPED_LOCK macro's functionality
and use it in a bunch of places in the code.
This commit was SVN r11383.
functionality of libevent for Windows. Anyway, these functions are not
currently used in the Open MPI project, so it's safe to remove them from the
Windows library. But, they should be never used otherwise changes are
required.
This commit was SVN r11378.
The same treatement will happens on all sub-projects. The .h files
have to be C++ compatibles and all symbols with an external visibility
have to get the {PROJECT}_DECLSPEC in front of the prototype.
This commit was SVN r11340.
range of OS friendly path management functions, such as opal_basename
opal_dirname. They should always be used instead of basename and
dirname. There are several functions which allow us to create paths
that are compatible with the OS.
The OPAL_ENV_SEP define should be used (instead of ':') when a env
variable is splitted.
This commit was SVN r11336.
Windows version for the libevent. The one they provide is more than
innapropriate for what we need (without talking about the fact that
the code is just plain wrong).
This commit was SVN r11329.
One of the most important is the IOVBASE_TYPE which should be used
all over the places for casting to and from the iov_base field of
the iovec struct. The reason is because windows does not support
any kind of implicit conversion (not even through void*). All
conversions should be EXPLICIT.
This commit was SVN r11328.
environment variables.
- The HOME on Windows is called USERPROFILE.
- C++ compilers (at least on Windows) require explicit casts. Even going
through a void* does not help.
- Cleanup the Windows file name management.
- Always use opal_os_path to create OS friendly paths.
This commit was SVN r11311.
