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 B2C1A7FCEF for ; Sun, 19 Apr 2015 10:38:34 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=pra; client-ip=74.55.86.74; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=mailfrom; client-ip=74.55.86.74; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@smtp.webfaction.com) identity=helo; client-ip=74.55.86.74; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="postmaster@smtp.webfaction.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AuAQDvaDNVnEpWN0pch1HKfgKBXxABAQEBAQEBEQEBAQEBBg0JCRQuhCEBAQMBI1YFCwsaAiYCAkcQBhuIGwgEtCGUEAEKAQEBHoEhihaEUTMHgmgvgRYBBJxrgzyCPA+KLoNOglmBPoMxAQEB X-IPAS-Result: A0AuAQDvaDNVnEpWN0pch1HKfgKBXxABAQEBAQEBEQEBAQEBBg0JCRQuhCEBAQMBI1YFCwsaAiYCAkcQBhuIGwgEtCGUEAEKAQEBHoEhihaEUTMHgmgvgRYBBJxrgzyCPA+KLoNOglmBPoMxAQEB X-IronPort-AV: E=Sophos;i="5.11,602,1422918000"; d="scan'208";a="135744749" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail2-smtp-roc.national.inria.fr with ESMTP; 19 Apr 2015 10:38:33 +0200 Received: from [172.20.10.2] (121.232.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.232.121]) by smtp.webfaction.com (Postfix) with ESMTP id C096620EFF7E; Sun, 19 Apr 2015 08:38:30 +0000 (UTC) Date: Sun, 19 Apr 2015 10:38:27 +0200 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Adrien Nader Cc: Malcolm Matalka , caml-list@inria.fr Message-ID: <67E83AEE021C4CF3826AA7A3575C5635@erratique.ch> In-Reply-To: <20150419064722.GA25301@notk.org> References: <877ftfoudd.fsf@gmail.com> <20150419064722.GA25301@notk.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [Caml-list] Suggested way to determine platform specific capabilities in build system? Le dimanche, 19 avril 2015 =C3=A0 08:47, Adrien Nader a =C3=A9crit : > 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. It depends quite a lot of what you need to do, e.g. in the ocamlbuild examp= le I linked to, you need to add a specific flag to the compiler, now if you= need to check for this using some kind of obscure test your are building q= uite a few assumptions about how the tool works and the semantics of the fl= ag both of which may change in the future regardless of the you may think a= bout them. These kind of things lead to quite obscure configuration systems= which also do have a huge cost both for *users* and maintainers in the lon= g-term. > 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.=20=20 I know this is the way autocrap likes to work; it may seem smart but I thin= k that's completely retarded. We want versioned APIs/system releases that a= re clear about the symbols they expose and their associated semantics. I me= an if we take to the extreme why have any form of package constraints in op= am ? We could just test needed symbols/modules against what is installed. I= hope you do realize that this is completely insane.=20=20=20 Nowadays that it has never been as easy to use a patched package (under the= form of `opam pin`) and that I hope we will also soon fix the problem of m= aking reliable releases in a breeze. I think that the kind of approach you = propose is going to be more much more expensive in the long term. The simpl= er you keep the configuration bits the easier it will be to adapt both from= you as a maintainer or from someone that is external to the project.=20=20 The approach you mention would make sense if the OSes would provide us a re= liable service for testing its capabilities. Lacking this, relying on obscu= re and brittle test shell scripts, thanks but no. Progress is not hindered = by what you make think... Best, Daniel