From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id CFC537EE99 for ; Wed, 22 Jan 2014 20:22:35 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of rinderkn@caesar.elte.hu) identity=pra; client-ip=157.181.151.9; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rinderkn@caesar.elte.hu"; x-sender="rinderkn@caesar.elte.hu"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of rinderkn@caesar.elte.hu designates 157.181.151.9 as permitted sender) identity=mailfrom; client-ip=157.181.151.9; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rinderkn@caesar.elte.hu"; x-sender="rinderkn@caesar.elte.hu"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@mx2.mail.elte.hu designates 157.181.151.9 as permitted sender) identity=helo; client-ip=157.181.151.9; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rinderkn@caesar.elte.hu"; x-sender="postmaster@mx2.mail.elte.hu"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcBADUZ4FKdtZcJnGdsb2JhbABbvHKDBYEXFg4BAQEBAQgLCQkUKIIlAQEBAwF4BgsLGAkWDwkDAgECAUUGAQwIAQGHeQjDSxePA4Q4BJQ8g2aVRg X-IPAS-Result: AtcBADUZ4FKdtZcJnGdsb2JhbABbvHKDBYEXFg4BAQEBAQgLCQkUKIIlAQEBAwF4BgsLGAkWDwkDAgECAUUGAQwIAQGHeQjDSxePA4Q4BJQ8g2aVRg X-IronPort-AV: E=Sophos;i="4.95,701,1384297200"; d="scan'208,217";a="54413781" Received: from mx2.mail.elte.hu ([157.181.151.9]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 22 Jan 2014 20:22:35 +0100 Received: from mailbox1.caesar.elte.hu ([157.181.151.157]) by mx2.mail.elte.hu with esmtp (Exim) id 1W63Ng-0003nq-7k from ; Wed, 22 Jan 2014 20:22:34 +0100 Received: (Authenticated sender: rinderkn) by mailbox1.caesar.elte.hu with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W63Nf-0005LX-QI; Wed, 22 Jan 2014 20:22:31 +0100 Message-ID: <52E01A76.7050109@caesar.elte.hu> Date: Wed, 22 Jan 2014 20:22:30 +0100 From: Christian Rinderknecht Reply-To: rinderkn@caesar.elte.hu Organization: =?ISO-8859-1?Q?E=F6tv=F6s_Lor=E1nd_University?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: William R , caml-list@inria.fr References: <52DF18CB.6000809@caesar.elte.hu> <52DF76A5.1020805@libertysurf.fr> In-Reply-To: <52DF76A5.1020805@libertysurf.fr> Content-Type: multipart/alternative; boundary="------------070804080202040608070306" X-ELTE-SpamScore: -7.8 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 3.0 X-ELTE-SpamCheck-Details: score=-7.8 required=5.9 tests=ALL_TRUSTED,BAYES_00,HTML_MESSAGE,L_AUTH,T_RP_MATCHES_RCVD autolearn=ham SpamAssassin version=3.3.2 -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -5.0 L_AUTH Caesar auth -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -2.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.2 HTML_MESSAGE BODY: HTML included in message Subject: Re: [Caml-list] [ANN] Announcing yet another Makefile for OCaml This is a multi-part message in MIME format. --------------070804080202040608070306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear William and list members, On 01/22/2014 08:43 AM, William R wrote: > could you explain differences with OCamlMakefile This is a fair question, since Markus' work has been around for quite a while, but I am afraid that I never used it. Nevertheless, I went through the documentation and the source code and here are the main differences I can see at the moment (my apologies to Markus if I am mistaken): OCamlMakefile vs my Makefile * User specifies SOURCES and RESULT vs optional OBJ and BIN * Order of linking must be specified vs optional * Builds library and toplevels vs none * Supports -pack/-for-pack and profiling vs none * Preprocessors in special comments, no command-line options per source file vs one tag file per source file + global options * Generates documentation vs none * Subprojects vs mono-project * Support for ocamlfind vs none * Included in another Makefile vs includes another Makefile * One native code compilation vs two * 1300 lines vs 830 lines * Plethora of phony targets vs two * Short documentation vs long OCamlMakefile supports more features than I do, although I use tag files à la ocamlbuild. This is not surprising, as my makefile was not developed to cover many use-cases, just mine and those of beginners. Accordingly, I put an extreme emphasis on different issues, like having the laziest makefile possible: it works a lot in order to compile as little as possible and requires the programmer to configure as little as possible. The output on the terminal is entirely generated by the Makefile, not by the tools it calls, and, if available, it leverages the --output-sync option of GNU Make 4.0 to keep everything readable while using parallelism. Also, there is an impact analysis in case of errors, so there are no redundant error messages (one error implying another in another module) and no useless recompilations (bound to fail). Another feature is that my makefile keeps track of source deletions, which are a major source of inconsistencies, while updating compilation dependencies locally, and, generally speaking, the main design principle is that you should *never* have to do [make clean] if you don't really want to (the only case where you should is compiling to native code when maximising cross-module optimisations and inlining). > why not contribute to this project if you introduced compatible > clever ideas ? OCamlMakefile and my Makefile address different crowds, but these can actually benefit from each other, you are right. I will keep that in mind, but before I add more features à la OCamlMakefile, or the other way around, I would like to have bug reports. You can simply try my makefile by putting it in a single-directory project and setting BIN to the main module's basename in Makefile.cfg. (Each file requiring camlp4 or special options for certain tools require a tag file. See Makefile.man) Best regards, Christian PS I did not know about obuild. I will have a look at it. --------------070804080202040608070306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear William and list members,

