On Mon, Sep 8, 2014 at 4:24 PM, Stephen Leake <[email protected]> wrote: > I've gotten Emacs to build under msys2; I'll look into providing an msys > package for it. > > In the process, I reinstalled msys2 several times, in order to avoid > rebase issues I encountered. So I have some notes on improving > http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ > > Is that page in a CM system? Perhaps I could use that to create a patch. >
No, it's not. We do also have: http://msys2.github.io/ which is stored on github ( https://github.com/msys2/msys2.github.io ) you could fork that if you were interested in improving the instructions on that site to include horrible details of rebasing etc. > In the meantime, some comments: > > I Downloading. > > It would help to clarify what 32-bit and 64-bit mean. They indicate what > machine you are running on, not what machine you want to target. People > building packages will often want to build a 32 bit program on a 64 bit > machine (because the package has not yet been ported to 64 bit), and be > confused by this choice (this happened to me). > > Perhaps something like: > > 1. 32-bit for a 32 bit host > > 2. 64 bit for a 64 bit host > > You can build and run 32 bit programs with the 64 bit install. > > > When I ran the installer for the very first time, it somehow located my > Cygwin HOME directory, and used the .bash_profile from there. That was > very confusing, not to say disturbing. Did you have a Windows env. var of HOME set to your Cygwin HOME? That would explain it. We should remove HOME from the environment passed to the execution of bash.exe that happens from within the installer in that case, I think. A log from the installer here would be useful if you can provide it ("Show Details" button AFAIR, or the text file written out to the root installation folder). > > How did that happen? How can I prevent this on my next new Windows box? > > > Restarting c:/msys64/msys64_shell.bat used the correct > c:/msys64/home/stephe directory, and informed me that it was copying > .bash_profile etc, as expected. > > However, later I deleted c:/msys64, and ran the installer again. It used > the correct, but empty home directory, and _silently_ copied in the > .bash_profile etc. It should have said it was doing the copy. Again, "Show Details" from the installer should show a log from this copy process. > > I'm guessing the installer sets some state in the Windows Registry; is > that documented somewhere, so I can delete it when I have problems > installing in the future (things do change)? > It does store a very small amount of stuff in the registry, yes, just so that Uninstall can be run from the Control Panel. The keys are at: HKEY_USERS\<UUID>\Software\Microsoft\Windows\CurrentVersion\Uninstall\MSYS2 32bit HKEY_USERS\<UUID>\Software\Microsoft\Windows\CurrentVersion\Uninstall\MSYS2 64bit .. if you re-install elsewhere then these keys will be overwritten with new values. Uninstalling should also remove them. Having 'stale' values in there (e.g. if you manually deleted MSYS2) should be harmless, except that trying to uninstall from Control Panel will fail. > > II updates and general package management > > Step 1 is simply wrong if the installer is older than the current > central repository, which will normally be the case. The installer I > used is dated 2014-07-04, and I had rebase problems with this command. > There's differing opinions on how msys2-base should be managed. Mine is that the best thing to do is to remove all those packages from pacman and only provide them via the installer (which can be tweaked to also function as an updater). We need something more robust than the current scheme, that's for certain. > I reinstalled several times, trying to find a sequence of updated > package installations that did not report rebase problems. Below is what > I came up with. > > It would help to separate the discussion of the issues from the recipe > for upgrading. This is what I have in my notes: > > pacman maintains a local database of package versions. You have > control over when that database is updated from the central > repository. > > Running pacman can change dlls that are currently in use without > checking, which can cause the post-install scripts to fail. This > can happen any time you update the local package version database, > since the central repository is updated often, and any new package > you install may require an updated dll. > > During updating, kill the msys shell with the Windows X button > immediately after running pacman; doing anything else in the shell > after runnig pacman, including "exit", may run into the dll > problem. > > To update safely: > > - exit all msys2 processes, start a new shell from Windows Explorer: > c:\msys64\msys2_shell.bat > > - In the msys shell: > > $ pacman -Sy > # updates local package database from central repository > > $ pacman -S --needed filesystem msys2-runtime libiconv \ > libarchive libgpgme libcurl pacman ncurses libintl > > - from Windows Explorer: > > run c:\msys64\autorebase.bat > run c:\msys64\msys2_shell.bat > > - In the msys shell: > > $ pacman -S --needed bash libreadline > > - from Windows Explorer: > > run c:\msys64\autorebase.bat > run c:\msys64\msys2_shell.bat > > > Since many (most? hopefully fewer as more prebuilt packages become > available :) people installing msys2 will want to install a compiler in > order to build packages, it would help to say how to do that simply: > > To install a standard set of development tools, including gcc for > several languages: > > - for building 32 bit programs: > > $ pacman -S mingw-w64-i686-toolchain > > - for building 64 bit programs: > > $ pacman -S mingw-w64-X86_64-toolchain > Slightly related, I noticed you posted this to emacs devel mailing list recently: > x86_64-pc-msys is the correct host identifier, but we will never actually > build an Emacs for that machine; we will always want to build for > i686-pc-mingw32 or x86_64-pc-mingw32. > It might make sense to have configure translate x86_64-pc-msys to > x86_64-pc-mingw32, and i686-pc-msys to i686-pc-mingw32. I am not sure why you would never want an MSYS2 version of emacs, or indeed if that wouldn't be preferable. I don't know much about emacs, but MSYS2 versions of programs allow forking to be performed, and for Unix-y curses/text-based editors forking is often called upon. We have vim as an MSYS2 package, and not as a MinGW-w64 package for example, same thing is true for nano .. then again, if emacs has been ported to native Windows in a comprehensive manner then fair enough, but an MSYS2 version may still be wanted by some? > -- > -- Stephe > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > Msys2-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/msys2-users ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
