Re: [OMPI devel] RFC: merge windows branch into trunk

2008-11-20 Thread Ralph Castain 

Hi Rainer

Historically, our rules have prohibited the introduction of such  
features into a sub-release like 1.3.1. Perhaps that policy needs  
review?


We've been pretty strict about it in the past, though...with some good  
reasons, I admit.


Ralph


On Nov 20, 2008, at 4:56 PM, Rainer Keller wrote:


Hi Ralph,
On Donnerstag, 20. November 2008, Ralph Castain wrote:
1. since nearly everyone is at SC08, and since next week is a  
holiday,

the timing of this merge is poor. I would really urge that you delay
it until at least Dec 5 so people actually know about it - and have
time to even think about it

Yes, the idea is having more people take a look into it and try out.

2. how does this fit into our overall release schedule? There was  
talk

at one time (when we thought 1.3 was going out soon) about having a
short release cycle to get Windows support out for 1.4. Now this is
coming into the trunk even before 1.3 goes out.

So is 1.3 going to have a lifecycle of a month? Or are we going to
delay 1.3 (if it even needs to be delayed) so it can include this  
code?

No, why ,-]?
At the appropriate time this can be merged into 1.3.x  (with x being  
> 1...?)



Reason I ask: last time we rolled Windows support into the system it
created a complete code fork, making support for the current stable
release nearly impossible. There generated a lot of unhappiness and
argument within the community until we finally released a new  
version.
Well, we believe with only the view touched general files and only  
the CCP

components being added, there's less chance of hurting other code.


M ompi/runtime/ompi_mpi_init.c
...
M orte/tools/orterun/orterun.c
M orte/util/hnp_contact.c


I would ask that you consider breaking these
modifications into parts that "could" be harmlessly
brought over independently to 1.3, if a subsequent
non-windows bugfix to one of those files needs to
be brought over that will only merge cleanly if some
of your changes to the same file are also brought over.
For example, it would be a real pain to have to use
patchfiles to resolve merge conflicts simply because
of an #ifdef or white-space change here or there.
Hopefully that made sense...
Yes, breaking into chunks (such as the CMakeLists.txt + .windows  
files, the
CCP component and finally the files that touch other files) is a  
good way

forward.

CU,
Rainer
--

Dipl.-Inf. Rainer Keller   http://www.hlrs.de/people/keller
HLRS  Tel: ++49 (0)711-685 6 5858
Nobelstrasse 19  Fax: ++49 (0)711-685 6 5832
70550 Stuttgartemail: kel...@hlrs.de
Germany AIM/Skype:rusraink

Re: [OMPI devel] RFC: merge windows branch into trunk

2008-11-20 Thread Rainer Keller 
Hi Ralph,
On Donnerstag, 20. November 2008, Ralph Castain wrote:
> 1. since nearly everyone is at SC08, and since next week is a holiday,
> the timing of this merge is poor. I would really urge that you delay
> it until at least Dec 5 so people actually know about it - and have
> time to even think about it
Yes, the idea is having more people take a look into it and try out.

> 2. how does this fit into our overall release schedule? There was talk
> at one time (when we thought 1.3 was going out soon) about having a
> short release cycle to get Windows support out for 1.4. Now this is
> coming into the trunk even before 1.3 goes out.
>
> So is 1.3 going to have a lifecycle of a month? Or are we going to
> delay 1.3 (if it even needs to be delayed) so it can include this code?
No, why ,-]?
At the appropriate time this can be merged into 1.3.x  (with x being > 1...?)

> Reason I ask: last time we rolled Windows support into the system it
> created a complete code fork, making support for the current stable
> release nearly impossible. There generated a lot of unhappiness and
> argument within the community until we finally released a new version.
Well, we believe with only the view touched general files and only the CCP 
components being added, there's less chance of hurting other code.

> >> M ompi/runtime/ompi_mpi_init.c
> >> ...
> >> M orte/tools/orterun/orterun.c
> >> M orte/util/hnp_contact.c
> >
> > I would ask that you consider breaking these
> > modifications into parts that "could" be harmlessly
> > brought over independently to 1.3, if a subsequent
> > non-windows bugfix to one of those files needs to
> > be brought over that will only merge cleanly if some
> > of your changes to the same file are also brought over.
> > For example, it would be a real pain to have to use
> > patchfiles to resolve merge conflicts simply because
> > of an #ifdef or white-space change here or there.
> > Hopefully that made sense...
Yes, breaking into chunks (such as the CMakeLists.txt + .windows files, the 
CCP component and finally the files that touch other files) is a good way 
forward.

CU,
Rainer
-- 