On 01/22/2014 08:43 AM, William R wrote:
> could you explain differences with OCamlMakefile

This is a fair question, since Markus' work has been around for quite
a while, but I am afraid that I never used it. Nevertheless, I went
through the documentation and the source code and here are the main
differences I can see at the moment (my apologies to Markus if I am
mistaken):

OCamlMakefile vs my Makefile
  * User specifies SOURCES and RESULT vs optional OBJ and BIN
  * Order of linking must be specified vs optional
  * Builds library and toplevels vs none
  * Supports -pack/-for-pack and profiling vs none
  * Preprocessors in special comments, no command-line options per
    source file vs one tag file per source file + global options
  * Generates documentation vs none
  * Subprojects vs mono-project
  * Support for ocamlfind vs none
  * Included in another Makefile vs includes another Makefile
  * One native code compilation vs two
  * 1300 lines vs 830 lines
  * Plethora of phony targets vs two
  * Short documentation vs long

OCamlMakefile supports more features than I do, although I use tag
files à la ocamlbuild. This is not surprising, as my makefile was not
developed to cover many use-cases, just mine and those of
beginners. Accordingly, I put an extreme emphasis on different issues,
like having the laziest makefile possible: it works a lot in order to
compile as little as possible and requires the programmer to configure
as little as possible. The output on the terminal is entirely
generated by the Makefile, not by the tools it calls, and, if
available, it leverages the --output-sync option of GNU Make 4.0 to
keep everything readable while using parallelism. Also, there is an
impact analysis in case of errors, so there are no redundant error
messages (one error implying another in another module) and no useless
recompilations (bound to fail). Another feature is that my makefile
keeps track of source deletions, which are a major source of
inconsistencies, while updating compilation dependencies locally, and,
generally speaking, the main design principle is that you should
*never* have to do [make clean] if you don't really want to (the only
case where you should is compiling to native code when maximising
cross-module optimisations and inlining).

> why not contribute to this project if you introduced compatible
> clever ideas ?

OCamlMakefile and my Makefile address different crowds, but these can
actually benefit from each other, you are right. I will keep that in
mind, but before I add more features à la OCamlMakefile, or the other
way around, I would like to have bug reports.

You can simply try my makefile by putting it in a single-directory
project and setting BIN to the main module's basename in
Makefile.cfg. (Each file requiring camlp4 or special options for
certain tools require a tag file. See Makefile.man)

Best regards,

Christian

PS I did not know about obuild. I will have a look at it.

--------------070804080202040608070306--