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
- From: "Soegtrop, Michael" <michael.soegtrop@xxxxxxxxx>
- Subject: RE: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
> Building mingw apps may be one use of cygwin, but it is not the "intended use
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.
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