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 D16447FFE1 for ; Thu, 6 Oct 2016 16:46:26 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-io0-f182.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.182; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.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@mail-io0-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-io0-f182.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3Anqt0XhEoIDzoQtebJ4r5rp1GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ74psywAkXT6L1XgUPTWs2DsrQf2rCQ6PqrBjJIyK3CmUhKSIZLWR4BhJ?= =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBy?= =?us-ascii?q?brysXNWD1YLsjavtpdX6WEZhvHKFe7R8LRG7/036l/I9ps9cEJs30QbDuXBSeu?= =?us-ascii?q?5blitCLFOXmAvgtI/rpMYwuwwZgf8q9tZBXKPmZOx4COUAVHV1BVso/9XmvgXv?= =?us-ascii?q?Sg6G531UEjlH00kAPw+Qpir9U5jtqCzi8qJY2SKaNMDyB/hgXDWp765mTFnzjy?= =?us-ascii?q?oIKyQ+6EnWjNB9iORQpxf39DJlxIuBT4ifLvtzeuvmdtMXX2dbFpJeXiZbA464?= =?us-ascii?q?KZAED+cbMPxwoIz0pl9Iphy7U1r/TNjzwyNF0yellZYx1P4sRESbhQE=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQCNYvZXf7bfVdFcHAEBBAEBCgEBG?= =?us-ascii?q?AEFAQsBgxIBAQEBATw5fAekKYIqhhmNdCaFegKBawc7EQEBAQEBAQEBAQEBEgE?= =?us-ascii?q?BCQsLCRcxgjIEARUFghEBAQMBEhEdAQgTEgsBAwELBgULGh0CAiIBEQEFAQoEA?= =?us-ascii?q?Q0GEwgKAgcHiBEBAw8IDqNZgTI+MotCgWuCXwWDbgoZJwMKU4MIAQEBAQEBBAE?= =?us-ascii?q?BAQEBAQEBFwMGEIYsg1CBBYR0gleCWwWGbwyTBIFlhEOJU4I8jTiMd4I9Ex6BE?= =?us-ascii?q?TRfgjwsghoiNIZ/gUEBAQE?= X-IPAS-Result: =?us-ascii?q?A0AdAQCNYvZXf7bfVdFcHAEBBAEBCgEBGAEFAQsBgxIBAQE?= =?us-ascii?q?BATw5fAekKYIqhhmNdCaFegKBawc7EQEBAQEBAQEBAQEBEgEBCQsLCRcxgjIEA?= =?us-ascii?q?RUFghEBAQMBEhEdAQgTEgsBAwELBgULGh0CAiIBEQEFAQoEAQ0GEwgKAgcHiBE?= =?us-ascii?q?BAw8IDqNZgTI+MotCgWuCXwWDbgoZJwMKU4MIAQEBAQEBBAEBAQEBAQEBFwMGE?= =?us-ascii?q?IYsg1CBBYR0gleCWwWGbwyTBIFlhEOJU4I8jTiMd4I9Ex6BETRfgjwsghoiNIZ?= =?us-ascii?q?/gUEBAQE?= X-IronPort-AV: E=Sophos;i="5.31,454,1473112800"; d="scan'208,217";a="195867523" Received: from mail-io0-f182.google.com ([209.85.223.182]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 06 Oct 2016 16:46:25 +0200 Received: by mail-io0-f182.google.com with SMTP id j37so17584533ioo.3 for ; Thu, 06 Oct 2016 07:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tbGTDPYUTAbnQZGU2T20e8fapfW4qDz5c1yk4OFuiJQ=; b=EBiM+dNEmKB9XGMgONteKJkadqynRWRSkXA2OI6e3nhVAivUJSQR3winagXUx1grFL 2nt26/sZgoOK+AksIsJB9Gab76wykS7zqhSOlvBO0NCLmawPwkbDLVRWy61Ilg0F1Nu3 WCoZpvwzql4dwUXRWcPtTX33VrXuQU0wGUhG/jSwYHvnFtHDVP+N+bOwwD8Qaulsxm1o S49X/oYAJC8cQaBVQmu2nJhNJFpnZsmoi448OP8bz40iVR4VHWWRP0BUbxqvg/btk9/p mFzJeI9UZnKaMe1efC/u8VcaVlzat5IR1svOd49uA3NAUqiNWD1gtFT4ucMwMD+/G2Ys SyQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tbGTDPYUTAbnQZGU2T20e8fapfW4qDz5c1yk4OFuiJQ=; b=RgYs9PXsSmPh9BtnTm2X9T6LfdoWqF2rW2OcQxsv1NeJlajmyEOZoYqkyoMyVL8JMY BsxBb3aizPRpGhcShPVGjZoijc3cDmnca1kWuH2zNTkZaEWqJNZDtCpFHwwG4UBPFCfi A3eDN5HOvN8HbOLHLrVIMnnNdtDhTnIl43g7si9V+LEfISKMxGcGgr1F8lgMrWn7eIzY 35K21CuWwa21zHBsy14qXvA/l9KyxNXeLfME1+uGJ9NCYaUCRZ89Gath3OMmf8xFLI5t DVwatHmbHNLUhjX1FJSsOOaLN3HnpLPCp2q6lKTP6P3NDhPSYFrfyiexvfzNmzKxnCRo yESA== X-Gm-Message-State: AA6/9Rk6kosqLX5C5T0KaQ48WEJQ5Ck6hU1QMTF2skkHKQ4ceHTyS//G5Xj/LLSd4qZTJ27OF+/An49wyRcBVQ== X-Received: by 10.107.164.209 with SMTP id d78mr15485185ioj.182.1475765184417; Thu, 06 Oct 2016 07:46:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.129.219 with HTTP; Thu, 6 Oct 2016 07:45:43 -0700 (PDT) In-Reply-To: <0F7D3B1B3C4B894D824F5B822E3E5A172CF8E210@IRSMSX102.ger.corp.intel.com> References: <0F7D3B1B3C4B894D824F5B822E3E5A172CF8E1BA@IRSMSX102.ger.corp.intel.com> <645B0ADB30534643B7294B43C28A3F3D@erratique.ch> <0F7D3B1B3C4B894D824F5B822E3E5A172CF8E210@IRSMSX102.ger.corp.intel.com> From: Gabriel Scherer Date: Thu, 6 Oct 2016 10:45:43 -0400 Message-ID: To: "Soegtrop, Michael" Cc: =?UTF-8?Q?Daniel_B=C3=BCnzli?= , "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a11458f8496d489053e335b19 Subject: Re: [Caml-list] ocamlbuild on Windows and bash vs. cmd --001a11458f8496d489053e335b19 Content-Type: text/plain; charset=UTF-8 > And I take this as a "yes" on the question if something like this would be appreciated by the community. This is my impression as well, and I would personally warmly welcome changes to improve Windows users experience -- I think of ocamlbuild as a portable build system, and I would like to work out of the box; I don't think there are any fundamental design limitations that would prevent this good portability experience. One difficulty right now in term of development dynamics is that I don't have a Windows machine to test on myself, so I'm rather conservative regarding Windows-related changes to avoid regressions for non-Windows user (it's not necessarily easy to predict which changes risk breaking stuff), or even regressions for other Windows users (some of the non-intuitive Windows-related code is there because otherwise stuff breaks for some people). Sometimes Windows developers make a certain amount of changes that look right to them and fix actual problems on their system, but then it's hard for me to see what can be safely integrated (see for example https://github.com/ocaml/ocamlbuild/pull/70 , whose low-hanging fruits I could merge quickly, but for the rest I worry of regressions ). To solve that problem we need a better testing infrastructure for ocamlbuild, but also get more tests from Windows users to provide feedback on other approaches or patches reworks, etc. If someone, for example you, is willing to start a more persistent approach of iterative improvements and tests, I think that things could improve rather quickly. On Thu, Oct 6, 2016 at 10:15 AM, Soegtrop, Michael < michael.soegtrop@intel.com> wrote: > Dear Daniel, > > > See https://github.com/ocaml/ocamlbuild/issues/64 > > yes, I have seen the discussion, especially the discussion if one should > use cmd vs. removing the use of a shell by ocamlbuild entirely. I agree > that the latter would be the better solution, but it would be a major > change since currently ocamlbuild wraps everything through string commands. > But maybe it is not as bad as it looks. > > And I take this as a "yes" on the question if something like this would be > appreciated by the community. > > I am a bit in a hurry to get something working for Coq 8.6. I guess I > first make a cmd based hack for Coq and then look into the real solution. > > I will continue the discussion on the ocamlbuild issue tracker item linked > above. > > Best regards, > > Michael > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Christian Lamprechter > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --001a11458f8496d489053e335b19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=20 And I take this as a "yes" on the question if something like this= would be appreciated by the community.

This is my = impression as well, and I would personally warmly welcome changes to improv= e Windows users experience -- I think of ocamlbuild as a portable build sys= tem, and I would like to work out of the box; I don't think there are a= ny fundamental design limitations that would prevent this good portability = experience.


One difficulty righ= t now in term of development dynamics is that I don't have a Windows ma= chine to test on myself, so I'm rather conservative regarding Windows-r= elated changes to avoid regressions for non-Windows user (it's not nece= ssarily easy to predict which changes risk breaking stuff), or even regress= ions for other Windows users (some of the non-intuitive Windows-related cod= e is there because otherwise stuff breaks for some people). Sometimes Windo= ws developers make a certain amount of changes that look right to them and = fix actual problems on their system, but then it's hard for me to see w= hat can be safely integrated (see for example https://github.com/ocaml/ocamlbuild/pull/70 = , whose low-hanging fruits I could merge quickly, but for the rest I worry = of regressions ).

To solve that problem we need a better testing inf= rastructure for ocamlbuild, but also get more tests from Windows users to p= rovide feedback on other approaches or patches reworks, etc. If someone, fo= r example you, is willing to start a more persistent approach of iterative = improvements and tests, I think that things could improve rather quickly.

On Thu, O= ct 6, 2016 at 10:15 AM, Soegtrop, Michael <michael.soegtrop@int= el.com> wrote:
Dear Daniel,

> See https://github.com/ocaml/ocamlbuild/issue= s/64

yes, I have seen the discussion, especially the discussion if one should us= e cmd vs. removing the use of a shell by ocamlbuild entirely. I agree that = the latter would be the better solution, but it would be a major change sin= ce currently ocamlbuild wraps everything through string commands. But maybe= it is not as bad as it looks.

And I take this as a "yes" on the question if something like this= would be appreciated by the community.

I am a bit in a hurry to get something working for Coq 8.6. I guess I first= make a cmd based hack for Coq and then look into the real solution.

I will continue the discussion on the ocamlbuild issue tracker item linked = above.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89= 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--001a11458f8496d489053e335b19--