Cygwin metaticket: port Sage to Microsoft Windows (via Cygwin)

[kcrisman]

Thanks to #6743, Sage now builds on Cygwin with make and appropriate prereqs.

This metaticket tracks further status of Sage on Cygwin.

Depends on #6743

CC: @jpflori @dimpase @williamstein @eviatarbach

Component: porting: Cygwin

Reviewer: Jean-Pierre Flori, Karl-Dieter Crisman

Issue created by migration from https://trac.sagemath.org/ticket/13841

[kcrisman]

Dependencies: #6743

[kcrisman]

comment:1

Looks like we won't need this... of course, one never knows, with all the upgrades to spkgs in every version! Anyway, I'm setting this to sage-pending on #6743 for now.

[jpflori]

comment:2

I guess we should close this one.

[kcrisman]

comment:3

Until #6743 is merged, I say never say never! There always seems to be some crazy thing that stands in the way.

[kcrisman]

comment:4

Given that #6743 is closed (though not merged in a specific Sage version yet), perhaps this should be as well now? Are the 5.10 betas doing well on Cygwin?

With respect to keeping it working... JP, are you saying that you have the hardware and time to commit to monitoring this for (say) 2 years? I just don't have the access to Windows/time to mess with them often enough to guarantee this; given how finicky Cygwin is, we will likely have to keep fixing things that other tickets do - either in terms of missing includes in pyx files or in terms of spkgs which don't have proper stuff... Thanks for all your amazing work on this!

[kcrisman]

Reviewer: Jean-Pierre Flori, Karl-Dieter Crisman

[jdemeyer]

comment:5

Replying to @kcrisman:

JP, are you saying that you have the hardware and time to commit to monitoring this for (say) 2 years?

I think hardware shouldn't be the problem, I'm sure William can setup a VM for this if needed. Time, on the other hand, is a more valuable resource...

[jpflori]

comment:6

Replying to @jdemeyer:

Replying to @kcrisman:

JP, are you saying that you have the hardware and time to commit to monitoring this for (say) 2 years?

I think hardware shouldn't be the problem, I'm sure William can setup a VM for this if needed.

Yeah that would be very helpful, at least for a buildbot (though it may need human intervention somehow because of rebasing issues, but also note that 64 bits cygwin is on its way and seems quite already in a usale state except for the lack of an installer and me being able to find where to downnload it!).

Time, on the other hand, is a more valuable resource...

For at least one year, or mybe two years, i.e. until I change job, I should have some time for that.

[jpflori]

comment:7

And having VMs already turned on somewhere would also be nice to run things such as "make ptestlong" which are incredibly slow because of forking.

[dimpase]

comment:8

A buildbot would need a cygwin-less way to log in onto it, otherwise rebasing can't always be done. And the standard WIndows way (with a GUI -- "remote desktop connection") might be too slow if the work needs to be done across continents. Are there alternatives? I don't really know. There are sshd "native" WIndows implementations, but I never tried them.

[jpflori]

comment:9

Using "rebase -O" should be possible even though other Cygwin processes are running (as long as nothing from Sage is).

[dimpase]

comment:10

Replying to @jpflori:

Using "rebase -O" should be possible even though other Cygwin processes are running (as long as nothing from Sage is).

yes, but if you want to install a new version of Sage, then you probably want to wipe the rebase databases and do a full, cygwin-less, rebase.

[jpflori]

comment:11

I'd say the trick would be to never let Sage enter the rebase database by only using "rebase -O" :)

[dimpase]

comment:12

Replying to @jpflori:

I'd say the trick would be to never let Sage enter the rebase database by only using "rebase -O" :)

Are you sure that "rebase -O" does not add stuff to the database? I thought it does, it just does not move what's already there...

[jpflori]

comment:13

Replying to @dimpase:

Replying to @jpflori:

I'd say the trick would be to never let Sage enter the rebase database by only using "rebase -O" :)

Are you sure that "rebase -O" does not add stuff to the database? I thought it does, it just does not move what's already there...

Yup, completely sure, it just reads what's there to rebase after what already exists, but does not write anything.

E.g. if you "rebase -O" two copies of sage and try to run them at the same time, it will likely fail because "rebase -O" will have used the same addesses.

[jdemeyer]

comment:14

Replying to @jpflori:

And having VMs already turned on somewhere would also be nice to run things such as "make ptestlong" which are incredibly slow because of forking.

What is "incredibly slow"? For me, there is no problem if Sage can be built and tested within 48 hours. Is that feasible?

[dimpase]

comment:15

Replying to @jpflori:

Replying to @dimpase:

Replying to @jpflori:

I'd say the trick would be to never let Sage enter the rebase database by only using "rebase -O" :)

Are you sure that "rebase -O" does not add stuff to the database? I thought it does, it just does not move what's already there...

Yup, completely sure, it just reads what's there to rebase after what already exists, but does not write anything.

The mapping of dlls to addresses must be stored somewhere. (where?)
Are you saying that the next run of "rebase -O" completely erases this mapping, and builds a new one from scratch?

[jpflori]

comment:16

I'd say it's stored into the dlls themselves, not sure though, but not in the system-wide database for sure, my usual user doesnt have write access to it anyway.

I'm not sure a second run would change everything, it just acts like a usual rebase (without -O) but does not record the results into the system-wide database, so if no dll was added into the global database and you're not adding new stuff to the list of additional files you want to rebase then nothing will change (maybe if you remove some then it will try to pack the address space used).

[embray]

comment:19

This ticket hasn't been updated in 4+ years, and doesn't really discuss anything that's still an open issue for the Cygwin port.

The best way right now to track progress on the Cygwin port is to just search on the porting: Cygwin component.