This is the mail archive of the
mailing list for the Cygwin project.
Re: Removing cygwin32-*, cygwin64-*
- From: Warren Young <wyml at etr-usa dot com>
- To: The Cygwin Mailing List <cygwin at cygwin dot com>
- Date: Mon, 28 Mar 2016 15:25:08 -0600
- Subject: Re: Removing cygwin32-*, cygwin64-*
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot WNT dot 2 dot 00 dot 1603281018590 dot 496 at panamint>
On Mar 28, 2016, at 4:03 AM, Arthur Norman <firstname.lastname@example.org> 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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple