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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 92A257EE51 for ; Wed, 10 Apr 2013 11:08:48 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dra-news@metastack.com) identity=pra; client-ip=115.124.103.27; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of dra-news@metastack.com designates 115.124.103.27 as permitted sender) identity=mailfrom; client-ip=115.124.103.27; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@relay.metastack.com) identity=helo; client-ip=115.124.103.27; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="postmaster@relay.metastack.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAF4rZVFzfGcb/2dsb2JhbABQgmUhNsEogRAWdIIfAQEBAwF5BQsCAQgYCiQyJQIEAQ0FCIgGBQIDvk+OYzEHAoJeYQOIRoppg0qBIY9ugwuCKA X-IPAS-Result: AgMFAF4rZVFzfGcb/2dsb2JhbABQgmUhNsEogRAWdIIfAQEBAwF5BQsCAQgYCiQyJQIEAQ0FCIgGBQIDvk+OYzEHAoJeYQOIRoppg0qBIY9ugwuCKA X-IronPort-AV: E=Sophos;i="4.87,444,1363129200"; d="scan'208";a="10441296" Received: from relay.metastack.com ([115.124.103.27]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 Apr 2013 11:08:47 +0200 Received: from romulus.metastack.com ([81.102.132.77]) by relay.metastack.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Apr 2013 10:08:46 +0100 Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id r3A98gXE018695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Apr 2013 10:08:42 +0100 Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0123.003; Wed, 10 Apr 2013 10:08:41 +0100 From: David Allsopp To: Julien Signoles , =?iso-8859-1?Q?=C9tienne_Andr=E9?= CC: Caml List Thread-Topic: [Caml-list] Build number and date in OCaml? Thread-Index: AQHONRbKXsG1WON5iUyaHsNicAokEpjPFaeAgAASCPA= Date: Wed, 10 Apr 2013 09:08:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.0.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-OriginalArrivalTime: 10 Apr 2013 09:08:46.0771 (UTC) FILETIME=[01F3C830:01CE35CB] Subject: RE: [Caml-list] Build number and date in OCaml? Julien Signoles wrote: > 2013/4/9 =C9tienne Andr=E9 > I've been using OCaml for a couple of years, but without using any advanc= ed feature; > so my question may be a little naive. Is there any way to insert easily t= he current=20 > date and time of compiling, as well as, e.g., an incremental build number= in an OCaml > program?=A0So that it is printed at runtime, e.g., in the program header. > > This kind of information is part of your build process and are not direct= ly accessible > in OCaml. If you want to access it in your OCaml program, you have to pas= s them from=20 > the build environment to the program environment. As Jeremie Dimino said,= the usual way > is to general a small OCaml file at build time and to link it to your pro= gram. > For instance, if you use 'make', you could have the following lines in yo= ur Makefile: > VERSION=3D... > config.ml: Makefile NB - if you want the build stamp ever to be updated, it'll need to depend o= n more than Makefile. You can either have it depend on all of your ML sourc= e files or, if using GNU make, you could declare config.ml as .PHONY (which= means it will be rebuilt at every invocation of make). > CMO_FILES =3D config.cmo ... (* other cmo files *) There's a further subtlety which can come into play if your build has more = than one output, which is to place config.cmo / config.cmx as an order-only= dependency. For example, suppose your build system has two programs whose = sources are Foo.ml and Bar.ml both of which depend on Common.ml. If you str= ucture your Makefile as: Config.ml: Foo.ml Bar.ml Common.ml ... foo.exe: Common.cmx Foo.cmx | Config.cmx ... bar.exe: Common.cmx Bar.cmx | Config.cmx ... then updates to Foo.ml will not cause bar.exe to be rebuilt. The advantage = of this approach is that the generating of the build stamp does not interfe= re with make - i.e. you don't get any additional recompilations. Of course,= there are times where you do want all output programs to have the same bui= ld stamp but most of the time (i.e. while developing!) you don't want a cha= nge in one small part of the system to force recompilation/linking of the w= hole system...=20 HTH, David