From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81857 invoked by alias); 28 Mar 2016 21:25:22 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 81846 invoked by uid 89); 28 Mar 2016 21:25:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=dying, roi, ROI, H*r:qmail-ldap-1.03 X-HELO: etr-usa.com Received: from etr-usa.com (HELO etr-usa.com) (130.94.180.135) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 Mar 2016 21:25:10 +0000 Received: (qmail 31683 invoked by uid 13447); 28 Mar 2016 21:25:09 -0000 Received: from unknown (HELO polypore.west.etr-usa.com) ([73.26.17.49]) (envelope-sender ) by 130.94.180.135 (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 28 Mar 2016 21:25:09 -0000 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 In-Reply-To: Date: Mon, 28 Mar 2016 21:25:00 -0000 Content-Transfer-Encoding: quoted-printable Message-Id: <26D869CD-02D1-4EA8-A655-1323FA39EB33@etr-usa.com> References: To: The Cygwin Mailing List X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00531.txt.bz2 On Mar 28, 2016, at 4:03 AM, Arthur Norman wrote: >=20 > 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=E2=80=99s 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 fu= ll sey of cross 32-bit libraries were not provided there If you install separate 32- and 64-bit Cygwin installations on a 64-bit Win= dows system, you don=E2=80=99t need to wait for someone to provide the full= set of cross-compilation libraries. Presumably the native Cygwin librarie= s 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 o= f only one way to make that work, and it would be a huge effort to make tha= t 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 rea= lly 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 Cyg= win only has two full-time employees, and has for many, many years. Meanwhile, 32-bit is dying, so it=E2=80=99s a shrinking ROI problem. Yes, granted, 32-bit isn=E2=80=99t going away anytime soon, but it surely i= sn=E2=80=99t growing, either. Meanwhile, you=E2=80=99re 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=E2=80=99m sure Yaakov would let you take over maintainership of all the p= ackages needed to make that happen. > I rather feel that the small collection of responses to a question that a= sks "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 g= ood 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 p= ackages to keep one user every ~6 weeks happy? I=E2=80=99d rather he spent the same amount of effort on packages used by h= undreds or thousands of users a day. > I can on the other hand understand that for cygwin maintainers that looki= ng after and checking both 32 and 64-bit worlds and then cross environments= in both directions adds to work You=E2=80=99re right: the GCC toolchains, their dependent libraries (newlib= , libbfd, etc.) and all of the core libraries needed to make those tools us= eful are among the most complex packages in all of Cygwin. Today, there ar= e two of these build systems. Bringing back cross-compilation toolchains e= ssentially 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