Re: [Plplot-devel] comprehensive testing of MSVC/ifort/nmake
Hi Alan,
> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, March 14, 2016 10:23 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: comprehensive testing of MSVC/ifort/nmake
>
> On 2016-03-14 07:35- Arjen Markus wrote:
>
> > Alas, I tried that [msvc/ifort comprehensive test] this weekend: somehow
> > CMake
> gets confused. I have stared at the error messages, but I can make heads nor
> tails
> of the cause.
> >
> > Here is what I did:
> >
> > 1. I added the directory containing MinGW-w64's sh.exe to the path, so
> > that
> the shell script would be run properly
>
> From your comprehensive_test_env.out file, your PATH (as understood by
> bash.exe) was as follows:
>
> PATH=/d/cmake3.4.3/bin:/usr/bin:/c/Program Files (x86)/Intel/Composer XE
> 2015/bin/intel64:/c/Program Files (x86)/Intel/Composer XE
> 2015/redist/intel64/compiler:/c/Program Files (x86)/Microsoft Visual Studio
> 12.0/Common7/IDE/CommonExtensions/Microsoft/TestWindow:/c/Program Files
> (x86)/MSBuild/12.0/bin/amd64:/c/Program Files
> (x86)/MSBuild/12.0/bin/amd64:/c/Program Files (x86)/Microsoft Visual Studio
> 12.0/VC/BIN/amd64:/c/WINDOWS/Microsoft.NET/Framework64/v4.0.30319:/c/Pro
> gram Files (x86)/Microsoft Visual Studio 12.0/VC/VCPackages:/c/Program Files
> (x86)/Microsoft Visual Studio 12.0/Common7/IDE:/c/Program Files
> (x86)/Microsoft
> Visual Studio 12.0/Common7/Tools:/c/Program Files (x86)/HTML Help
> Workshop:/c/Program Files (x86)/HTML Help Workshop:/c/Program Files
> (x86)/Microsoft Visual Studio 12.0/Team Tools/Performance Tools/x64:/c/Program
> Files (x86)/Microsoft Visual Studio 12.0/Team Tools/Performance
> Tools:/c/Program
> Files (x86)/Windows Kits/8.1/bin/x64:/c/Program Files (x86)/Windows
> Kits/8.1/bin/x86:/c/Program Files (x86)/Microsoft SDKs/Windows/v8.1A/bin/NETFX
> 4.5.1 Tools/x64:/c/Program Files (x86)/Intel/Composer XE
> 2015/redist/intel64/mkl:/c/Program Files (x86)/Intel/Composer XE
> 2015/redist/intel64/compiler:/c/ProgramData/Oracle/Java/javapath:/d/CAF/bin:/c/GT
> K/bin:/c/Program Files (x86)/MATLAB/MATLAB Compiler
> Runtime/v82/runtime/win32:/c/Program Files
> (x86)/Skype/Phone:/c/windows/system32:/c/windows:/c/Python27:/c/Python27/DLL
> s:/c/Python27/Scripts:/c/Program Files (x86)/pythonxy/console:/c/Program Files
> (x86)/pythonxy/gettext/bin:/c/MinGW32-xy/bin:/c/Program Files
> (x86)/pythonxy/SciTE-3.3.2-3:/c/Program Files
> (x86)/pythonxy/swig:/c/tcl/bin:/c/windows/system32:/c/Program Files
> (x86)/MiKTeX
> 2.9/miktex/bin:/c/Program Files (x86)/Intel/Composer XE
> 2015/redist/intel64/mpirt
>
> That's an extraordinarily complicated PATH. Is all that really necessary?
>
Quite possibly not, but in Windows these things tend to accumulate without an
easy way to reduce it. (Yes, I know, I can go into the "Advanced System
Properties" dialogue and the "Environment variables" bit, but the path is then
presented as a long long string in a tiny entry control. I do not know which of
these directories are really necessary, so that would require some
experimenting.)
> From
>
> SH_EXECUTABLE:FILEPATH=C:/msys64/usr/bin/bash.exe
>
> in shared/noninteractive/build_tree/CMakeCache.txt it appears that somehow you
> have indeed found the MinGW-w64/MSYS2 version of bash.exe yet
> C:/msys64/usr/bin is not on your PATH. For comprehensive testing you will
> likely
> need other things in C:/msys64/usr/bin so is there some issue with putting
> that
> PATH component last in your PATH? (Not first since you want MinGW-
> w64/MSYS2 versions to be the last resort and not the first resort.)
>
Should well be possible - it is just my habit to put such things first.
> Also, I noticed from shared/noninteractive/build_tree/CMakeCache.txt
> you are using D:/cmake3.4.3/bin/cmake.exe. Can you confirm that is indeed the
> ordinary Windows version of cmake that you should be using for
> MSVC/ifort/nmake
> that you can download from kitware rather than some MinGW-w64/MSYS2 version?
Yes, that is the version I use for building under MinGW-w64/MSYS2 as well
(actually copied the path from the build script I use for that configuration).
>
> >
> > 2. I invoked the script like this:
> >
> > ../plplot-git/scripts/comprehensive_test.sh --generator_string "NMake
> > Makefiles" -
> -do_clean_as_you_go yes --do_test_interactive no
> --do_test_traditional_install_tree
> yes --cmake_added_options "-DTCL_INCLUDE_PATH=/usr/include" --
> cmake_added_options "-DENABLE_ada=OFF -DENABLE_octave=OFF" --do_ctest
> no --build_command "nmake" --cmake_added_options "-
> DCMAKE_Fortran_COMPILER=ifort"
> >
> > to make sure the Intel Fortran compiler is selected ("NMake Makefiles" was
> > not
> enough). It took some experimenting ;).
>
> That invocation likely has two showstopper issues.
>
> 1. The option --cmake_added_options was specified three times with different
> values. The result was (see comprehensive_test.sh.out)
>
> --cmake_added_options
[Plplot-devel] comprehensive testing of MSVC/ifort/nmake
On 2016-03-14 07:35- Arjen Markus wrote:
> Alas, I tried that [msvc/ifort comprehensive test] this weekend: somehow
> CMake gets confused. I have stared at the error messages, but I can make
> heads nor tails of the cause.
>
> Here is what I did:
>
> 1. I added the directory containing MinGW-w64's sh.exe to the path, so
> that the shell script would be run properly
>From your comprehensive_test_env.out file, your PATH (as understood by
bash.exe) was as follows:
PATH=/d/cmake3.4.3/bin:/usr/bin:/c/Program Files (x86)/Intel/Composer XE
2015/bin/intel64:/c/Program Files (x86)/Intel/Composer XE
2015/redist/intel64/compiler:/c/Program Files (x86)/Microsoft Visual Studio
12.0/Common7/IDE/CommonExtensions/Microsoft/TestWindow:/c/Program Files
(x86)/MSBuild/12.0/bin/amd64:/c/Program Files
(x86)/MSBuild/12.0/bin/amd64:/c/Program Files (x86)/Microsoft Visual Studio
12.0/VC/BIN/amd64:/c/WINDOWS/Microsoft.NET/Framework64/v4.0.30319:/c/Program
Files (x86)/Microsoft Visual Studio 12.0/VC/VCPackages:/c/Program Files
(x86)/Microsoft Visual Studio 12.0/Common7/IDE:/c/Program Files (x86)/Microsoft
Visual Studio 12.0/Common7/Tools:/c/Program Files (x86)/HTML Help
Workshop:/c/Program Files (x86)/HTML Help Workshop:/c/Program Files
(x86)/Microsoft Visual Studio 12.0/Team Tools/Performance Tools/x64:/c/Program
Files (x86)/Microsoft Visual Studio 12.0/Team Tools/Performance
Tools:/c/Program Files (x86)/Windows Kits/8.1/bin/x64:/c/Program Files
(x86)/Windows Kits/8
.1/bin/x86:/c/Program Files (x86)/Microsoft SDKs/Windows/v8.1A/bin/NETFX 4.5.1
Tools/x64:/c/Program Files (x86)/Intel/Composer XE
2015/redist/intel64/mkl:/c/Program Files (x86)/Intel/Composer XE
2015/redist/intel64/compiler:/c/ProgramData/Oracle/Java/javapath:/d/CAF/bin:/c/GTK/bin:/c/Program
Files (x86)/MATLAB/MATLAB Compiler Runtime/v82/runtime/win32:/c/Program Files
(x86)/Skype/Phone:/c/windows/system32:/c/windows:/c/Python27:/c/Python27/DLLs:/c/Python27/Scripts:/c/Program
Files (x86)/pythonxy/console:/c/Program Files
(x86)/pythonxy/gettext/bin:/c/MinGW32-xy/bin:/c/Program Files
(x86)/pythonxy/SciTE-3.3.2-3:/c/Program Files
(x86)/pythonxy/swig:/c/tcl/bin:/c/windows/system32:/c/Program Files
(x86)/MiKTeX 2.9/miktex/bin:/c/Program Files (x86)/Intel/Composer XE
2015/redist/intel64/mpirt
That's an extraordinarily complicated PATH. Is all that really
necessary?
From
SH_EXECUTABLE:FILEPATH=C:/msys64/usr/bin/bash.exe
in shared/noninteractive/build_tree/CMakeCache.txt it appears
that somehow you have indeed found the MinGW-w64/MSYS2 version of bash.exe
yet C:/msys64/usr/bin is not on your PATH. For comprehensive testing
you will likely need other things in C:/msys64/usr/bin so is
there some issue with putting that PATH component last in your
PATH? (Not first since you want MinGW-w64/MSYS2 versions to
be the last resort and not the first resort.)
Also, I noticed from shared/noninteractive/build_tree/CMakeCache.txt
you are using D:/cmake3.4.3/bin/cmake.exe. Can you confirm that is
indeed the ordinary Windows version of cmake that you should be using
for MSVC/ifort/nmake that you can download
from kitware rather than some MinGW-w64/MSYS2 version?
>
> 2. I invoked the script like this:
>
> ../plplot-git/scripts/comprehensive_test.sh --generator_string "NMake
> Makefiles" --do_clean_as_you_go yes --do_test_interactive no
> --do_test_traditional_install_tree yes --cmake_added_options
> "-DTCL_INCLUDE_PATH=/usr/include" --cmake_added_options "-DENABLE_ada=OFF
> -DENABLE_octave=OFF" --do_ctest no --build_command "nmake"
> --cmake_added_options "-DCMAKE_Fortran_COMPILER=ifort"
>
> to make sure the Intel Fortran compiler is selected ("NMake Makefiles" was
> not enough). It took some experimenting ;).
That invocation likely has two showstopper issues.
1. The option --cmake_added_options was specified three times with
different values. The result was (see comprehensive_test.sh.out)
--cmake_added_options "-DCMAKE_Fortran_COMPILER=ifort"
i.e., only the last specified value was honored.
Instead you should use that option only once, e.g.,
--cmake_added_options "-DTCL_INCLUDE_PATH=/usr/include -DENABLE_ada=OFF
-DENABLE_octave=OFF"
Note, in this example I have dropped -DCMAKE_Fortran_COMPILER=ifort
because it is problematic, see 2.
2. That added option -DCMAKE_Fortran_COMPILER=ifort is problematic
since it does not get propagated properly to the soft landing
workaround for Fortran. So in that soft-landing workaround mode a
non-intel compiler was checked (and was working). Because of that
success it then tried the Intel compiler for real which had a crash
landing (cmake errored out). To avoid this inconsistency issue
between soft-landing mode and real mode I suggest you use the
well-debugged environment variable method of specifying the compiler,
i.e.,
export FC=ifort
which will test that compiler in soft-landing mode and only try it for
real if the soft-landing mode has a success. And if the soft-landing
mode fails,
