Properly compiling modules in subfolders (ocamlbuild)

Question

I recently decided to organize the files in my project directory. I moved the parsers I had for a few different file types into their own directory and also decided to use ocamlbuild (the as the project was getting more complicated and the simple shell script was not sufficient any longer).

I was able to successfully include external projects by modifying myocamlbuild with some basic rules (calling ocaml_lib, I'll use ocamlfind some other time), but I am stuck on how to include the folder as a module into the project properly. I created a parser.mlpack file and filled it with the proper modules to be included (eg, "parser/Date", et cetera), wrote a parser.mli in the root of the directory for their implementations, and modified the _tags file (see below).

During the compilation, the parser directory is traversed properly, and parser.cmi, parser.mli.depends were both created in the _build directory; as well as all *.cm[xio] files in the parsers subdirectory.

I feel I might be doing something redundant, but regardless, the project still cannot find the Parser module when I compile!

Thanks!

_tags

debug : true
<*.ml> : annot
"parser" : include
<parser/*.cmx>: for-pack(Parser)
<curlIO.*> : use_curl
<mySQL.*> : use_mysql
<**/*.native> or <**/*.byte> : use_str,use_unix,use_curl,use_mysql

compilation error

/usr/local/bin/ocamlopt.opt unix.cmxa str.cmxa -g -I /usr/local/lib/ocaml/site-lib/mysql mysql.cmxa -I /usr/local/lib/ocaml/curl curl.cmxa curlIO.cmx utilities.cmx date.cmx fraction.cmx logger.cmx mySQL.cmx data.cmx project.cmx -o project.native  
File "\_none\_", line 1, characters 0-1:  
Error: **No implementations provided for the following modules:**
         Parser referenced from project.cmx  
Command exited with code 2.  

You'll notice -I parser is not included in the linking phase above; actually none of the parser related files are included!

edit: Added new details from comments and answer below.

Noonberg

Answer 1

I wonder if parser.mli is somehow interfering with the dependencies in processing the mlpack file. parser.cmi will be generated from the pack operation when parser.mlpack is processed and compiled. Try building with the parser.mli file removed. If that works, then this can be re-processed into a real answer.

Also, you don't need parser/ as a prefix to your modules in parser.mlpack if parser.mlpack is in the parser directory and you have the include tag set. But that shouldn't make a difference for this.

Update: this worked around the problem, but wasn't the root cause. Root cause, per comment below, was a file mentioned in the .mlpack that had been relocated.

Grandiloquent

Yes, this worked, But does not have the intended consequences. A module representing the contents of the directory was not created; they are referenced by the submodules directly. The -pack argument is added to the proper modules during compilation though. But not used in the final product. Is my interpretation about -pack incorrect? – Noonberg

-pack should create a module which contains the other modules as submodules. Your other code must then refer to them as their submodules (e.g. Parser.ConfParser); if it ever refers to them directly (just ConfParser without first opening Parser), then things will get messed up. Could you post the -verbose output when you don't have parser.mli? – Grandiloquent

I added back the parser.mli file. I think for some reason an error while compiling the pack didn't break where it should. There was an extra module in my mlpack file that I had moved. – Noonberg

Answer 2

You need to "include" the parser directory in the search path. You can do this in _tags:

"parser": include

Then ocamlbuild can search the parser directory for interesting files.

Grandiloquent

... I modified my question above. This helped, but I was actually already doing this, but from the equivalence on the command line with -I parser. Now, I just build with ocamlbuild project.<target> – Noonberg

Let's try something else then :). Done as a separate answer since it's really another approach. – Grandiloquent

(just to be complete, you may know this already) <parser> or "parser" will work, but "parser" is correct since I'm not trying to do any pattern matching. – Noonberg