Re: Removing cygwin32-*, cygwin64-*

Re: Removing cygwin32-*, cygwin64-*

[Arthur Norman]

This question was asked on 9 February, and while my reply is in late 
March that is because I only found this when I installed a fresh cygwin in 
a new virtual machine and found that the cygwin64-* packages that I use 
were no longer present. For the reduce-algebra project (on sourceforge) 
the build sequences I have on Windows really like having all the building 
done from a single shell, so that it can be automated and a single call to 
"make" at the top level builds win32, win64, cygwin32 and cygwin64 
variants... and I then take steps so that when a user tries to launch the 
program it invokes the relevant one of one of those four binaries, 
depending on the context it was launched from. I have not had trouble with 
the cross build of 64 bit executables from the 32-bit world, but 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 - I had expected that to be 
a transient as 64-bit cygwin stabilised and matured. I had even hoped to 
dream that invoking a 64-bin cygwin binary from a 32-bit shell and vice 
versa might eventually happen!
So I will note that I am sad that the cross-compilation capability has 
been withdrawn, and 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.

Using the cross-build scheme it is trivial to have (eg) a cron script or 
access via ssh build both 32 and 64-bit everything. When 32 and 64-bit 
cygwins are fully separate worlds while I know I will be able to cope it 
is more delicate, more messy and extra work for me.

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, and that is really valuable 
work that I am not being asked to pay for, so I am not in a position to 
express outrege - merely distress! I guess my best emergency response to 
this has to be to comment out places in my build where I support the 
version of cygwin I am not running under.

Arthur Norman


--
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

Re: Removing cygwin32-*, cygwin64-*

[Warren Young]

On Mar 28, 2016, at 4:03 AM, Arthur Norman <acn1@cam.ac.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