From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 24A9A7FCEF for ; Sun, 19 Apr 2015 08:47:24 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of adrien@notk.org designates 91.121.71.147 as permitted sender) identity=mailfrom; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; 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@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DJCQB8TjNV/5NHeVtbgwxSXIMXwyMJgVGGAQKBJTgUAQEBAQEBAX1BBYNbAQEEIw8BRhALGAICBRMOAgIPBRgxMYgRCbQblBMBAQEBAQUBAQEBARkEgSGKFoJrghkHgmgvgRYFlSeGJAGBH4M8kEcigWRTgT48MYJEAQEB X-IPAS-Result: A0DJCQB8TjNV/5NHeVtbgwxSXIMXwyMJgVGGAQKBJTgUAQEBAQEBAX1BBYNbAQEEIw8BRhALGAICBRMOAgIPBRgxMYgRCbQblBMBAQEBAQUBAQEBARkEgSGKFoJrghkHgmgvgRYFlSeGJAGBH4M8kEcigWRTgT48MYJEAQEB X-IronPort-AV: E=Sophos;i="5.11,602,1422918000"; d="scan'208";a="112022380" Received: from nautica.notk.org ([91.121.71.147]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 19 Apr 2015 08:47:23 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id 5BD4FC009; Sun, 19 Apr 2015 08:47:22 +0200 (CEST) Date: Sun, 19 Apr 2015 08:47:22 +0200 From: Adrien Nader To: Daniel =?utf-8?Q?B=C3=BCnzli?= Cc: Malcolm Matalka , caml-list@inria.fr Message-ID: <20150419064722.GA25301@notk.org> References: <877ftfoudd.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Caml-list] Suggested way to determine platform specific capabilities in build system? Hi, On Tue, Apr 14, 2015, Daniel Bünzli wrote: > Le mardi, 14 avril 2015 à 12:51, Malcolm Matalka a écrit : > > What is the current suggested way to determine what, roughly, autoconf > > would do for you? I have some platform specific functionality to be > > included (or excluded) depending on the OS. > > I don't know if there's a suggested way but here are various ways to proceed. > > If you are using ocamlbuild, you can use `Sys.win32` since 4.01.0 or `Sys.os_type = "Win32"` to determine if you are on windows and otherwise get the (stripped and lowercased) result of `uname -s`, see e.g (but it's missing the win bit): > > https://github.com/dbuenzli/tsdl/blob/master/myocamlbuild.ml#L6 > > If you are using Makefiles you may want include `$(ocamlc -where)/lib/ocaml/Makefile.config` and use the `$SYSTEM` variable. > > If this is only needed for C stubs you can also try solve this at the CPP level — but I guess this can be quite brittle — see e.g (here again missing the win bit as it's undefined for now): > > https://github.com/dbuenzli/mtime/blob/master/src-os/mtime_stubs.c#L11-L21 > > In any case make sure the value can be overridden from the command line for cross compilation scenarios. This is the wrong approach. Please do not test for systems but for capabilities. Testing for systems hinders progress and is a huge long-term cost. Consider the case where you test for windows on the mingw-w64 toolchain. Something isn't available and you therefore disable it. Then mingw-w64 add it and tt becomes available at the end of the year. Either you must push a new release (typically a development one that is completely experimental) or the packager must patch (and that's one of the most annoying kind of patching to do) or the software never takes advantage of the new feature. The proper way to do it is to test for features instead. Want to know if function foo is available in library bar? Well, just reference it and see if compilation and/or linking fails. You can also try to run it, if not cross-compiling; at which point you would have to guess (in practice it's < 1% of cases). -- Adrien Nader