From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, DNS_FROM_SECURITYSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 77764BBAF for ; Mon, 20 Oct 2008 22:02:52 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIBABSB/EhDWxLCbmdsb2JhbACBcpF9PqlAhS1fg2w X-IronPort-AV: E=Sophos;i="4.33,453,1220220000"; d="scan'208";a="16295974" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail2-smtp-roc.national.inria.fr with ESMTP; 20 Oct 2008 22:02:51 +0200 Received: from kuba.bertec.net (kuba.bertec.net [192.168.2.16]) by server1.bertec.net (Postfix) with ESMTP id 71CBA105761 for ; Mon, 20 Oct 2008 16:02:51 -0400 (EDT) From: Kuba Ober To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Camelia progress, indenter Date: Mon, 20 Oct 2008 16:02:49 -0400 User-Agent: KMail/1.9.10 References: <200810170956.00776.kuba@mareimbrium.org> <200810200935.24152.ober.14@osu.edu> <48FC99DA.6070606@lri.fr> In-Reply-To: <48FC99DA.6070606@lri.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200810201602.50825.ober.14@osu.edu> X-Spam: no; 0.00; ocaml:01 compilation:01 debugger:01 mli:01 mll:01 byte:01 cmxa:01 cmo:01 cmo:01 cmx:01 cmxa:01 mli:01 doable:01 makefiles:01 cheers:01 On Monday 20 October 2008, Romain Bardou wrote: > Kuba Ober a =C3=A9crit : > >> 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