Hi Alan,
I will try this new approach rightaway. This is an obscure bug indeed. > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] > > 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. > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
