Re: [CMake] ANN: UseOcaml.cmake
congratulations! :) please let me know when you have completed your scripts, so that i can replace mine with your in the yars refactoring tree. cheers, keyan On 26 Jan 2010, at 22:53, Judicaël Bedouet wrote: Thanks for your help. It is solved. A dependency between custom targets was missing. In fact, the dependency was just between the custom command outputs and I didn't think that setting a dependency between custom targets would have solved the problem. I also have had to generate objects in separate directories (a directory per target). Indeed, in the example of Keyan, some files are compiled twice and there is no dependency between the two targets. So, if I compile all files in the same directory, a file may be compiled and used in a link command at the same time. It is a much more complex with separate directories and I have to revise ocamldep output but it works. I don't have so much time for the moment but I will take a look at your CMake files as soon as possible to test and improve my scripts. Thanks, J. Bedouet 2010/1/26 Alan W. Irwin ir...@beluga.phys.uvic.ca On 2010-01-26 00:28+0100 Judicaël Bedouet wrote: I see one solution : add a macro to create an only target with all OCaml libraries and executables, but it's not perfect. This issue should be straighforward to solve with proper dependencies for _both_ custom targets and custom command OUTPUT files. We have our own independent method of compiling OCaml libraries and executables which takes care of such dependency issues correctly. See http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/bindings/ocaml/CMakeLists.txt?view=log, http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/bindings/ocaml/plcairo/CMakeLists.txt?view=log, and http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/examples/ocaml/CMakeLists.txt?view=log. Our method is pretty brute force (a series of add_custom commands and add_custom targets) so we are open to adopting something different if this current thread results in something that ultimately ends up as part of a CMake release. Note, our current method does work fine for parallel builds. Thus, it should also be straightforward to make parallel builds work properly for any other method of building ocaml libraries and apps if the necessary target and file dependencies are handled correctly. 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 __ ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ANN: UseOcaml.cmake
Hi, I think I have found the problem. It's in the structure of the Makefile generated by CMake. For each target, make is called on a sub Makefile and this is problematic for OCaml. I have reproduced the problem with an handwritten Makefile (see attachment). Try make -j all2 and make -j all1. The first command will always work whereas the second, with recursive calls to make, will fail sometimes. Recursive Makefiles with OCaml seem to be incompatible with parallel make. In OCaml, each object depends on others. If two targets depend on io.cmx and if make is launched in parallel on these two targets, the file io.cmx will be built twice. And if the first make command builds the object whereas the second tries to link the executable at the same time, the link command will fail because the object is being corrupted. I think it's only a problem for OCaml. In C or C++, objects only depend on sources, and not on objects previously compiled. Do you agree with this explanation ? I see one solution : add a macro to create an only target with all OCaml libraries and executables, but it's not perfect. Bye, J. Bedouet 2010/1/22 Keyan m...@pulsschlag.net hi, i didnt have much time lately to look deeply into the scripts. at first i thought that one has to add some add_dependencies, which was my first strategy, before i wrote useocaml.cmake. but then i saw, that i removed them, because i got the DEPENDS right. so my guess was wrong. what you write seems plausible. i got the messages with your script when i compiled with make -j 2 while my computer was busy. for some reason i didnt get them with my scripts yet, which could just be by chance. i do not know how to proceed from here on. anyone got an idea? cheers, keyan On 22 Jan 2010, at 02:16, Judicaël Bedouet wrote: Hello, I try to compare Makefiles generated by your scripts and mine. I don't see any big differences, except the copy rules. While trying your scripts, I also reproduced a similar bug. Generating file_node.cmx Generating message_node.cmi Generating file_node.cmi File /Users/judi/src/ocaml/cmake/ code-analysis/build/file_node.ml, line 1, characters 0-1: Error: Corrupted compiled interface file_node.cmi make[2]: *** [file_node.cmx] Error 2 Try with while true; do make clean; make -j; done and you will reproduce it. I think dependencies in our scripts are good (or almost good). The reason may be elsewhere. I don't see a solution yet but I have found a promising lead. When two targets depends on the same object, make tries to build the object twice. If make builds the same object twice at the same time, the command 'cmake -E copy_if_different' may be called at the same time and one of the cmake command fails because it can't open the file. I suppose it's the reason of Error copying file (if different) from [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake.tmp to [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake. In your code, the loc and messages executables depends both on io.cmo. Sometimes, it tries to link loc and build io.cmo (probably for messages) at the same time. I suppose it's the reason of Building OCaml object io.cmo Building OCaml object files.cmo [ 0%] Linking OCaml executable loc File _none_, line 1, characters 0-1: Error: The file /Users/judi/src/ocaml/cmake/code-analysis/build/io.cmo is not a bytecode object file I add a third target which depends on io.cmo (create a common library and make loc and messages depend on this library). It appears that make tries to build the object io.cmo three times and build fails are almost systematic. If you keep only one target, there is never no problems. An idea ? Too late in the night for me :-( Bye, J. Bedouet 2010/1/20 Keyan m...@pulsschlag.net hi, i started to work on your scripts. very nice work! unfortunately, i couldnt find the problem, and i cant reproduce it with my scripts. there must be a difference somewhere. cheers, keyan On 19 Jan 2010, at 00:30, Judicaël Bedouet wrote: Hi, Effectively, I have reproduced your two bugs by using make -j. It's not systematic (once in ten). Error: The file /Users/zahedi/Downloads/code-analysis-build/io.cmo is not a bytecode object file When this error occurs, it also appears that the object is being built. And if I rerun make, linking is correct, without rebuilding io.cmo. Building OCaml object io.cmo Building OCaml object files.cmo [ 0%] Linking OCaml executable loc File _none_, line 1, characters 0-1: Error: The file /Users/judi/src/ocaml/cmake/code-analysis/build/io.cmo is not a bytecode object file Dependencies in the generated Makefile seem to be correct : loc: file_node.cmo loc: files.cmo loc: io.cmo loc: file_statistics.cmo loc: message_node.cmo loc: loc.cmo Is OCaml
Re: [CMake] ANN: UseOcaml.cmake
On 2010-01-26 00:28+0100 Judicaël Bedouet wrote: I see one solution : add a macro to create an only target with all OCaml libraries and executables, but it's not perfect. This issue should be straighforward to solve with proper dependencies for _both_ custom targets and custom command OUTPUT files. We have our own independent method of compiling OCaml libraries and executables which takes care of such dependency issues correctly. See http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/bindings/ocaml/CMakeLists.txt?view=log, http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/bindings/ocaml/plcairo/CMakeLists.txt?view=log, and http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/examples/ocaml/CMakeLists.txt?view=log. Our method is pretty brute force (a series of add_custom commands and add_custom targets) so we are open to adopting something different if this current thread results in something that ultimately ends up as part of a CMake release. Note, our current method does work fine for parallel builds. Thus, it should also be straightforward to make parallel builds work properly for any other method of building ocaml libraries and apps if the necessary target and file dependencies are handled correctly. 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 __ ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ANN: UseOcaml.cmake
Hello, I try to compare Makefiles generated by your scripts and mine. I don't see any big differences, except the copy rules. While trying your scripts, I also reproduced a similar bug. Generating file_node.cmx Generating message_node.cmi Generating file_node.cmi File /Users/judi/src/ocaml/cmake/ code-analysis/build/file_node.ml, line 1, characters 0-1: Error: Corrupted compiled interface file_node.cmi make[2]: *** [file_node.cmx] Error 2 Try with while true; do make clean; make -j; done and you will reproduce it. I think dependencies in our scripts are good (or almost good). The reason may be elsewhere. I don't see a solution yet but I have found a promising lead. When two targets depends on the same object, make tries to build the object twice. If make builds the same object twice at the same time, the command 'cmake -E copy_if_different' may be called at the same time and one of the cmake command fails because it can't open the file. I suppose it's the reason of Error copying file (if different) from [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake.tmp to [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake. In your code, the loc and messages executables depends both on io.cmo. Sometimes, it tries to link loc and build io.cmo (probably for messages) at the same time. I suppose it's the reason of Building OCaml object io.cmo Building OCaml object files.cmo [ 0%] Linking OCaml executable loc File _none_, line 1, characters 0-1: Error: The file /Users/judi/src/ocaml/cmake/code-analysis/build/io.cmo is not a bytecode object file I add a third target which depends on io.cmo (create a common library and make loc and messages depend on this library). It appears that make tries to build the object io.cmo three times and build fails are almost systematic. If you keep only one target, there is never no problems. An idea ? Too late in the night for me :-( Bye, J. Bedouet 2010/1/20 Keyan m...@pulsschlag.net hi, i started to work on your scripts. very nice work! unfortunately, i couldnt find the problem, and i cant reproduce it with my scripts. there must be a difference somewhere. cheers, keyan On 19 Jan 2010, at 00:30, Judicaël Bedouet wrote: Hi, Effectively, I have reproduced your two bugs by using make -j. It's not systematic (once in ten). Error: The file /Users/zahedi/Downloads/code-analysis-build/io.cmo is not a bytecode object file When this error occurs, it also appears that the object is being built. And if I rerun make, linking is correct, without rebuilding io.cmo. Building OCaml object io.cmo Building OCaml object files.cmo [ 0%] Linking OCaml executable loc File _none_, line 1, characters 0-1: Error: The file /Users/judi/src/ocaml/cmake/code-analysis/build/io.cmo is not a bytecode object file Dependencies in the generated Makefile seem to be correct : loc: file_node.cmo loc: files.cmo loc: io.cmo loc: file_statistics.cmo loc: message_node.cmo loc: loc.cmo Is OCaml parallel make safe ? I'm not sure... I readd CMake address : maybe someone has an idea... To speed up compilation, I could look for ocamlc.opt and if not found ocamlc. Bytecode compilations should be faster. J. Bedouet 2010/1/18 Keyan m...@pulsschlag.net hi, i am just trying to reproduce the message i posted. i cant, but i got something else: Error: The file /Users/zahedi/Downloads/code-analysis-build/io.cmo is not a bytecode object file i use make -j 2 (at least 2), and my guess is that it has to do with parallel compilation. could that be the case? cheers, keyan On 18 Jan 2010, at 18:01, Judicaël Bedouet wrote: Hi, first of all, wow, good job! very nice scripts, much more sophisticated then mine :) Thanks :-) I only had one error when first trying: Error copying file (if different) from [...]/code-analysis-build/Dependencies /message_node.ml.dep.cmake.tmp to [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake. Maybe the Dependencies directory is not created. It is done at line 32 of OCamlDep, though. Let me know if you find something. I have tested my scripts with OCaml 3.10 and I have found that ocamlfind is officially distributed with OCaml since 3.11. Maybe, I should put ocamlfind stuff in a FindOCamlFind script... J. Bedouet 2010/1/18 Keyan m...@pulsschlag.net Hi, i am sorry that i could not reply any sooner. first of all, wow, good job! very nice scripts, much more sophisticated then mine :) i only had one error when first trying: Error copying file (if different) from [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake.tmp to [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake. i will try to solve that myself. this way i know if i understand your scripts. cheers, keyan On 16 Jan 2010, at 14:51, Judicaël Bedouet wrote:
Re: [CMake] ANN: UseOcaml.cmake
hi, i started to work on your scripts. very nice work! unfortunately, i couldnt find the problem, and i cant reproduce it with my scripts. there must be a difference somewhere. cheers, keyan On 19 Jan 2010, at 00:30, Judicaël Bedouet wrote: Hi, Effectively, I have reproduced your two bugs by using make -j. It's not systematic (once in ten). Error: The file /Users/zahedi/Downloads/code-analysis-build/io.cmo is not a bytecode object file When this error occurs, it also appears that the object is being built. And if I rerun make, linking is correct, without rebuilding io.cmo. Building OCaml object io.cmo Building OCaml object files.cmo [ 0%] Linking OCaml executable loc File _none_, line 1, characters 0-1: Error: The file /Users/judi/src/ocaml/cmake/code-analysis/build/io.cmo is not a bytecode object file Dependencies in the generated Makefile seem to be correct : loc: file_node.cmo loc: files.cmo loc: io.cmo loc: file_statistics.cmo loc: message_node.cmo loc: loc.cmo Is OCaml parallel make safe ? I'm not sure... I readd CMake address : maybe someone has an idea... To speed up compilation, I could look for ocamlc.opt and if not found ocamlc. Bytecode compilations should be faster. J. Bedouet 2010/1/18 Keyan m...@pulsschlag.net hi, i am just trying to reproduce the message i posted. i cant, but i got something else: Error: The file /Users/zahedi/Downloads/code-analysis-build/io.cmo is not a bytecode object file i use make -j 2 (at least 2), and my guess is that it has to do with parallel compilation. could that be the case? cheers, keyan On 18 Jan 2010, at 18:01, Judicaël Bedouet wrote: Hi, first of all, wow, good job! very nice scripts, much more sophisticated then mine :) Thanks :-) I only had one error when first trying: Error copying file (if different) from [...]/code-analysis-build/Dependencies /message_node.ml.dep.cmake.tmp to [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake. Maybe the Dependencies directory is not created. It is done at line 32 of OCamlDep, though. Let me know if you find something. I have tested my scripts with OCaml 3.10 and I have found that ocamlfind is officially distributed with OCaml since 3.11. Maybe, I should put ocamlfind stuff in a FindOCamlFind script... J. Bedouet 2010/1/18 Keyan m...@pulsschlag.net Hi, i am sorry that i could not reply any sooner. first of all, wow, good job! very nice scripts, much more sophisticated then mine :) i only had one error when first trying: Error copying file (if different) from [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake.tmp to [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake. i will try to solve that myself. this way i know if i understand your scripts. cheers, keyan On 16 Jan 2010, at 14:51, Judicaël Bedouet wrote: Hi, Here are my OCaml scripts, with your OCaml code (it helped me to find a bug about a source file included in two targets). I have kept your idea about an only macro to compile and link, reused your macro ocaml_parse_arguments (I should use for my other macros :-) ) and added a macro find_ocaml_package to find ocaml packages with ocamlfind. Tell me what you think, J. Bedouet 2010/1/15 Keyan m...@pulsschlag.net hi, Indeed, it is much more sophisticated, so it may be more bugged ;-) i can help debugging :) shell i send you my scripts to take a look? It's not necessary. I have downloaded the refactoring branch of yars. Thanks. oh, ok, then you should have the newest version (last yars revision is 513). I comment my OCaml scripts and I send you, so that you could also have a look. great. I have took a look at your UseOCaml script. I can't see why you copy ML files into the current binary dir before compiling them. Is there a reason ? no. i copied most of the stuff from the UseLATEX.cmake. it was done so there, and at the time i wrote the script, i thought its a good idea. don't ask me why :) Keep in touch, let me know when i can jump in and help. looking forward. cheers, keyan J. Bedouet On Fri, Jan 15, 2010 at 8:26 AM, Keyan m...@pulsschlag.net wrote: I totally agree. Judicaël: how should we proceed? my first impression is that your usecaml.cmake is much more sophisticated then mine :) same for the findocaml.cmake scripts, as mine up to now does nothing more than to call a bunch of find_program commands. shell i send you my scripts to take a look? i have no problem with merging my stuff into your scripts, keeping you as main author, if there is anything useful for you. cheers, keyan On 15 Jan 2010, at 02:39, Philip Lowman wrote:
Re: [CMake] ANN: UseOcaml.cmake
The reason the UseLATEX.cmake script copies files to the binary directory is
because the latex compiler has no equivalent to the -I flag. It always looks
for files with respect to the directory in which the command was run. Thus,
the easiest way to do an out-of-source build is to simply copy the source over
to the binary directory. If the ML compiler has a way of specifying a list of
directories from which to find included files, you are much better off
compiling the original source file directly.
-Ken
On 1/15/10 9:28 AM, Keyan m...@pulsschlag.net wrote:
I have took a look at your UseOCaml script. I can't see why you copy ML files
into the current binary dir before compiling them. Is there a reason ?
no. i copied most of the stuff from the UseLATEX.cmake. it was done so there,
and at the time i wrote the script, i thought its a good idea. don't ask me why
:)
Kenneth Moreland
*** Sandia National Laboratories
***
*** *** *** email: kmo...@sandia.gov
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ANN: UseOcaml.cmake
thanks for the explanation. i hope you didnt feel offended. the uselatex.cmake is great. without that, i wouldn't even had a clue where to start :) cheers, keyan On 18 Jan 2010, at 17:12, Moreland, Kenneth wrote: The reason the UseLATEX.cmake script copies files to the binary directory is because the latex compiler has no equivalent to the –I flag. It always looks for files with respect to the directory in which the command was run. Thus, the easiest way to do an out-of-source build is to simply copy the source over to the binary directory. If the ML compiler has a way of specifying a list of directories from which to find included files, you are much better off compiling the original source file directly. -Ken On 1/15/10 9:28 AM, Keyan m...@pulsschlag.net wrote: I have took a look at your UseOCaml script. I can't see why you copy ML files into the current binary dir before compiling them. Is there a reason ? no. i copied most of the stuff from the UseLATEX.cmake. it was done so there, and at the time i wrote the script, i thought its a good idea. don't ask me why :) Kenneth Moreland *** Sandia National Laboratories *** *** *** *** email: kmo...@sandia.gov ** *** ** phone: (505) 844-8919 *** web: http://www.cs.unm.edu/~kmorel ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ANN: UseOcaml.cmake
Hi, Effectively, I have reproduced your two bugs by using make -j. It's not systematic (once in ten). Error: The file /Users/zahedi/Downloads/code-analysis-build/io.cmo is not a bytecode object file When this error occurs, it also appears that the object is being built. And if I rerun make, linking is correct, without rebuilding io.cmo. Building OCaml object io.cmo Building OCaml object files.cmo [ 0%] Linking OCaml executable loc File _none_, line 1, characters 0-1: Error: The file /Users/judi/src/ocaml/cmake/code-analysis/build/io.cmo is not a bytecode object file Dependencies in the generated Makefile seem to be correct : loc: file_node.cmo loc: files.cmo loc: io.cmo loc: file_statistics.cmo loc: message_node.cmo loc: loc.cmo Is OCaml parallel make safe ? I'm not sure... I readd CMake address : maybe someone has an idea... To speed up compilation, I could look for ocamlc.opt and if not found ocamlc. Bytecode compilations should be faster. J. Bedouet 2010/1/18 Keyan m...@pulsschlag.net hi, i am just trying to reproduce the message i posted. i cant, but i got something else: Error: The file /Users/zahedi/Downloads/code-analysis-build/io.cmo is not a bytecode object file i use make -j 2 (at least 2), and my guess is that it has to do with parallel compilation. could that be the case? cheers, keyan On 18 Jan 2010, at 18:01, Judicaël Bedouet wrote: Hi, first of all, wow, good job! very nice scripts, much more sophisticated then mine :) Thanks :-) I only had one error when first trying: Error copying file (if different) from [...]/code-analysis-build/Dependencies /message_node.ml.dep.cmake.tmp to [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake. Maybe the Dependencies directory is not created. It is done at line 32 of OCamlDep, though. Let me know if you find something. I have tested my scripts with OCaml 3.10 and I have found that ocamlfind is officially distributed with OCaml since 3.11. Maybe, I should put ocamlfind stuff in a FindOCamlFind script... J. Bedouet 2010/1/18 Keyan m...@pulsschlag.net Hi, i am sorry that i could not reply any sooner. first of all, wow, good job! very nice scripts, much more sophisticated then mine :) i only had one error when first trying: Error copying file (if different) from [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake.tmp to [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake. i will try to solve that myself. this way i know if i understand your scripts. cheers, keyan On 16 Jan 2010, at 14:51, Judicaël Bedouet wrote: Hi, Here are my OCaml scripts, with your OCaml code (it helped me to find a bug about a source file included in two targets). I have kept your idea about an only macro to compile and link, reused your macro ocaml_parse_arguments (I should use for my other macros :-) ) and added a macro find_ocaml_package to find ocaml packages with ocamlfind. Tell me what you think, J. Bedouet 2010/1/15 Keyan m...@pulsschlag.net hi, Indeed, it is much more sophisticated, so it may be more bugged ;-) i can help debugging :) shell i send you my scripts to take a look? It's not necessary. I have downloaded the refactoring branch of yars. Thanks. oh, ok, then you should have the newest version (last yars revision is 513). I comment my OCaml scripts and I send you, so that you could also have a look. great. I have took a look at your UseOCaml script. I can't see why you copy ML files into the current binary dir before compiling them. Is there a reason ? no. i copied most of the stuff from the UseLATEX.cmake. it was done so there, and at the time i wrote the script, i thought its a good idea. don't ask me why :) Keep in touch, let me know when i can jump in and help. looking forward. cheers, keyan J. Bedouet On Fri, Jan 15, 2010 at 8:26 AM, Keyan m...@pulsschlag.net wrote: I totally agree. Judicaël: how should we proceed? my first impression is that your usecaml.cmake is much more sophisticated then mine :) same for the findocaml.cmake scripts, as mine up to now does nothing more than to call a bunch of find_program commands. shell i send you my scripts to take a look? i have no problem with merging my stuff into your scripts, keeping you as main author, if there is anything useful for you. cheers, keyan On 15 Jan 2010, at 02:39, Philip Lowman wrote: On Thu, Jan 14, 2010 at 5:11 AM, Keyan m...@pulsschlag.net wrote: hi, ups ... i thought i replied to the list. thanks for the link. i will adapt my find-script to the requirements and maintain the package. You should work with Judicaël to combine the best of both of your works together into one FindOCaml and UseOCaml script. There is no
Re: [CMake] ANN: UseOcaml.cmake
hi, i had the same problems before i wrote my useocaml.cmake. actually, that was the main reasons for writing it. i solved the problems by getting all the depencies right. my guess is, that a few additional add_depencies will solve the problem. as soon as i have a little bit time, i will check the script and see what i can do. cheers, keyan On 19 Jan 2010, at 00:30, Judicaël Bedouet wrote: Hi, Effectively, I have reproduced your two bugs by using make -j. It's not systematic (once in ten). Error: The file /Users/zahedi/Downloads/code-analysis-build/io.cmo is not a bytecode object file When this error occurs, it also appears that the object is being built. And if I rerun make, linking is correct, without rebuilding io.cmo. Building OCaml object io.cmo Building OCaml object files.cmo [ 0%] Linking OCaml executable loc File _none_, line 1, characters 0-1: Error: The file /Users/judi/src/ocaml/cmake/code-analysis/build/io.cmo is not a bytecode object file Dependencies in the generated Makefile seem to be correct : loc: file_node.cmo loc: files.cmo loc: io.cmo loc: file_statistics.cmo loc: message_node.cmo loc: loc.cmo Is OCaml parallel make safe ? I'm not sure... I readd CMake address : maybe someone has an idea... To speed up compilation, I could look for ocamlc.opt and if not found ocamlc. Bytecode compilations should be faster. J. Bedouet 2010/1/18 Keyan m...@pulsschlag.net hi, i am just trying to reproduce the message i posted. i cant, but i got something else: Error: The file /Users/zahedi/Downloads/code-analysis-build/io.cmo is not a bytecode object file i use make -j 2 (at least 2), and my guess is that it has to do with parallel compilation. could that be the case? cheers, keyan On 18 Jan 2010, at 18:01, Judicaël Bedouet wrote: Hi, first of all, wow, good job! very nice scripts, much more sophisticated then mine :) Thanks :-) I only had one error when first trying: Error copying file (if different) from [...]/code-analysis-build/Dependencies /message_node.ml.dep.cmake.tmp to [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake. Maybe the Dependencies directory is not created. It is done at line 32 of OCamlDep, though. Let me know if you find something. I have tested my scripts with OCaml 3.10 and I have found that ocamlfind is officially distributed with OCaml since 3.11. Maybe, I should put ocamlfind stuff in a FindOCamlFind script... J. Bedouet 2010/1/18 Keyan m...@pulsschlag.net Hi, i am sorry that i could not reply any sooner. first of all, wow, good job! very nice scripts, much more sophisticated then mine :) i only had one error when first trying: Error copying file (if different) from [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake.tmp to [...]/code-analysis-build/Dependencies/message_node.ml.dep.cmake. i will try to solve that myself. this way i know if i understand your scripts. cheers, keyan On 16 Jan 2010, at 14:51, Judicaël Bedouet wrote: Hi, Here are my OCaml scripts, with your OCaml code (it helped me to find a bug about a source file included in two targets). I have kept your idea about an only macro to compile and link, reused your macro ocaml_parse_arguments (I should use for my other macros :-) ) and added a macro find_ocaml_package to find ocaml packages with ocamlfind. Tell me what you think, J. Bedouet 2010/1/15 Keyan m...@pulsschlag.net hi, Indeed, it is much more sophisticated, so it may be more bugged ;-) i can help debugging :) shell i send you my scripts to take a look? It's not necessary. I have downloaded the refactoring branch of yars. Thanks. oh, ok, then you should have the newest version (last yars revision is 513). I comment my OCaml scripts and I send you, so that you could also have a look. great. I have took a look at your UseOCaml script. I can't see why you copy ML files into the current binary dir before compiling them. Is there a reason ? no. i copied most of the stuff from the UseLATEX.cmake. it was done so there, and at the time i wrote the script, i thought its a good idea. don't ask me why :) Keep in touch, let me know when i can jump in and help. looking forward. cheers, keyan J. Bedouet On Fri, Jan 15, 2010 at 8:26 AM, Keyan m...@pulsschlag.net wrote: I totally agree. Judicaël: how should we proceed? my first impression is that your usecaml.cmake is much more sophisticated then mine :) same for the findocaml.cmake scripts, as mine up to now does nothing more than to call a bunch of find_program commands. shell i send you my scripts to take a look? i have no problem with merging my stuff into your scripts,
Re: [CMake] ANN: UseOcaml.cmake
Indeed, it is much more sophisticated, so it may be more bugged ;-) shell i send you my scripts to take a look? It's not necessary. I have downloaded the refactoring branch of yars. Thanks. I comment my OCaml scripts and I send you, so that you could also have a look. I have took a look at your UseOCaml script. I can't see why you copy ML files into the current binary dir before compiling them. Is there a reason ? Keep in touch, J. Bedouet On Fri, Jan 15, 2010 at 8:26 AM, Keyan m...@pulsschlag.net wrote: I totally agree. Judicaël: how should we proceed? my first impression is that your usecaml.cmake is much more sophisticated then mine :) same for the findocaml.cmake scripts, as mine up to now does nothing more than to call a bunch of find_program commands. shell i send you my scripts to take a look? i have no problem with merging my stuff into your scripts, keeping you as main author, if there is anything useful for you. cheers, keyan On 15 Jan 2010, at 02:39, Philip Lowman wrote: On Thu, Jan 14, 2010 at 5:11 AM, Keyan m...@pulsschlag.net wrote: hi, ups ... i thought i replied to the list. thanks for the link. i will adapt my find-script to the requirements and maintain the package. You should work with Judicaël to combine the best of both of your works together into one FindOCaml and UseOCaml script. There is no sense having two of them out there. -- Philip Lowman ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ANN: UseOcaml.cmake
hi, Indeed, it is much more sophisticated, so it may be more bugged ;-) i can help debugging :) shell i send you my scripts to take a look? It's not necessary. I have downloaded the refactoring branch of yars. Thanks. oh, ok, then you should have the newest version (last yars revision is 513). I comment my OCaml scripts and I send you, so that you could also have a look. great. I have took a look at your UseOCaml script. I can't see why you copy ML files into the current binary dir before compiling them. Is there a reason ? no. i copied most of the stuff from the UseLATEX.cmake. it was done so there, and at the time i wrote the script, i thought its a good idea. don't ask me why :) Keep in touch, let me know when i can jump in and help. looking forward. cheers, keyan J. Bedouet On Fri, Jan 15, 2010 at 8:26 AM, Keyan m...@pulsschlag.net wrote: I totally agree. Judicaël: how should we proceed? my first impression is that your usecaml.cmake is much more sophisticated then mine :) same for the findocaml.cmake scripts, as mine up to now does nothing more than to call a bunch of find_program commands. shell i send you my scripts to take a look? i have no problem with merging my stuff into your scripts, keeping you as main author, if there is anything useful for you. cheers, keyan On 15 Jan 2010, at 02:39, Philip Lowman wrote: On Thu, Jan 14, 2010 at 5:11 AM, Keyan m...@pulsschlag.net wrote: hi, ups ... i thought i replied to the list. thanks for the link. i will adapt my find-script to the requirements and maintain the package. You should work with Judicaël to combine the best of both of your works together into one FindOCaml and UseOCaml script. There is no sense having two of them out there. -- Philip Lowman ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ANN: UseOcaml.cmake
hi,
ups ... i thought i replied to the list. thanks for the link. i will adapt my
find-script to the requirements and maintain the package.
cheers,
keyan
On 14 Jan 2010, at 03:46, Philip Lowman wrote:
On Mon, Jan 11, 2010 at 3:39 AM, Keyan m...@pulsschlag.net wrote:
It looks like a couple of the macros don't have the OCAML_ name prefix
added to them. For example, COPY_FILE GET_DEPENDENCIES. You should
add the prefix to them as well to prevent name collision when other
people use your code.
thanks. wasnt aware of this coding standard, but it makes sense :)
For the INCLUDES feature, doesn't it just get turned into a list you
can iterate on? Couldn't you just use foreach() on it and add the
-I argument and path argument to a separate list that gets passed to
add_custom_command()?
foreach(path ${includelist})
list(APPEND myargs -I)
list(APPEND myargs ${path})
endforeach()
nice, it worked. my mistake was that i used:
set(myargs {$myargs} -I ${path})
instead.
i will try to write a FindOcaml.cmake script soon. when i am done, what is
the best practice to make it available?
Sorry, your email got accidently buried for 3 days. :) Also please
reply to all always so the list gets a copy of the thread.
I think the best way to get it available it to have it released as
part of CMake's Modules folder. To do this you have to volunteer to
maintain the module (basically to deal with patches and bugs) and
follow the process documented in Modules/README.txt to obtain CVS
commit access.
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/readme.txt?root=CMakeview=markup
--
Philip Lowman
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ANN: UseOcaml.cmake
On Thu, Jan 14, 2010 at 5:11 AM, Keyan m...@pulsschlag.net wrote: hi, ups ... i thought i replied to the list. thanks for the link. i will adapt my find-script to the requirements and maintain the package. You should work with Judicaël to combine the best of both of your works together into one FindOCaml and UseOCaml script. There is no sense having two of them out there. -- Philip Lowman ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ANN: UseOcaml.cmake
On Mon, Jan 11, 2010 at 3:39 AM, Keyan m...@pulsschlag.net wrote:
It looks like a couple of the macros don't have the OCAML_ name prefix
added to them. For example, COPY_FILE GET_DEPENDENCIES. You should
add the prefix to them as well to prevent name collision when other
people use your code.
thanks. wasnt aware of this coding standard, but it makes sense :)
For the INCLUDES feature, doesn't it just get turned into a list you
can iterate on? Couldn't you just use foreach() on it and add the
-I argument and path argument to a separate list that gets passed to
add_custom_command()?
foreach(path ${includelist})
list(APPEND myargs -I)
list(APPEND myargs ${path})
endforeach()
nice, it worked. my mistake was that i used:
set(myargs {$myargs} -I ${path})
instead.
i will try to write a FindOcaml.cmake script soon. when i am done, what is
the best practice to make it available?
Sorry, your email got accidently buried for 3 days. :) Also please
reply to all always so the list gets a copy of the thread.
I think the best way to get it available it to have it released as
part of CMake's Modules folder. To do this you have to volunteer to
maintain the module (basically to deal with patches and bugs) and
follow the process documented in Modules/README.txt to obtain CVS
commit access.
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/readme.txt?root=CMakeview=markup
--
Philip Lowman
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
