On Monday 20 October 2008, Romain Bardou wrote:
> Kuba Ober a écrit :
> >> I'm not sure that parsing ocamlbuild file is the right thing to do. For
> >> a simple OCaml project (which would probably mean most Camelia
> >> projects), there are no OCamlBuild files at all.
> >>
> >> Mmmhhh.... there's .itarget (i.e. a list of files you wish generated
> >> after compilation), but that's about it. And, again, most projects don't
> >> have any.
> >
> > OK, so I'll focuse on .itarget instead, since that's the thing that the
> > debugger has to cooperate with to decide what executable to run and
> > debug.
>
> Err... I'm not sure .itarget is what you want. It's close of what you
> want, sure, but you may have several .itarget for the same project,
> things like that.
>
> A typical project may have:
>    * some source files (.ml .mli .mly .mll);
>    * several main targets (.byte .native .mllib .mlpack), that may or
> may not be put together in one or several .itarget;
>    * a documentation (.odocl);
>    * some special rules (_tags myocamlbuild.ml), like some libraries to
> use; * a configure script.
> This is not, IMO, easily relatable to the project itself, which is
> simply a list of files...
>
> Given a list of files, an IDE can guess interesting targets such as:
>    * .docdir/index.html for each .odocl;
>    * .cma .cmxa for each .mllib;
>    * .cmo for each .mlpack.
> But potentially every file can generate several interesting targets. For
> instance, from the file x.mlpack, one can generate x.cmo, x.cmx, x.cma,
> x.cmxa, x.mli, or even x.docdir/index.html.
>
> IMO, simply allowing to view the whole contents of a directory is
> enough, especially thanks to the fact that ocamlbuild does not pollute
> your source directory.

That works for me.
In future I can implement functionality similar to Visual Studio's .vcproj
files, where you can basically hand-tune the build process, all without
leaving the IDE. I have had a go at writing a proof-of-concept stand-alone
"executor" or "builder" for .vcproj files, and it's not only doable, but
the concept should be easy to duplicate and is relatively user-friendly -
certainly better than dealing with Makefiles directly, and better than
dealing with qmake's .pro files too.

Cheers, Kuba