On 2016-11-30 07:54-0000 Arjen Markus wrote: > Yes, [dashboard submission] turned out to be easier than I thought. My first run failed because I had forgotten to adjust the path before running ctest -D Experimental. (I was misled by the term "dashboard" which seems to have several different meanings in modern computespeak.)
> I am a bit puzzled though about the compiler errors - qhull/qhull_a.h not found. I had not seen that before. Checking the code and my installation: > The include directory for Qhull is libqhull - in previous/ordinary builds this was selected via the macro HAS_LIBQHULL_INCLUDE. Hi Arjen: This is a most interesting result that puzzled me for a long while until I believe I have now found the solution. I agree with your conclusion that HAS_LIBQHULL_INCLUDE was not being set correctly. After a lot of staring at the CMake logic in our build system I finally spotted a bug that would occur any time HAS_LIBQHULL_INCLUDE was true (your case) and you were running cmake a second time (which happens as a result of ctest -D Experimental, see below). I believe I have now fixed this bug (see commit 8dfff8a) so please try submitting a dashboard again. Note from my further reading of the documentation ctest -D Experimental should be equivalent to Make Experimental which builds the following targets in this exact order (again from the documentation). ExperimentalStart ExperimentalConfigure ExperimentalBuild ExperimentalCoverage ExperimentalTest ExperimentalSubmit (The coverage part is ignored because we don't have any support for coverage in our build system.) Anyhow, building the above subtargets (so long as you remember to do them in the above order because apparently there are no dependencies between them to enforce the correct order) can be used to do everything required to prepare a dashboard and optionally submit it. This allows you to watch results being accumulated in the Testing subdirectory for each of those subtargets if you are trying to diagnose an issue. I did that here, and ExperimentalConfigure does what its name implies and reruns cmake. For your particular platform where HAS_LIBQHULL_INCLUDE is ON on the first cmake run, this subsequent run would set it (incorrectly) to OFF until I fixed the CMake logic bug as above. So your dashboard submission has already been quite a success since it uncovered a build-system bug that has been with us for a while. I am actually surprised you have never run into this issue on Cygwin before. Because all you would have to do to generate a subsequent CMake run and the resulting broken build is to edit any of our build-system code and continue on with another build with a dirty cache. But as I recall you did not have libqhull installed for a long time on your Cygwin platform so that may explain why you have never seen this issue before. Come to think of it, perhaps we have been plagued with a lot of these stale cached variable bugs in the past which has lead me to the possibly incorrect conclusion we should always start fresh with an empty build tree. So from now on I am going to continue with a stale cache for a while as I continue to develop PLplot to see how far I get (and to see if any other stale cached variable errors like you just discovered turn up). And, of course, my previously successful dashboard submissions did involve a stale cache so perhaps such bugs are quite rare now in our build-system logic. For example, I only had the qhull form of the header here so this bug did not affect me at all. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