Dipl.-Inf. Rainer Keller   http://www.hlrs.de/people/keller
 HLRS  Tel: ++49 (0)711-685 6 5858
 Nobelstrasse 19  Fax: ++49 (0)711-685 6 5832
 70550 Stuttgartemail: kel...@hlrs.de 
 Germany AIM/Skype:rusraink

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-20 Thread Ethan Mallove 
On Thu, Nov/20/2008 07:00:31PM, Ralf Wildenhues wrote:
> Our previous mails overlapped, sorry about that.
> 
> * Ethan Mallove wrote on Thu, Nov 20, 2008 at 06:52:09PM CET:
> > 
> > The above appears to be looking for a Fortran version string from the
> > C compiler, but it wouldn't match our version string anyway:
> > 
> >   $ f90 -V
> >   f90: Sun Ceres Fortran 95 8.3 SunOS_sparc 2008/01/28
> 
> Ah, ok.  Please try the patch below instead of yours, thanks.

Your patch seems to work, though I get this:

   libtool: Version mismatch error.  This is libtool 2.2.7a, but the
   libtool: definition of this LT_INIT comes from libtool 2.2.6.
   libtool: You should recreate aclocal.m4 with macros from libtool 2.2.7a
   libtool: and run autoconf again.

I take it the above error will occur if I have two different libtools
in my PATH?

This comment could be a little misleading because the same is true for
Sun Fortran 8.1 and 8.2:

  # Sun Fortran 8.3 passes all unrecognized flags to the linker

I don't know of a version of Sun Fortran that accepts -Wl the way GNU
Fortran does. I will let you know if I find one.

> Do you mind being added to libtool/THANKS (includes email address)?

I do not mind.

> > I'm still running into the Cstd/stlport4 issue with 2.2.6. That is,
> > this line appears in the libtool script:
> > 
> >   postdeps="-library=Cstd -library=Crun"
>
> Do you have the string " -library=stlport4 " in $CXX $CXXFLAGS?
> If not, then how can Libtool detect that you use stlport?

Ok. When I use -library=stlport4, I get libstlport linked to
libmpi_cxx, instead of libCstd. Doesn't that then lock the user into
having to use stlport4 when we want them to be able to use either Cstd
or stlport4?

Thanks,
Ethan


> 
> Thanks,
> Ralf
> 
>   * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [ linux ]: Also
> match `Sun Ceres Fortran' compiler; reorder with C compiler
>   matching.
>   * THANKS: Update.
>   Report by Ethan Mallove.
> 
> diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
> index 7fbf965..d90c4f4 100644
> --- a/libltdl/m4/libtool.m4
> +++ b/libltdl/m4/libtool.m4
> @@ -3947,17 +3947,17 @@ m4_if([$1], [CXX], [
>   ;;
>*)
>   case `$CC -V 2>&1 | sed 5q` in
> - *Sun\ C*)
> -   # Sun C 5.9
> + *Sun\ F* | *Sun*Fortran*)
> +   # Sun Fortran 8.3 passes all unrecognized flags to the linker
> _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
> _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
> -   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
> +   _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
> ;;
> - *Sun\ F*)
> -   # Sun Fortran 8.3 passes all unrecognized flags to the linker
> + *Sun\ C*)
> +   # Sun C 5.9
> _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
> _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
> -   _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
> +   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
> ;;
>   esac
>   ;;
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] IOF round 2

2008-11-20 Thread Ralph Castain 

Hi all

I believe I have fixed the IOF problems reported by Tim M a week ago  
(11/13). The fixes are in a separate Hg branch:


http://www.open-mpi.org/hg/hgwebdir.cgi/rhc/iof/

Before I bring these to the trunk - and eventually migrate them to the  
1.3 branch - would some of you like to run an MTT pass across the  
branch? I have run it through some of the tests that reported issues  
before, and it seems to be working just fine - but I wanted to offer a  
chance for people to test it prior to bringing it back into the trunk.


Please let me know if/when you can do this so I can plan on when to  
bring this over to the trunk. If I don't hear from folks by Dec 1,  
I'll just bring it into the trunk so it can get tested there.


Thanks
Ralph

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-20 Thread Ralf Wildenhues 
Our previous mails overlapped, sorry about that.

* Ethan Mallove wrote on Thu, Nov 20, 2008 at 06:52:09PM CET:
> 
> The above appears to be looking for a Fortran version string from the
> C compiler, but it wouldn't match our version string anyway:
> 
>   $ f90 -V
>   f90: Sun Ceres Fortran 95 8.3 SunOS_sparc 2008/01/28

Ah, ok.  Please try the patch below instead of yours, thanks.
Do you mind being added to libtool/THANKS (includes email address)?

> I'm still running into the Cstd/stlport4 issue with 2.2.6. That is,
> this line appears in the libtool script:
> 
>   postdeps="-library=Cstd -library=Crun"

Do you have the string " -library=stlport4 " in $CXX $CXXFLAGS?
If not, then how can Libtool detect that you use stlport?

Thanks,
Ralf

* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [ linux ]: Also
match `Sun Ceres Fortran' compiler; reorder with C compiler
matching.
* THANKS: Update.
Report by Ethan Mallove.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 7fbf965..d90c4f4 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3947,17 +3947,17 @@ m4_if([$1], [CXX], [
;;
   *)
case `$CC -V 2>&1 | sed 5q` in
-   *Sun\ C*)
- # Sun C 5.9
+   *Sun\ F* | *Sun*Fortran*)
+ # Sun Fortran 8.3 passes all unrecognized flags to the linker
  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
