Hi Ed: On 2010-01-12 16:56+0800 Ed Zaron wrote:
> > Hi All, > > I'm having trouble building the ocaml bindings from the latest plplot in > the svn repository. > > This is on a recent Ubuntu/Debian linux. And it seems to be a makefile > problem. > > Has anyone seen errors like this from "make build"? > > Scanning dependencies of target target_lib_plplot_stubs > make[2]: Circular bindings/ocaml/plplot_core.idl <- > bindings/ocaml/plplot_core.idl dependency dropped. > [ 21%] Generating plplot_core.idl, plplot_core.h, plplot_core.ml, > plplot_core.mli, plplot_core_stubs.c > Error copying file (if different) from > "/home/ezaron/plplot/bindings/ocaml/plplot_core.idl" to > "/home/ezaron/plplot/bindings/ocaml/plplot_core.idl". > make[2]: *** [bindings/ocaml/plplot_core.idl] Error 1 > make[1]: *** [bindings/ocaml/CMakeFiles/target_lib_plplot_stubs.dir/all] > Error 2 > make: *** [all] Error 2 Thanks for your report. I think you have caught a pervasive bug in our build system for the case where the build tree is identical to the source tree. For some time now, I have assumed CMake's copy-if-different would work fine (i.e., would take no action) if the build tree was identical to the source tree (as in your case) so that no copying from source tree to build tree would be required. But from your error report it looks like copy-if-different does not work the way I had assumed, and instead tries to do something circular for this case. The workaround I suggest for you now is to use a separate build tree, i.e., do _not_ use "cmake .". "cmake some_other_directory" should be fine. Note, however, that once you have done "cmake ." it permanently messes up the source tree and does not allow you to use a separate build tree. So you must remove the contaminated source tree completely and start over with a svn checkout before you attempt further builds using a separate build tree. Frankly, separate build trees are really convenient since all you have to do to get a fresh start is to remove the tree without worrying that you are also removing source. So separate build trees are mostly all that we test. But now you have drawn my attention to the issue, I will try to solve it. 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 the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
