Thanks Alan, I understand now. I'm new to cmake and didn't understand the importance of the separate build tree.
I will do as you suggested. Thanks very much! Regards, Ed Alan W. Irwin wrote: > 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 > __________________________ -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Edward D. Zaron Research Assistant Professor Department of Civil and Environmental Engineering Portland State University Portland, OR 97207-0751 Phone: (503)-725-2435 FAX: (503)-725-5950 za...@cecs.pdx.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------------------------------ 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
