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=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 0AE52BC6C for ; Thu, 31 Jan 2008 11:02:18 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKwroUfAXQImh2dsb2JhbACQKwEBAQgKKZtU X-IronPort-AV: E=Sophos;i="4.25,284,1199660400"; d="scan'208";a="22008966" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 31 Jan 2008 11:02:17 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0VA2Etn024615 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 31 Jan 2008 11:02:17 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAO8qoUfBL1AZh2dsb2JhbACQKgEBAQgKKZtJ X-IronPort-AV: E=Sophos;i="4.25,284,1199660400"; d="scan'208";a="8565993" Received: from gw.exalead.com (HELO exalead.com) ([193.47.80.25]) by mail3-smtp-sop.national.inria.fr with ESMTP; 31 Jan 2008 11:02:14 +0100 Received: from [192.168.204.148] (madpc064.exalead.com [192.168.204.148]) (authenticated bits=0) by exalead.com (8.14.0/8.14.0) with ESMTP id m0VA2Ars021741; Thu, 31 Jan 2008 11:02:13 +0100 Message-ID: <47A19CA2.9010303@exalead.com> Date: Thu, 31 Jan 2008 11:02:10 +0100 From: Berke Durak User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Caml-list List Cc: Nicolas Pouillard Subject: Using dynlink (native code and byte code) for the build system Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 47A19CA6.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 dynlink:01 byte:01 compilation:01 makefile:01 byte:01 makefiles:01 makefiles:01 ocaml:01 callable:01 dependencies:01 dynamically:01 Hello all, Thank to Alain Frisch's natdynlink, it is now possible to dynamically load native code plugins. We were thinking with Nicolas of dynamically of using this to loading all plugins dynamically, instead of linking them with ocamlbuild and re-running the resulting executable as is done currently. This would allow to load any number of plugins during the course of the compilation. It has been recently suggested on this list that instead of forcing everyone to use the same build system, we could ask them to have a common build API. One proposition was a makefile with a fixed number of targets (byte, native, clean...) I think that we should minimize the set of different languages used per the ``you shall not unnecessarily multiply entities'' principle. Also, Makefiles are not very portable, because: * There are different implementations of make (BSD make vs GNU make) * Makefiles embed shell commands and filenames, which cause huge portability problems So why not require projects to have a buld API in an Ocaml file? The API would be distinct from ocamlbuild but would be designed to be extensible, to permit dynamic loading and to be callable from ocamlbuild. I have started a toy system. Every project includes in its root a file named plugin.ml, which contanis something such as: open Interface class entry env = object inherit default_builder method hello = env.env_say "Hello, world!" method build = env.env_say "Building"; Sys.command "make linux" method clean = env.env_say "Cleaning"; Sys.command "make clean" end let _ = register (fun env -> new entry env) Interface is the API we are talking of. The plugin registers an object of class entry. The entry object has a #build method which is called to build and install the project, according to options and target directories defined in the environment env. The environment contains a registry-like configuration dictionary whose interpretation is project-dependent. The entry object can also have a #prerequisites method which returns a description of the dependencies of the project. I've made a toy API and a toy builder which compiles and loads native plugins, and written a plugin for a C project which is built using make. You can browse the source at http://aurochs.fr/hg/opkg/ or clone it using Mercurial with the command: hg clone http://aurochs.fr/hg/opkg/ You then run ./make and then ./builder So this is a request for experimenting and developing a plugin system around these ides. Feel absolutely free to do anything based on the opkg sample code. I hope a nice plugin system will evolve from it. PS. You can commit in your own repository; if you want to have push access just send me a mail with the result of htpasswd -nd yourlogin PPS. I put the code in the public domain. -- Berke DURAK