On 2007-10-26 00:51-0400 Jim Dishaw wrote: > "Alan W. Irwin" <[EMAIL PROTECTED]> writes: > >> Hi Jim, >> >> This post covers one final topic generated by your e-mail. >> >> On 2007-10-25 19:53-0400 Jim Dishaw wrote: >> >>> $ cmake -DBUILD_SHARED_LIBS=ON -DENABLE_DYNDRIVERS=OFF >>> -DCMAKE_VERBOSE_MAKEFILE=ON -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON >>> -DDEFAULT_NO_BINDINGS=ON >>> /cygdrive/m/software/source/scientific/plplot-svn >>> >>> The output files are attached. I didn't bother to do the second test >>> because the first one failed. >> >> So what happens with this simple test if you properly select your compiler >> using CC=gcc (or should that be CC=/usr/bin/gcc.exe ?) > > I did the test without Intel's or Microsoft's compilers in the path. > The /Zl still remains. I did find the cause of it--it is my fault. I > modified the UserOverride.cmake to add the /Zl in order to get the > libraries to work correctly with the Microsoft compilers. My bad.
No problem. I am glad you figured it out. So now that you can get the -DENABLE_DYNDRIVERS=OFF case to work with gcc what happens for the much more interesting -DENABLE_DYNDRIVERS=ON case? > > The issue with Intel Fortran and Cygwin: > > - The Unix style path is being interpreted by the compiler as compiler > switches, which causes the compiler to fail. In the e-mail I just posted, I gave a really simple example of that ifort test that I would like you to execute. Please send me the complete example (CMakeList.txt, hello_world.f, and the failing cmake.out with ifort specified with the FC variable) to pass on to the CMake list to see what they recommend to fix the problem. I suspect it will be a straightforward fix of CMake (one added configuration file) so providing that complete test result for the CMake list should be worth your while. > > The above issue reveals the following problem with cmake > > - When the Fortran compiler test fails when running cmake, the Fortran > bindings should not be enabled. Currently, running cmake a second > time will leave the Fortran bindings on. I have never felt comfortable running cmake twice in the same build tree without removing everything in between. There is just too much possibility of stale results from the first cmake run tainting the second run (as you have just discovered). I think we already suggest in the documentation that cmake should only be executed in an empty build tree for this very reason. > > In the documentation we should state: > > If the build system has multiple compilers installed and visible in the > executable search path, you must specify the compilers with the > appropriate environment variables, e.g. FC and CC. Good point. Anybody can change the wiki (although there is some protection from spammers because anybody doing editing must subscribe first from a valid e-mail address). Anyhow, I suggest you do such editing of the wiki based on your recent experience. Such editing often needs a fresh eye since those like myself who have worked with PLplot for many years may forget something essential that they subconsciously discount as "obvious". > > When building with different compilers, always start with a clean build > directory. That happens automatically if you follow the rule to always execute cmake in an empty build tree. BTW, PLplot developers often end up changing some CMake configuration file in the source tree. In that case you will find that re-running the "make" command in the build tree automatically reruns cmake in the build tree to account for your change. I find that case of re-running cmake normally has no problems (presumably because no compiler choosing environment variables were changed between the make commands, and the options of the cmake command that is rerun by make are identical to those of the original cmake command.) However, at the end of what is usually a series of changes, I normally like to start all over with an empty build tree for a final check of my complete set of changes. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
