X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:mime-version
	:content-transfer-encoding; q=dns; s=default; b=sHeS1JcSiLTBhk7b
	YR7kCYrCt4qpjURQyD+i0XOhgT8P4h/t2edbaVLelX/lrqyiuLz6Z8EUVCB4fuNZ
	pHNyEyEXOdfc56UL3PWEtQiBSJY4PAjgEsFfp+Gj0g/EkRToUzs6B4FdHLyf3SZE
	9eyidCRm3T2WHfJpT5KjjGB1BS0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:mime-version
	:content-transfer-encoding; s=default; bh=mgVuSP7mcWvuKLi/g4Lftz
	2/Czc=; b=qRn77LZbAXOZFFmDXYkWx2sZpEwy7Xm/vofSjCG/JOlOTSD6jA26Tl
	v4CXDANxjJhB2qMbn7p7Skz7LmZsc5Hxzpt0TwOwFZNPOVG1mWC4tUbrWRQ4iDYs
	xSojUpJc5bk6ADSb5xVco6c3/pXFD7XRw5Ft3CRA5iRI7T4pn2Ey0=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,MIME_BASE64_BLANKS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=oriented, communicated, pragmatic, assistant
X-HELO: mga09.intel.com
X-ExtLoop1: 1
From: "Soegtrop, Michael" <michael DOT soegtrop AT intel DOT com>
To: Eric Blake <eblake AT redhat DOT com>, "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: RE: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
Date: Fri, 9 Jun 2017 16:56:41 +0000
Message-ID: <0F7D3B1B3C4B894D824F5B822E3E5A175B2705E9@IRSMSX102.ger.corp.intel.com>
References: <0F7D3B1B3C4B894D824F5B822E3E5A175B2636E4 AT IRSMSX103 DOT ger DOT corp DOT intel DOT com> <a53282b6-d00c-aad8-76a6-26b4089a9623 AT redhat DOT com> <0F7D3B1B3C4B894D824F5B822E3E5A175B26CE47 AT IRSMSX102 DOT ger DOT corp DOT intel DOT com> <59399CC5 DOT 60900 AT tlinx DOT org> <417f84ac-5d9f-dc50-e912-973e90b8a128 AT redhat DOT com> <0F7D3B1B3C4B894D824F5B822E3E5A175B26F278 AT IRSMSX102 DOT ger DOT corp DOT intel DOT com> <34b26965-34c2-b5f0-a3f2-b2c3df344b08 AT gmail DOT com> <0F7D3B1B3C4B894D824F5B822E3E5A175B270518 AT IRSMSX102 DOT ger DOT corp DOT intel DOT com> <5313de97-d9bd-d9c9-cb4a-254a3eadcf4a AT redhat DOT com>
In-Reply-To: <5313de97-d9bd-d9c9-cb4a-254a3eadcf4a@redhat.com>
dlp-product: dlpe-windows
dlp-version: 10.0.102.7
dlp-reaction: no-action
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-IsSubscribed: yes
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id v59Gv3vx010660

Dear Eric,

> Building mingw apps may be one use of cygwin, but it is not the "intended use
> case". 

I said "an" intended use case, not "the". I also use cygwin for a lot of other things.

> If you are writing a Linux app that processes data produced on a windows
> machine, then YOU must strip CR from that data (Linux sed will NOT strip it).
> So now cygwin sed does the same thing.

Maybe my situation gets clear when I describe what my use case is: I maintain the scripts which build the Windows installers for Coq - a proof assistant with a GTK based UI. This starts building a MinGW OCaml compiler from sources. I could also build a host=cygwin target=MinGW OCaml compiler, to get around the issue that messages it produces contain CRs, but OCaml doesn't support host!=target very well, and many of the tools it produces I also have to run under cygwin. So I would need 3 OCaml compilers, one build=cygwin, host=cygwin, target=cygwin to build the tools I run under cygwin during the build, then one build=cygwin, host=cygwin, target=MinGW to build the tools I finally need for plain Windows. But since Coq also needs OCaml at run time I also would have to build a build=cygwin, host=MinGW, target=MinGW variant. Many of the tools and libs I need have similar issues.
 
I admit I am lazy and build only one OCaml compiler, the build=cygwin, host=MinGW, target=MinGW variant, because I will need this eventually anyway. The only issue this results in is that its text messages (like version or lib path info) contain carriage returns.

All the OCaml and Coq build scripts (and the build scripts for the libraries and tools I need) themselves are not maintained by me. I just maintain the wrapper which sets up a fresh cygwin, gets all the sources, builds the whole stuff and finally produces a Windows installer for others to use. I call many scripts and tools which are originally designed to run on Linux and are maintained by Linux centric people and I do not want to bother them with such issues.

Cross building on Linux would be much more complicated, because on Linux I would no matter what need 3 OCaml variants but also 2 Coq variants, because I need to compile the Coq libraries, so I need to run Coq on the build host as well. With cygwin I can call the MinGW variants. 

All this did work remarkably well on cygwin, because cygwin had support to call MinGW programs and to process their text oriented output.

I don't see another way than having sed strip away the CRs. It doesn't make sense to build programs intended to be run under plain Windows such that they do not produce CRs. It doesn't make sense to hack around in build scripts and source code of Linux centric tools just to get this Windows build done. The true way would be to support host!=target in OCaml and to make 2..3 host/target build variants of everything. But it would take ages, waste a lot of energy (think of the CI test severs), slow down development, ... and all this just to get rid of maybe 200 carriage return characters in strings communicated in a build process.

For me, cygwin is a pragmatic tool to get the job done. And it does, perfectly and better than I expected when I started this, except that current cygwin's text tools can't process text produced by MinGW tools out of the box any more.

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple