avoid Makefile wrappers

[agarwal]

In practice, use of ocamlbuild requires a Makefile wrapper to also be provided. This is sort of silly. OCamlbuild is meant to be a superior replacement of Make, so how come I still end up having to resort to Make to provide the final bits of my build. Here are some reasons:

• [x] To provide default targets. Thus, a very short make suffices during development.
• [ ] I need to pass long arguments to ocamlbuild, such as -plugin-tag "package(opam-lib)". My makefile adds these in, so I don't have to type it each time.

[gasche]

I think the real reason why people provide Makefile wrappers is that users (say they clone the development repository and want to just hack one small thing in the project) are just used to make or make all as an interface to building a package, they don't want to look at which build system is used to figure the right build command. This is unlikely to go away unless (1) people use OASIS and recognize the ocaml setup.ml -build interface or (2) people adopt an opam build script that just looks for the opam file and runs the build command locally. Even then I think some people will want to provide a make interface.

That said, your list of reasons is a good idea: we should try to kill any reason other than cosmetics as they may highlights limitations of the tool.

• provide default targets: no need to, given that you can write the list of target in a foo.itarget file
• pass long arguments to ocamlbuild: we don't have a no-wrapper answer to this. Some support for an -args path file allowing to pass command-line arguments in a file rather than on the command line is certainly a good idea (we need this in the compiler, and adding support in ocamlbuild would be good if only for consistency). To go further one could think of a default .ocamlbuild file with command-line argument, but I'm wary of this kind of cruft.

Another reason is to vary the set of flags passed. For example I personally don't like the foo.d.byte targets, I prefer to pass -flag debug explicitly during my development cycle, and one could imagine a Makefile with two targets, one with and one without the flag. Again, I suppose that -args path would be a rather clean answer to this need.

[agarwal]

users ... are just used to make or make all as an interface to building a package

Fair enough. I might even keep a Makefile with targets like clean just calling ocamlbuild -clean. The problem is that I'm currently doing real work in my Makefile because I can't or don't know how to get ocamlbuild to do them.

provide default targets: no need to, given that you can write the list of target in a foo.itarget

So you still have to type ocamlbuild foo.itarget, but I want to be able to do just ocamlbuild. If I could define this list of default targets directly within myocamlbuild.ml, then I would be satisifed. I suspect I already can, but like my _tags issue in gasche/manual-ocamlbuild#19, it's a matter of figuring out how to mimic the functionality of an external file within myocamlbuild.ml. In general, I'm wary of any answer that requires me to create any file other than myocamlbuild.ml.

pass long arguments to ocamlbuild

This is perhaps the only use case I accept as requiring an extra file because there is a bootstrapping issue. You can't specify how to compile myocamlbuild.ml from within myocamlbuild.ml. Well, we could using a header section like ocamlscript or pragmas like Haskell, but an external file is also fine for me in this case.

one could think of a default .ocamlbuild file with command-line argument, but I'm wary of this kind of cruft

I don't understand why this is cruft as compared to your proposal of a -args path option. Isn't that exactly the same; now you have to write an extra file, which you could name .ocamlbuild, and pass to this option. Only difference is .ocamlbuild is the obvious name for specifying your ocamlbuild configuration. It seems perfect to me. Also, no reason to limit this config file to just arguments to ocamlbuild; it could serve the purpose of the unified file you mentioned here (though I don't support that goal).

[agarwal]

Another reason for foo.itarget being unsatisfactory is that my default targets are not fixed. If lwt is installed, then I want to by default compile mylib_lwt.cma, otherwise I don't. I did this with omake. There's no reason I shouldn't be able to do it when I supposedly have the full power of OCaml at my disposal.

[gasche]

If I could define this list of default targets directly within myocamlbuild.ml, then I would be satisifed.

You can just prepend stuff to Options.target at the Before_options or After_options hook time (depending on the cascade model you want wrt. command-line arguments).

In general modifying Options works for a lot of things (I'm not sure we expose a "parse this string in command-line argument format" function that would be more convenient than manual mutation in many cases; if not, we should), but of course not for -plugin-tags for the bootstrapping reason you give.

I'm not opposed to an ocamlscript-like solution if we can find something nice. For example an extension point at the head of myocamlbuild.ml could indicate findlib plugins to load.

I don't understand why .ocamlbuild is cruft as compared to your proposal of a -args path option. Isn't that exactly the same.

With -args args, there is nothing implicit. ocamlbuild takes as input the myocamlbuild.ml, the _tags, the command-line, and then it does stuff. The .ocamlbuild proposal is adding another implicit input source, this is bad. It is very marginally more convenient and makes for more complex, less composable interfaces.

[agarwal]

With -args args, there is nothing implicit.

I'm missing something. What value would you give as the argument to -args? IIUC it is the path to a file, right?

[gasche]

Yes, a path to a file whose content is a string of command-line arguments.

[agarwal]

Yes, a path to a file whose content is a string of command-line arguments.

As I thought, so then I still don't see how this is less cruft than a .ocamlbuild file. The difference is I'm suggesting we let the name of the file specifically be .ocamlbuild (by default, I supposed you could allow passing an option to override the default), instead of making the user always specify it. Maybe I'm still missing something.