AW: [Caml-list] Re: working %.pp.ml target with ocamfind/ocamlbuild

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am 11.09.2012 14:50:24 schrieb(en) Wojciech Meyer:
> Gerd,
> 
> I agree omake is a high quality tool for non trivial builds, however
> it does not solve the same problems as ocamlbuild. The point of
> dicsussion is to improve ocamlbuild not to switch to the external
> tool.

Well, I don't want to stop you fixing ocamlbuild. My point is rather  
that users sometimes don't recognize the point of complexity when  
ocamlbuild is no longer the right utility, and I just want to point out  
that there is an alternative tool.

> I will lament, because I used both and ocamlbuild have some clear
> advantages over omake (and some clear disadvantages too):
> 
> - it's dead easy to build a single file, without constructing
> horrendous command line or adding an unneeded target

Come on, this is not a fair critique. Have you ever started a fresh  
omake project? It's really short:

.DEFAULT: $(OCamlProgram put_here_the_name_of_your_program, module1  
module2 ...)

> - it's declarative, you don't want to construct tons of special
> variables and concatate them

You can have pattern rules in omake, and I think they are a full  
replacement for tags.

> - it's part of our distribution - no additional dependencies, so if
> it's there, there is some reason, and if something it's not working
> properly we have to fix it

Right, being part of the distribution is the advantage of ocamlbuild.

> Overall ocamlbuild is based on some nice ideas, whatever people would
> say. Not that I say that OMake is no good - in fact it's a very robust
> and excellent build system, and I recommend anyone who's got already
> bootstraping phases, lot of meta programming with unsual tools,
> portability problems etc..

I'd recomment it already when the alternative is to write ocamlbuild  
plugins (which are the biggest error of ocamlbuild - ocaml is just not  
the right language to modify the behavior of builds).

> Both however suffer from almost similar problem - OMake is a bit
> underused for the quality you get, where ocamlbuild is just underrated
> for the ideas it has.

ocamlbuild certainly has some nice ideas, but I'd overall say that it  
jumps too short. It's ok for student projects, and I guess this is the  
main justification for having it in the distribution. It's easier than  
traditional Makefiles. What's missing is that you cannot easily modify  
existing behavior, and to my mind, plugins do not use the right  
abstractions. A one-liner in omake's DSL (which is actually a nice  
dynamically-typed functional language) turns into a lengthy phrase.

Well, there are also things I don't like in omake (e.g. environments  
are powerful but also difficult to debug). But so far it is the clear  
winner for me, mostly because it has a good DSL which is more adequate  
than

Gerd


> --
> Wojciech
> 
> On Tue, Sep 11, 2012 at 1:27 PM, Gerd Stolpmann  
> <info@gerd-stolpmann.de> wrote:
> > Am 10.09.2012 14:18:42 schrieb(en) bob zhang:
> >>
> >> Btw, there's something wrong with the rule "%.pp.ml", I don't  
> remember
> >>
> >> exactly where it's, for your interest, you can have a look at
> >>
> >>  
> https://bitbucket.org/HongboZhang/camlp4/src/e88f431db722/myocamlbuild.ml
> >>
> >> ocaml has a really really *high quality* compiler, but all the  
> tools
> >> around
> >> it is not that satisfied, contribution is much harder than bug  
> fixes :-(
> >>
> >> If you take a look at ICFP 12's paper about Shake, the idea is  
> essentially
> >> the same as 'ocamlbuild', and the idea is cool, but the  
> implementation of
> >> ocamlbuild is fragile and buggy.
> >
> >
> > And I wonder why ocamlbuild is actually used. There is a *high  
> quality*
> > build tool for ocaml: omake.
> >
> >
> >>
> >> On Mon, Sep 10, 2012 at 2:08 PM, Hongbo Zhang
> >> <bobzhang1988@gmail.com>wrote:
> >>
> >> > Greetings,
> >> > On 9/9/12 6:29 PM, Wojciech Meyer wrote:
> >> >
> >> >> Gabriel Scherer <gabriel.scherer@gmail.com> writes:
> >> >>
> >> >>  This is useful for debugging purposes, and for some (minor)  
> modes of
> >> >>> use of Camlp4. However, for most Camlp4 development, this has  
> the
> >> >>> severe downside of losing the location information of the  
> original
> >> >>> file, if I understand correctly. This means that you don't  
> want to use
> >> >>> it as a transparent step towards compilation, but only in  
> exceptional
> >> >>> situations where the developers will re-edit the output code.
> >> >>>
> >> >>
> >> >> I think I've to say I disagree it's not useful, when I'm  
> developing a
> >> >> syntax extension on top of Camlp4 I really want to see the  
> generated
> >> >> code. Moreover to understand some of the more complicated syntax
> >> >> extensions like type_conv, deriving, FoldGenerator I need to  
> look at
> >> >> the
> >> >> expanded code to understand how to use it - last time I hit the  
> same
> >> >>
> >> > Yes, it's damn useful not only for bootstrapping, but also for
> >> > developing
> >> > to locate type errors. But there's something wrong with Camlp4's
> >> > printer,
> >> > it has *4* printers in total, writing a printer for an Ast which  
> has no
> >> > backend is totally useless. In my branch of camlp4, *I removed  
> all those
> >> > 4
> >> > printers and using tools/pprintast.ml* in ocaml's compiler source
> >> > tree(with some my own bug fixes), and it works very well.
> >> > Btw, are you in ICFP? we could have a talk about Camlp4 :-)
> >> >
> >> >> problem it was actually 'deriving-ocsigen' when I needed to  
> implement
> >> >> my
> >> >> own Show module - it's just much faster to see what's being  
> generated
> >> >> for the usual case, then trying to figure out from the recipe  
> in the
> >> >> documentation.  Otherwise for bootstrapping purposes, you might  
> want to
> >> >> pre-generate some code too and put into the repository.
> >> >>
> >> >> --
> >> >> Wojciech Meyer
> >> >> http://danmey.org
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Regards
> >> -- Bob
> >>
> >> --
> >> Caml-list mailing list.  Subscription management and archives:
> >> https://sympa-roc.inria.fr/wws/info/caml-list
> >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> >> Bug reports: http://caml.inria.fr/bin/caml-bugs
> >>
> >>
> >
> > --
> > ------------------------------------------------------------
> > Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
> > Creator of GODI and camlcity.org.
> > Contact details:        http://www.camlcity.org/contact.html
> > Company homepage:       http://www.gerd-stolpmann.de
> > ------------------------------------------------------------
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa-roc.inria.fr/wws/info/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
> >
> 
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------