- _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
  ;;
-   *Sun\ F*)
- # Sun Fortran 8.3 passes all unrecognized flags to the linker
+   *Sun\ C*)
+ # Sun C 5.9
  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
- _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
  ;;
esac
;;

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-20 Thread Ralf Wildenhues 
Hello Ethan,

* Ethan Mallove wrote on Wed, Nov 19, 2008 at 09:24:16PM CET:
> 
> I'm seeing the same issue with the faulty "wl" Libtool
> variable in 2.2.6 with Linux SunStudio:

That's really weird, because this change should have fixed that:


>   make[5]: Entering directory `ompi/mpi/f90'
>   /bin/sh ../../../libtool   --mode=link f90 -I../../../ompi/include 
> -I../../../ompi/include -M. -I. -I../../../ompi/mpi/f90  -m32 -xO5  
> -export-dynamic-o libmpi_f90.la -rpath /opt/SUNWhpc/HPC8.1/sun/lib mpi.lo 
> mpi_sizeof.lo mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo 
> mpi_testsome_f90.lo mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo 
> mpi_wtime_f90.lo   ../../../ompi/libmpi.la -lnsl -lutil  -lm
>   libtool: link: f90 -G  .libs/mpi.o .libs/mpi_sizeof.o 
> .libs/mpi_comm_spawn_multiple_f90.o .libs/mpi_testall_f90.o 
> .libs/mpi_testsome_f90.o .libs/mpi_waitall_f90.o .libs/mpi_waitsome_f90.o 
> .libs/mpi_wtick_f90.o .libs/mpi_wtime_f90.o   -Wl,-rpath -Wl,ompi/.libs 
> -Wl,-rpath 
> -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
>  -Wl,-rpath 
> -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
>  -Wl,-rpath -Wl,/opt/SUNWhpc/HPC8.1/sun/lib 
> -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
>  
> -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
>  ../../../ompi/.libs/libmpi.so 
> /tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs/libopen-rte.so
>  opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lm  -m32   -mt -Wl,-soname 
> -Wl,libmpi_f90.so.0 -o .libs/libmpi_f90.so.0.0.0
>   f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
[...]

Please post the output of
  f90 -V

and the output of
  ./libtool --tag=FC --config

to see what's going on.

Thanks,
Ralf

Re: [OMPI devel] RFC: merge windows branch into trunk

2008-11-20 Thread Ralf Wildenhues 
I'm probably going to come across as ignorant, and I'm
obviously biased on this matter, but:

* Tim Mattox wrote on Thu, Nov 20, 2008 at 02:53:13PM CET:
> 
> Although I don't use windows myself, I appreciate your
> and others' efforts to expand the number of platforms
> we can run on.  Great work!

what keeps you from using the autotools-based build system
with MSVC?  All you should need is a wrapper like cccl.

Cheers,
Ralf

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-20 Thread Ethan Mallove 
On Wed, Nov/19/2008 03:24:16PM, Ethan Mallove wrote:
> On Wed, Nov/19/2008 01:42:55PM, Ethan Mallove wrote:
> > On Wed, Nov/19/2008 05:12:03PM, Ralf Wildenhues wrote:
> > > Hello Ethan,
> > > 
> > > * Ethan Mallove wrote on Wed, Nov 19, 2008 at 04:11:23PM CET:
> > > > There are a couple issues with SunStudio and Libtool:
> > > 
> > > Which Libtool version are you using?  If not 2.2.2 or newer, then please
> > > retry with 2.2.6.  If the problem persists, then we should fix Libtool
> > > rather than patching OpenMPI.  That way, other packages benefit from the
> > > fix as well.
> > > 
> > 
> > I'm using 2.2 (for Solaris) and 2.1b (for Linux). I'll try
> > 2.2.6.
> > 
> 
> I'm seeing the same issue with the faulty "wl" Libtool
> variable in 2.2.6 with Linux SunStudio:
> 
>   ...
>   make[5]: Entering directory `ompi/mpi/f90'
>   /bin/sh ../../../libtool   --mode=link f90 -I../../../ompi/include 
> -I../../../ompi/include -M. -I. -I../../../ompi/mpi/f90  -m32 -xO5  
> -export-dynamic-o libmpi_f90.la -rpath /opt/SUNWhpc/HPC8.1/sun/lib mpi.lo 
> mpi_sizeof.lo mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo 
> mpi_testsome_f90.lo mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo 
> mpi_wtime_f90.lo   ../../../ompi/libmpi.la -lnsl -lutil  -lm
>   libtool: link: f90 -G  .libs/mpi.o .libs/mpi_sizeof.o 
> .libs/mpi_comm_spawn_multiple_f90.o .libs/mpi_testall_f90.o 
> .libs/mpi_testsome_f90.o .libs/mpi_waitall_f90.o .libs/mpi_waitsome_f90.o 
> .libs/mpi_wtick_f90.o .libs/mpi_wtime_f90.o   -Wl,-rpath -Wl,ompi/.libs 
> -Wl,-rpath 
> -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
>  -Wl,-rpath 
> -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
>  -Wl,-rpath -Wl,/opt/SUNWhpc/HPC8.1/sun/lib 
> -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
>  
> -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
>  ../../../ompi/.libs/libmpi.so 
> /tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs/libopen-rte.so
>  opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lm  -m32   -mt -Wl,-soname 
> -Wl,libmpi_f90.so.0 -o .libs/libmpi_f90.so.0.0.0
>   f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>   f90: Warning: Option -Wl,ompi/.libs passed to ld, if ld is invoked, ignored 
> otherwise
>   f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,orte/.libs passed to ld, if ld is invoked, 
> ignored otherwise
>  f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,opal/.libs passed to ld, if ld is invoked, 
> ignored otherwise
>  f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,/opt/SUNWhpc/HPC8.1/sun/lib passed to ld, if ld 
> is invoked, ignored otherwise
>  f90: Warning: Option -Wl,-soname passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,libmpi_f90.so.0 passed to ld, if ld is invoked, 
> ignored otherwise
>   /usr/bin/ld: unrecognized option '-Wl,-rpath'
>  /usr/bin/ld: use the --help option for usage information
>   make[5]: *** [libmpi_f90.la] Error 1
>  make[5]: Leaving directory `ompi/mpi/f90'
>   make[4]: *** [install-recursive] Error 1
>   make[4]: Leaving directory `ompi/mpi/f90'
>   make[3]: *** [install] Error 2
>  make[3]: Leaving directory `ompi/mpi/f90'
>   make[2]: *** [install-recursive] Error 1
>   make[2]: Leaving directory `ompi'
>   make[1]: *** [install] Error 2
>   make[1]: Leaving directory `ompi'
>   make: *** [install-recursive] Error 1
> 
> The wl var in auto-generated libtool script should be set to
> "".

I think I found a potential problem. I see this in configure:

case `$CC -V 2>&1 | sed 5q` in
*Sun\ C*)
  # Sun C 5.9
  lt_prog_compiler_pic='-KPIC'
  lt_prog_compiler_static='-Bstatic'
  lt_prog_compiler_wl='-Wl,'
  ;;
*Sun\ F*)
  # Sun Fortran 8.3 passes all unrecognized flags to the linker
  lt_prog_compiler_pic='-KPIC'
  lt_prog_compiler_static='-Bstatic'
  lt_prog_compiler_wl=''
  ;;
esac
;;

The above appears to be looking for a Fortran version string from the
C compiler, but it wouldn't match our version string anyway:

  $ f90 -V
  f90: Sun Ceres Fortran 95 8.3 SunOS_sparc 2008/01/28

The result is that lt_prog_compiler_wl never gets set to '', and it
should. See attached (untested) patch.

> 
> Less sure about the Cstd/stlport4 issue, though it does
> appear from the below thread that the issue was already
> tackled at some point:
> 
>   http://lists.gnu.org/archive/html/libtool/2008-02/msg00024.html
> 
> The thread says the Cstd/stlport4 issue was fixed in 2006.

I'm still

Re: [OMPI devel] RFC: merge windows branch into trunk

2008-11-20 Thread Shiqing Fan 

Hi Ralph,
1. since nearly everyone is at SC08, and since next week is a holiday, 
the timing of this merge is poor. I would really urge that you delay 
it until at least Dec 5 so people actually know about it - and have 
time to even think about it
No problem, we can delay it. Dec 9th is the last choice for me to do it 
before Christmas, otherwise it can only happen next year.


2. how does this fit into our overall release schedule? There was talk 
at one time (when we thought 1.3 was going out soon) about having a 
short release cycle to get Windows support out for 1.4. Now this is 
coming into the trunk even before 1.3 goes out.


So is 1.3 going to have a lifecycle of a month? Or are we going to 
delay 1.3 (if it even needs to be delayed) so it can include this code?


Reason I ask: last time we rolled Windows support into the system it 
created a complete code fork, making support for the current stable 
release nearly impossible. There generated a lot of unhappiness and 
argument within the community until we finally released a new version.


From what I have seen as we've discussed things during devel, these 
are fairly well-contained changes. However, it -will- make maintaining 
1.3 more difficult if people attempt to do it the old way - making 
changes in the trunk and patching across to 1.3. If we instead use 
isolated 1.3 branches for maintaining the code, then this isn't an issue.
I made a detailed diff in last email, most of the changes are in the new 
added files and windows specific files, that won't go into 1.3. The rest 
necessary changes are minor, but if they do make it difficult to 
maintain 1.3, we can also consider a separate merge after 1.3. :-)



Thanks,
Shiqing



Merits more thought than one week can provide.

Ralph


On Nov 20, 2008, at 6:53 AM, Tim Mattox wrote:


I have two concerns.  First is that we really need to focus on
getting 1.3 stable and released.  My second concern with
this is how will it effect merging of bugfixes for 1.3 from the
trunk once we release 1.3.  Will the following modified files
cause merge conflicts for CMRs?  How big is this diff,
can you send it to the list, or otherwise make it available?


M ompi/runtime/ompi_mpi_init.c
M opal/event/event.c
M opal/event/WIN32-Code/win32.c
M opal/mca/base/mca_base_param.c
M opal/mca/installdirs/windows/opal_installdirs_windows.c
M opal/runtime/opal_cr.c
M opal/win32/ompi_misc.h
M opal/win32/win_compat.h
M orte/mca/plm/ccp/plm_ccp_component.c
M orte/mca/plm/ccp/plm_ccp_module.c
M orte/mca/plm/process/plm_process_module.c
M orte/mca/ras/ccp/ras_ccp_component.c
M orte/mca/ras/ccp/ras_ccp_module.c
M orte/runtime/orte_wait.c
M orte/tools/orterun/orterun.c
M orte/util/hnp_contact.c


I would ask that you consider breaking these
modifications into parts that "could" be harmlessly
brought over independently to 1.3, if a subsequent
non-windows bugfix to one of those files needs to
be brought over that will only merge cleanly if some
of your changes to the same file are also brought over.
For example, it would be a real pain to have to use
patchfiles to resolve merge conflicts simply because
of an #ifdef or white-space change here or there.
Hopefully that made sense...

Although I don't use windows myself, I appreciate your
and others' efforts to expand the number of platforms
we can run on.  Great work!
--
Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/
tmat...@gmail.com || timat...@open-mpi.org
   I'm a bright... http://www.the-brights.net/
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: merge windows branch into trunk

2008-11-20 Thread Shiqing Fan 

Hi Tim,

Yes, you're right. Most of those changes are made based on #ifdef 
__WINDOWS__, that would make troubles for CMRs.


Here I provide some more information :



These files are harmless, because no other platform will use them (no need to 
go into 1.3).

M opal/event/WIN32-Code/win32.c
M opal/mca/installdirs/windows/opal_installdirs_windows.c
M opal/win32/ompi_misc.h
M opal/win32/win_compat.h
M orte/mca/plm/ccp/plm_ccp_component.c
M orte/mca/plm/ccp/plm_ccp_module.c
M orte/mca/ras/ccp/ras_ccp_component.c
M orte/mca/ras/ccp/ras_ccp_module.c




The changes in these files are important for windows support(see details in the 
first diff file).

M orte/runtime/orte_wait.c
M orte/tools/orterun/orterun.c
M orte/util/hnp_contact.c
M ompi/runtime/ompi_mpi_init.c
M opal/event/event.c



These files are less important, and could be committed to trunk later (after 
1.3). The modification is huge in plm_process_module.c(see the second diff file)

M opal/runtime/opal_cr.c
M orte/mca/plm/process/plm_process_module.c
M opal/mca/base/mca_base_param.c



If it's necessary, we can also delay one/two of the three parts.


Thanks,
Shiqing





Tim Mattox wrote:

I have two concerns.  First is that we really need to focus on
getting 1.3 stable and released.  My second concern with
this is how will it effect merging of bugfixes for 1.3 from the
trunk once we release 1.3.  Will the following modified files
cause merge conflicts for CMRs?  How big is this diff,
can you send it to the list, or otherwise make it available?

  

M ompi/runtime/ompi_mpi_init.c
M opal/event/event.c
M opal/event/WIN32-Code/win32.c
M opal/mca/base/mca_base_param.c
M opal/mca/installdirs/windows/opal_installdirs_windows.c
M opal/runtime/opal_cr.c
M opal/win32/ompi_misc.h
M opal/win32/win_compat.h
M orte/mca/plm/ccp/plm_ccp_component.c
M orte/mca/plm/ccp/plm_ccp_module.c
M orte/mca/plm/process/plm_process_module.c
M orte/mca/ras/ccp/ras_ccp_component.c
M orte/mca/ras/ccp/ras_ccp_module.c
M orte/runtime/orte_wait.c
M orte/tools/orterun/orterun.c
M orte/util/hnp_contact.c



I would ask that you consider breaking these
modifications into parts that "could" be harmlessly
brought over independently to 1.3, if a subsequent
non-windows bugfix to one of those files needs to
be brought over that will only merge cleanly if some
of your changes to the same file are also brought over.
For example, it would be a real pain to have to use
patchfiles to resolve merge conflicts simply because
of an #ifdef or white-space change here or there.
Hopefully that made sense...

Although I don't use windows myself, I appreciate your
and others' efforts to expand the number of platforms
we can run on.  Great work!
  


Index: ompi/runtime/ompi_mpi_init.c
===
--- ompi/runtime/ompi_mpi_init.c(revision 20022)
+++ ompi/runtime/ompi_mpi_init.c(working copy)
@@ -685,7 +685,9 @@
 }
 
 /* Do we need to wait for a debugger? */
+#ifndef __WINDOWS__
 ompi_wait_for_debugger();
+#endif
 
 /* check for timing request - get stop time and report elapsed
  time if so, then start the clock again */
Index: opal/event/event.c
===
--- opal/event/event.c  (revision 20022)
+++ opal/event/event.c  (working copy)
@@ -310,7 +310,11 @@
 #ifdef __APPLE__
"select",
 #else
+#  ifdef __WINDOWS__
+   "win32",
+#  else
"poll",
+#  endif
 #endif
&event_module_include);
 free(help_msg);  /* release the help message */
Index: orte/runtime/orte_wait.c
===
--- orte/runtime/orte_wait.c(revision 20022)
+++ orte/runtime/orte_wait.c(working copy)
@@ -495,6 +495,9 @@
 /* create the event */
 *event = (opal_event_t*)malloc(sizeof(opal_event_t));
 
+/* setup the trigger and its associated lock */
+OBJ_CONSTRUCT(trig, orte_trigger_event_t);
+
 /* pass back the write end of the pipe */
 trig->channel = p[1];
 
@@ -887,8 +890,8 @@
 return;
 }
 
-send(trig->channel, (const char *) &data, sizeof(int), 0);
-   closesocket(trig->channel);
+send(trig->channel, (const char*)&data, sizeof(int), 0);
+closesocket(trig->channel);
 opal_progress();
 }
 
@@ -1102,6 +1105,9 @@
 /* create the event */
 *event = (opal_event_t*)malloc(sizeof(opal_event_t));
 
+/* setup the trigger and its associated lock */
+OBJ_CONSTRUCT(trig, orte_trigger_event_t);
+
 /* pass back the write end of the pipe */
 trig->channel = p[1];
 
Index: orte/tools/orterun/orterun.c
=

Re: [OMPI devel] RFC: merge windows branch into trunk

2008-11-20 Thread Ralph Castain 
HmmmI was just typing this up when Tim's note hit. I also have two  
concerns that somewhat echo his:


1. since nearly everyone is at SC08, and since next week is a holiday,  
the timing of this merge is poor. I would really urge that you delay  
it until at least Dec 5 so people actually know about it - and have  
time to even think about it


2. how does this fit into our overall release schedule? There was talk  
at one time (when we thought 1.3 was going out soon) about having a  
short release cycle to get Windows support out for 1.4. Now this is  
coming into the trunk even before 1.3 goes out.


So is 1.3 going to have a lifecycle of a month? Or are we going to  
delay 1.3 (if it even needs to be delayed) so it can include this code?


Reason I ask: last time we rolled Windows support into the system it  
created a complete code fork, making support for the current stable  
release nearly impossible. There generated a lot of unhappiness and  
argument within the community until we finally released a new version.


From what I have seen as we've discussed things during devel, these  
are fairly well-contained changes. However, it -will- make maintaining  
1.3 more difficult if people attempt to do it the old way - making  
changes in the trunk and patching across to 1.3. If we instead use  
isolated 1.3 branches for maintaining the code, then this isn't an  
issue.


Merits more thought than one week can provide.

Ralph


On Nov 20, 2008, at 6:53 AM, Tim Mattox wrote:


I have two concerns.  First is that we really need to focus on
getting 1.3 stable and released.  My second concern with
this is how will it effect merging of bugfixes for 1.3 from the
trunk once we release 1.3.  Will the following modified files
cause merge conflicts for CMRs?  How big is this diff,
can you send it to the list, or otherwise make it available?


M ompi/runtime/ompi_mpi_init.c
M opal/event/event.c
M opal/event/WIN32-Code/win32.c
M opal/mca/base/mca_base_param.c
M opal/mca/installdirs/windows/opal_installdirs_windows.c
M opal/runtime/opal_cr.c
M opal/win32/ompi_misc.h
M opal/win32/win_compat.h
M orte/mca/plm/ccp/plm_ccp_component.c
M orte/mca/plm/ccp/plm_ccp_module.c
M orte/mca/plm/process/plm_process_module.c
M orte/mca/ras/ccp/ras_ccp_component.c
M orte/mca/ras/ccp/ras_ccp_module.c
M orte/runtime/orte_wait.c
M orte/tools/orterun/orterun.c
M orte/util/hnp_contact.c


I would ask that you consider breaking these
modifications into parts that "could" be harmlessly
brought over independently to 1.3, if a subsequent
non-windows bugfix to one of those files needs to
be brought over that will only merge cleanly if some
of your changes to the same file are also brought over.
For example, it would be a real pain to have to use
patchfiles to resolve merge conflicts simply because
of an #ifdef or white-space change here or there.
Hopefully that made sense...

Although I don't use windows myself, I appreciate your
and others' efforts to expand the number of platforms
we can run on.  Great work!
--
Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/
tmat...@gmail.com || timat...@open-mpi.org
   I'm a bright... http://www.the-brights.net/
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: merge windows branch into trunk

2008-11-20 Thread Tim Mattox 
I have two concerns.  First is that we really need to focus on
getting 1.3 stable and released.  My second concern with
this is how will it effect merging of bugfixes for 1.3 from the
trunk once we release 1.3.  Will the following modified files
cause merge conflicts for CMRs?  How big is this diff,
can you send it to the list, or otherwise make it available?

> M ompi/runtime/ompi_mpi_init.c
> M opal/event/event.c
> M opal/event/WIN32-Code/win32.c
> M opal/mca/base/mca_base_param.c
> M opal/mca/installdirs/windows/opal_installdirs_windows.c
> M opal/runtime/opal_cr.c
> M opal/win32/ompi_misc.h
> M opal/win32/win_compat.h
> M orte/mca/plm/ccp/plm_ccp_component.c
> M orte/mca/plm/ccp/plm_ccp_module.c
> M orte/mca/plm/process/plm_process_module.c
> M orte/mca/ras/ccp/ras_ccp_component.c
> M orte/mca/ras/ccp/ras_ccp_module.c
> M orte/runtime/orte_wait.c
> M orte/tools/orterun/orterun.c
> M orte/util/hnp_contact.c

I would ask that you consider breaking these
modifications into parts that "could" be harmlessly
brought over independently to 1.3, if a subsequent
non-windows bugfix to one of those files needs to
be brought over that will only merge cleanly if some
of your changes to the same file are also brought over.
For example, it would be a real pain to have to use
patchfiles to resolve merge conflicts simply because
of an #ifdef or white-space change here or there.
Hopefully that made sense...

Although I don't use windows myself, I appreciate your
and others' efforts to expand the number of platforms
we can run on.  Great work!
-- 
Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/
 tmat...@gmail.com || timat...@open-mpi.org
I'm a bright... http://www.the-brights.net/

[OMPI devel] RFC: merge windows branch into trunk

2008-11-20 Thread Shiqing Fan 


WHAT:  To merge windows (cmake) support into trunk

WHY:  To allow people configure/compile Open MPI with CMake and Visual 
Studio on Windows platforms


WHERE:  Mainly in /contrib/platform/win32/ ; a few CMakeLists.txt files 
and some source files referred with Windows. (See the completed list of 
modified files below)


WHEN:  Next week

TIMEOUT:  28th Nov 2008





The windows branch has been tested for some time, and the basic 
functionalities worked well. It is now better to merge it back into 
trunk, so that more people can test it.


The original auto-tools based build system won't be affected. The 
changes to the source code are minimum, and only Windows related. It is 
supposed to be used for building Open MPI and applications only on 
Windows platforms (XP, Vista, server 2003 and server 2008).




Shiqing


--
The completed list of affected files (based on trunk revision 20022 and 
current Windows branch):


M ompi/runtime/ompi_mpi_init.c
M opal/event/event.c
M opal/event/WIN32-Code/win32.c
M opal/mca/base/mca_base_param.c
M opal/mca/installdirs/windows/opal_installdirs_windows.c
M opal/runtime/opal_cr.c
M opal/win32/ompi_misc.h
M opal/win32/win_compat.h
M orte/mca/plm/ccp/plm_ccp_component.c
M orte/mca/plm/ccp/plm_ccp_module.c
M orte/mca/plm/process/plm_process_module.c
M orte/mca/ras/ccp/ras_ccp_component.c
M orte/mca/ras/ccp/ras_ccp_module.c
M orte/runtime/orte_wait.c
M orte/tools/orterun/orterun.c
M orte/util/hnp_contact.c
A CMakeLists.txt
A contrib/platform/win32/bin
A contrib/platform/win32/bin/flex.exe
A contrib/platform/win32/CMakeModules
A contrib/platform/win32/CMakeModules/c_check_bool.cmake
A contrib/platform/win32/CMakeModules/check_c_inline.cmake
A contrib/platform/win32/CMakeModules/check_c_type_exists.cmake
A contrib/platform/win32/CMakeModules/check_mca_subdirs.cmake
A contrib/platform/win32/CMakeModules/check_sizeof_bool.cmake
A contrib/platform/win32/CMakeModules/F77_check.cmake
A contrib/platform/win32/CMakeModules/F77_check_type.cmake
A contrib/platform/win32/CMakeModules/F77_find_ext_symbol_convention.cmake
A contrib/platform/win32/CMakeModules/F77_get_alignment.cmake
A contrib/platform/win32/CMakeModules/f77_get_sizeof.cmake
A contrib/platform/win32/CMakeModules/find_flex.cmake
A contrib/platform/win32/CMakeModules/generate_version_file.cmake
A contrib/platform/win32/CMakeModules/get_c_alignment.cmake
A contrib/platform/win32/CMakeModules/ompi_check_Microsoft.cmake
A contrib/platform/win32/CMakeModules/ompi_configure.cmake
A contrib/platform/win32/CMakeModules/ompi_find_type.cmake
A contrib/platform/win32/CMakeModules/ompi_get_version.cmake
A contrib/platform/win32/CMakeModules/setup_F77.cmake
A contrib/platform/win32/ConfigFiles
A contrib/platform/win32/ConfigFiles/install_dirs.h.cmake
A contrib/platform/win32/ConfigFiles/mpi.h.cmake
A contrib/platform/win32/ConfigFiles/mpic++-wrapper-data.txt.cmake
A contrib/platform/win32/ConfigFiles/mpicc-wrapper-data.txt.cmake
A contrib/platform/win32/ConfigFiles/mpif77-wrapper-data.txt.cmake
A contrib/platform/win32/ConfigFiles/opal_config.h.cmake
A contrib/platform/win32/ConfigFiles/revision.in
A contrib/platform/win32/opal
A contrib/platform/win32/opal/libltdl
A contrib/platform/win32/opal/libltdl/ltdl.c
A contrib/platform/win32/opal/libltdl/ltdl.h
A ompi/CMakeLists.txt
A ompi/mca/allocator/basic/.windows
A ompi/mca/allocator/bucket/.windows
A ompi/mca/bml/r2/.windows
A ompi/mca/btl/self/.windows
A ompi/mca/btl/sm/.windows
A ompi/mca/btl/tcp/.windows
A ompi/mca/coll/basic/.windows
A ompi/mca/coll/hierarch/.windows
A ompi/mca/coll/self/.windows
A ompi/mca/coll/sm/.windows
A ompi/mca/common/sm/.windows
A ompi/mca/dpm/orte/.windows
A ompi/mca/mpool/rdma/.windows
A ompi/mca/mpool/sm/.windows
A ompi/mca/osc/pt2pt/.windows
A ompi/mca/osc/rdma/.windows
A ompi/mca/pml/cm/.windows
A ompi/mca/pml/dr/.windows
A ompi/mca/pml/ob1/.windows
A ompi/mca/pubsub/orte/.windows
A ompi/mca/topo/unity/.windows
A ompi/mpi/CMakeLists.txt
A ompi/mpi/cxx/CMakeLists.txt
A ompi/mpi/f77/CMakeLists.txt
A ompi/tools/CMakeLists.txt
A ompi/tools/ompi-server/CMakeLists.txt
A ompi/tools/ompi_info/CMakeLists.txt
A opal/CMakeLists.txt
A opal/event/CMakeLists.txt
A opal/event/compat/sys/CMakeLists.txt
A opal/event/WIN32-Code/CMakeLists.txt
A opal/include/CMakeLists.txt
A opal/mca/backtrace/none/.windows
A opal/mca/carto/auto_detect/.windows
A opal/mca/crs/none/.windows
A opal/mca/installdirs/config/.windows
A opal/mca/installdirs/env/.windows
A opal/mca/installdirs/windows/.windows
A opal/mca/maffinity/first_use/.windows
A opal/mca/paffinity/windows/.windows
A opal/tools/CMakeLists.txt
A opal/tools/opal-checkpoint/CMakeLists.txt
A opal/tools/opal-restart/CMakeLists.txt
A opal/tools/wrappers/CMakeLists.txt
A orte/CMakeLists.txt
A orte/mca/errmgr/default/.windows
A orte/mca/ess/env/.windows
A orte/mca/ess/hnp/.windows
A orte/mca/ess/singleton/.windows
A orte/mca/gr