DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; q=dns; s=default; b=faafl+zAydaaT29+BODQcEurLQGm
	duXKoHdexM2BKvSmHQwRHGsV53oDJXjcjmgPMECy45yJKC7iCHD+cy33Wfs4heff
	JC847Rsn8xtS9+zrtzGHUX7mifn3lCdp9tjHnxJ2FXjKkUWcbUNcqGEdKkUE/nRI
	a4pZ7zABCGiz5B0=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Removing cygwin32-*, cygwin64-*
From: Warren Young <wyml AT etr-usa DOT com>
In-Reply-To: <alpine.WNT.2.00.1603281018590.496@panamint>
Date: Mon, 28 Mar 2016 15:25:08 -0600
Message-Id: <26D869CD-02D1-4EA8-A655-1323FA39EB33@etr-usa.com>
References: <alpine DOT WNT DOT 2 DOT 00 DOT 1603281018590 DOT 496 AT panamint>
To: The Cygwin Mailing List <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

On Mar 28, 2016, at 4:03 AM, Arthur Norman <acn1 AT cam DOT ac DOT uk> wrote:
> 
> the build sequences I have on Windows really like having all the building done from a single shell, so that it can be automated

What’s difficult about treating Cygwin 32 and Cygwin 64 as separate platforms, each with its own Cygwin installation on your build server, and consequently its own toolchain?

> have not moved to running in a 64-bit cygwin world in part because the full sey of cross 32-bit libraries were not provided there

If you install separate 32- and 64-bit Cygwin installations on a 64-bit Windows system, you don’t need to wait for someone to provide the full set of cross-compilation libraries.  Presumably the native Cygwin libraries you need are available for both Cygwins.

> I had even hoped to dream that invoking a 64-bin cygwin binary from a 32-bit shell and vice versa might eventually happen!

Simply launching Cygwin binaries of a different bitness does work, and has for a long time. Over a year, probably.

If you mean that all of the cross-process mechanisms you get within a given Cygwin version should work across different Cygwin installations, I know of only one way to make that work, and it would be a huge effort to make that happen.

Pretty much the only organizations that go to that kind of effort are major operating system providers, because the layer required to do this is a really tricky bit of assembly language magic that translates all system calls on the fly, transparently.

Doable?  Sure.  But by whom?  As far as I know, the organization behind Cygwin only has two full-time employees, and has for many, many years.

Meanwhile, 32-bit is dying, so it’s a shrinking ROI problem.

Yes, granted, 32-bit isn’t going away anytime soon, but it surely isn’t growing, either.

Meanwhile, you’re proposing that all this work be done in the face of an existing solution: parallel installations.

> I am sad that the cross-compilation capability has been withdrawn

I’m sure Yaakov would let you take over maintainership of all the packages needed to make that happen.

> I rather feel that the small collection of responses to a question that asks "is anybody using..." by saying "never used them" and "I gave up" only say that THOSE people wopuld not be inconvenieced, and are to my mind not good evidence that none of us would be.

Is it also your opinion that the single busiest Cygwin package maintainer (Yaakov) should maintain one of the largest and most complex set of Cygwin packages to keep one user every ~6 weeks happy?

I’d rather he spent the same amount of effort on packages used by hundreds or thousands of users a day.

> I can on the other hand understand that for cygwin maintainers that looking after and checking both 32 and 64-bit worlds and then cross environments in both directions adds to work

You’re right: the GCC toolchains, their dependent libraries (newlib, libbfd, etc.) and all of the core libraries needed to make those tools useful are among the most complex packages in all of Cygwin.  Today, there are two of these build systems.  Bringing back cross-compilation toolchains essentially doubles that effort.

So again, I ask, why do all that for such poor ROI?
--
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