From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 1A2697FACD for ; Fri, 19 Sep 2014 16:00:32 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.212; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.212; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.212; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@msa.smtpout.orange.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcBACw2HFTB/BfUnGdsb2JhbABWCoNgV4MBxmyHVQGBGAERAQEBAQEGDQkJFCqEAwEBAQMBIxVAAQULCw4KAgIFFgsCAgkDAgECAUUGDQEHAQGIMgysc5Y1GIEsiG6FC1wHgniBUwEElgyHB4FhhWuRY2qCSgEBAQ X-IPAS-Result: ArcBACw2HFTB/BfUnGdsb2JhbABWCoNgV4MBxmyHVQGBGAERAQEBAQEGDQkJFCqEAwEBAQMBIxVAAQULCw4KAgIFFgsCAgkDAgECAUUGDQEHAQGIMgysc5Y1GIEsiG6FC1wHgniBUwEElgyHB4FhhWuRY2qCSgEBAQ X-IronPort-AV: E=Sophos;i="5.04,555,1406584800"; d="scan'208";a="96654003" Received: from msa03.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.212]) by mail2-smtp-roc.national.inria.fr with ESMTP; 19 Sep 2014 16:00:31 +0200 Received: from [192.168.1.132] ([92.151.92.168]) by mwinf5d61 with ME id t20V1o00Z3dx2K80320W16; Fri, 19 Sep 2014 16:00:31 +0200 X-ME-Helo: [192.168.1.132] X-ME-Auth: bGV4aWZpQHdhbmFkb28uZnI= X-ME-Date: Fri, 19 Sep 2014 16:00:31 +0200 X-ME-IP: 92.151.92.168 Message-ID: <541C36FF.3010603@frisch.fr> Date: Fri, 19 Sep 2014 16:00:31 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Gerd Stolpmann CC: Bob Zhang , Caml List References: <541C2037.5030303@frisch.fr> <1411133763.2930.28.camel@zotac> In-Reply-To: <1411133763.2930.28.camel@zotac> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] improve omake [was One build system to rule them all] On 09/19/2014 03:36 PM, Gerd Stolpmann wrote: > Well, I run frequently into the difficulty that I need some special > omake function that would be trivial to develop in OCaml (e.g. > associating some data with some other data, filtering things, doing > string transformations), but for writing it in the omake language I need > some time for developing and testing. I have a quite simple idea to > improve this: Besides OMakefile there could also be an OMakefile.ml, and > you can define any helper functions there, and they would be > automatically callable from the OMakefile. I think this is not really > complicated to do - you'd need to build a custom omake executable > whenever OMakefile.ml changes, and need to scan the OMakefile.ml > interface for function signatures that match the form that is callable, > and you need to generate some glue code. (Later this idea could be > extended by allowing OCaml code to emit new rules, as described in an > earlier post.) I can see some cases where it would indeed be more comfortable to implement build-system calculations in OCaml. But couldn't most of these cases be implemented as external programs called by omake functions and implemented e.g. in OCaml? This forces to pass explicitly all the data required by the calculation to those external programs, but how often is this a problem? With some convention, the external program could even return description of new dependencies, to be interpreted by some omake code and injected into the actual graph. AFAICT, all this is already possible. > I see what you mean. In a recent project I had to define all variables > with library names, findlib names, intra-project library dependencies > etc. in the global OMakefile, because they are needed in potentially all > sub-OMakefiles. That's of course not where these things are best > naturally defined. A variant is to have e.g. a OPreOMakefile file in each directory and arrange so that the toplevel OMakefile includes all of them (with a proper ordering) without processing the rest of the project. This way, you only need to "lift" the full list of directories, and actual data definitions can be put where they belong. > Maybe we should allow to switch to global context anywhere? I think this > is solvable. I'm not sure this would easily fit in the current functional semantics. > Could be something simple, like matching the wildcard rules against the > real files. Reading the directory content should be quite cheap, and then it is just string processing, which should be even cheaper (if done properly). It would be great to identify such hot spots; maybe some very local tweaks to algorithmics or data structures could improve performance a lot. Alain