Open MPI logo

MTT Devel Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all MTT Devel mailing list

Subject: Re: [MTT devel] MTT on Windows
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-03-11 11:25:32


On Mar 11, 2009, at 10:21 AM, Shiqing Fan wrote:

> >> So we can test like:
> >> if (`uname -o` == "Cygwin" ||
> >> `uname -o` == "MinGW" &&
> >> $config->{compiler_name} == "microsoft") {
> >> .....
> >>
> >
> > Good point. I see that your new patch doesn't test for MinGW --
> > should it?
>
> Yeah, why not. It wasn't in my previous patch, because I didn't test
> it.
>
> But now, I just have tested with MinGW bash, it looks good. The only
> problem for MinGW is that the user has to compile Perl by himself,
> which
> is a complex and painful procedure.
>
> I made another patch, including support for MinGW. Note that we have
> to
> test 'uname -o' for "Msys" rather than "MinGW".
>

Sounds good.

> >> +
> >> + # compile the whole solution
> >> + $x = _do_step($config, "script -a -c \"devenv.com *.sln
> >> /build debug\" -f temp.txt",
> >> + $config->{merge_stdout_stderr});
> >> + %$ret = (%$ret, %$x);
> >> + return $ret if
> >> (!MTT::DoCommand::wsuccess($ret->{exit_status}));
> >
> > I missed this the first time -- don't you need to restore %ENV here?
>
> I'm not sure about this. From what's written in the comment, restoring
> %ENV is only for a 'make check' step, but we don't have such step for
> cmake. That's why I skipped it.
>

I mention it because you're modifying LD_LIBRARY_PATH above -- so you
should restore it when you're done.

> >> +
> >> + # install to the prefix dir
> >> + $x = _do_step($config, "script -a -c \"devenv.com *.sln
> >> /project INSTALL.vcproj /build\" -f temp.txt",
> >> + $config->{merge_stdout_stderr});
> >> + %$ret = (%$ret, %$x);
> >> + return $ret if
> >> (!MTT::DoCommand::wsuccess($ret->{exit_status}));
> >> +
> >> + # All done!
> >> + $ret->{test_result} = MTT::Values::PASS;
> >> + $ret->{result_message} = "Success";
> >> + Debug("Build was a success\n");
> >> +
> >> + return $ret;
> >> + }
> >> +
> >
> > I think I would be more comfortable separating this stuff into a
> > Cmake.pm or somesuch. After all, it's *not* a configure/make (i.e.,
> > GNU tools) build. I think the default should call the GNU install
> > process, but if you set ompi_cmake = 1 (or somesuch), then call your
> > module/routine instead of the GNU one. For example:
> >
> > my $install;
> > if ($config->{ompi_cmake}) {
> > $install = MTT::Common::Cmake::Install($gnu);
> > } else {
> > $install = MTT::Common::GNU_Install::Install($gnu);
> > }
>
> I totally agree here. :-)
>
> > Just curious -- does the OMPI cmake system also work on Linux? I
> ask
> > because your cmake process is fairly win-specific. If it's *only*
> > intended to work on windoze, perhaps we should add some if tests
> to it
> > that warn/error if you're *not* running on cygwin/mingw (this is
> only
> > relevant if/when the cmake stuff moves to its own .pm file).
> >
> > Make sense?
>
> No, the OMPI cmake will stop immediately if it's being used on Linux
> or
> any other non-windows platforms. If you check the CMakeLists.txt in
> the
> root of OMPI source tree, you'll see it first checks the system:
>
> IF(WIN32)
> CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
> ELSE(WIN32)
> MESSAGE( FATAL_ERROR "Only support Windows. Aborting.")
> ENDIF(WIN32)
>
> But it won't stop under Cygwin. (here "WIN32" also includes win64)
>

Gotcha. So if our Cmake system is only targeted at windows, then I
think OMPI.pm can make the determination automatically to call the
GNU_Install or Cmake version.

Perhaps the _do_step stuff should be factored out into a separate .pm
so that you don't have to duplicate all that code between
GNU_Install.pm and Cmake.pm...?

-- 
Jeff Squyres
Cisco Systems