Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide proper cygwin rebasing scripts #14031

Closed
dimpase opened this issue Jan 29, 2013 · 26 comments
Closed

provide proper cygwin rebasing scripts #14031

dimpase opened this issue Jan 29, 2013 · 26 comments

Comments

@dimpase
Copy link
Member

dimpase commented Jan 29, 2013

Rebasing half-built, or fully built, Sage Cygwin installation currently
needs manual labour. This patch provides shell scripts and MSDOS batch files to make this more automatic, using 'rebaseall' or 'rebase -O'. One will only needs to adjust SAGE_ROOT in the batch file once (per Sage install).
The documentation (outside of within the script themselves) will be provided at #14465.

Apply to sage_scripts:

CC: @kcrisman @jpflori

Component: porting: Cygwin

Keywords: rebaseall, rebase

Author: Dmitrii Pasechnik, Jean-Pierre Flori

Reviewer: Jean-Pierre Flori, Karl-Dieter Crisman

Merged: sage-5.9.rc1

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

@dimpase dimpase added this to the sage-5.10 milestone Jan 29, 2013
@dimpase
Copy link
Member Author

dimpase commented Jan 29, 2013

Attachment: trac_14031.patch.gz

@dimpase
Copy link
Member Author

dimpase commented Jan 29, 2013

comment:1

Is this the right way to provide patches for sage_scripts?

@dimpase

This comment has been minimized.

@kcrisman
Copy link
Member

comment:2

I don't know what you mean by "right way". I usually go into $SAGE_LOCAL/bin and do hg commands from that repository...

rem dash %SAGE_ROOT%\local\bin\s.sh 

But the script isn't called s.sh? I know nothing about DOS so maybe this is obviously right.

An additional remark in the script about just using C:\cygwin\bin\dash.exe in the command prompt would not be amiss, since one could imagine people helping who don't know how to set paths in Windows, or even how to make env vars in Windows (e.g., I have no idea how to set SAGE_ROOT in the Windows command line).

@dimpase
Copy link
Member Author

dimpase commented Jan 29, 2013

comment:3

Replying to @kcrisman:

I don't know what you mean by "right way". I usually go into $SAGE_LOCAL/bin and do hg commands from that repository...

I was wondering whether I need to wrap it up in an spkg...

rem dash %SAGE_ROOT%\local\bin\s.sh 

But the script isn't called s.sh? I know nothing about DOS so maybe this is obviously right.

rem means that the whole line is commented out, same as # for Unix shells.
Indeed, this line can be deleted (a debugging leftover).

An additional remark in the script about just using C:\cygwin\bin\dash.exe in the command prompt would not be amiss,

the batch file does the right thing, if your Cygwin is in C:\cygwin. Otherwise the corr. line there needs to be changed.

since one could imagine people helping who don't know how to set paths in Windows, or even how to make env vars in Windows (e.g., I have no idea how to set SAGE_ROOT in the Windows command line).

no, it is meant to be changed in the batch file body. Perhaps I should mention that it is meant to call the dash script from the batch file, and not directly.

By the way, setting BLAH to foo in the Windows command line is just

set BLAH=foo

And if you need to evaluate BLAH you do %BLAH%, e.g.

echo %BLAH%

will print BLAH's value. You might also want to know that if you call dash after setting BLAH, it will be known to dash, and can be evaluated as usual, i.e. as $BLAH. dash will also treat PATH in a special way, by trying to translate it into Cygwin's PATH in some cases. But I digressed. :-)

@kcrisman
Copy link
Member

comment:4

I don't know what you mean by "right way". I usually go into $SAGE_LOCAL/bin and do hg commands from that repository...

I was wondering whether I need to wrap it up in an spkg...

No, one can just do the usual hg thing.

But the script isn't called s.sh? I know nothing about DOS so maybe this is obviously right.

rem means that the whole line is commented out, same as # for Unix shells.

I did figure that out eventually by staring at it :)

Indeed, this line can be deleted (a debugging leftover).

Good.

no, it is meant to be changed in the batch file body. Perhaps I should mention that it is meant to call the dash script from the batch file, and not directly.

Sure. I would have just called it directly somehow.

But I digressed. :-)

Useful info, though!

@jpflori
Copy link

jpflori commented Feb 13, 2013

comment:5

We should also/instead provide a bash script using rebase -O as Dima suggested on #6743.

@jdemeyer
Copy link

comment:6

Please add your real name as Author.

@dimpase
Copy link
Member Author

dimpase commented Mar 13, 2013

Author: Dmitrii Pasechnik

@kcrisman
Copy link
Member

comment:8

We should also/instead provide a bash script using rebase -O as Dima suggested on #6743.

+1 - this worked very nicely for me recently. I don't see why one couldn't replace the current one with that.

@jpflori
Copy link

jpflori commented Mar 14, 2013

comment:9

It would also be nice to mention the /etc/rebase.db.i386 file, its use and the potential need to clean it up (or at least it seems that at some point deleting it was useful for some of us, Dima could you confirm that?).

@kcrisman
Copy link
Member

comment:10

There is also a tiny typo.

C:\cygin\bin)

It doesn't affect things because it's in a comment, but could affect users.

@jpflori
Copy link

jpflori commented Apr 16, 2013

Attachment: trac_14031-scripts.patch.gz

Updated scripts, using rebaseall or rebase -O.

@jpflori
Copy link

jpflori commented Apr 16, 2013

Changed author from Dmitrii Pasechnik to Dmitrii Pasechnik, Jean-Pierre Flori

@jpflori

This comment has been minimized.

@kcrisman
Copy link
Member

Dependencies: #14465

@kcrisman

This comment has been minimized.

@jpflori
Copy link

jpflori commented Apr 18, 2013

comment:13

I'm not sure #14465 should be an explicit dependency.
The script are already self documented, so we could merge this even without #14465.

@kcrisman
Copy link
Member

Changed dependencies from #14465 to none

@kcrisman
Copy link
Member

comment:14

The script are already self documented, so we could merge this even without #14465.

Fair enough.

By the way, I give positive review to the actual commands, as does no doubt J-P. But I haven't (and won't have) had the chance to try out the actual scripts "in production" as my Cygwin is not available currently, and someone should try them in such a situation just to make sure we didn't miss a typo or something, or that the extreme minimality of the shells in Windows doesn't cause one of them to hiccup (dash doesn't even have an ls command!).

@kcrisman
Copy link
Member

Reviewer: Jean-Pierre Flori, Karl-Dieter Crisman

@jdemeyer
Copy link

comment:15

Replying to @kcrisman:

I give positive review to the actual commands

Great! We can still fix bugs later.

@jdemeyer
Copy link

Merged: sage-5.9.rc1

@dimpase
Copy link
Member Author

dimpase commented May 31, 2013

comment:17

I had a situation when I needed to rebase before sage_scripts spkg was installed (while building python spkg), so sage-rebase was not installed.

This is a kind of bug I don't know how to address properly (although installing the spkg with ./sage -f did help).
At least this got to be documented.

@jdemeyer
Copy link

comment:18

Replying to @dimpase:

This is a kind of bug I don't know how to address properly

Move the scripts to $SAGE_ROOT/spkg/bin. That's really the place for scripts which are needed at build-time.

@dimpase
Copy link
Member Author

dimpase commented Jun 14, 2013

comment:19

Replying to @jdemeyer:

Replying to @dimpase:

This is a kind of bug I don't know how to address properly

Move the scripts to $SAGE_ROOT/spkg/bin. That's really the place for scripts which are needed at build-time.

I've opened #14742 to deal with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants