Re: FAQ entries about emacs
Hi Volker, On Feb 22 21:37, Dr. Volker Zell wrote: Corinna Vinschen writes: Hi Volker, can you do me a favor? Can you have a look into the FAQ entries Is there a Cygwin port of GNU Emacs? and the next one What about NT Emacs? and suggest a rewrite? The information given in these two FAQ entries is certainly outdated, but I'm not quite sure how to rephrase them. What especially bugs me is the reference to X11 which, as far as I know, is not correct for XEmacs. Maybe (but that's just a vague idea from an Emacs non-user) it might be a good idea to pull the two FAQ entries together into one Is there a Cygwin port of Emacs? and just talk about XEmacs and GNU emacs, whatever the actual difference is. --- /o/download/faq-using.xml.orig2009-02-22 20:36:51.078125000 +0100 +++ /o/download/faq-using.xml 2009-02-22 21:34:36.359375000 +0100 @@ -806,12 +806,50 @@ Thank you! Unfortunately I have a problem. The patch applies cleanly, but the result doesn't build. The easy part was to fix the usage of `' in the screen sections, they just have to be converted to `amp;'. But the really big problem is that the para and itemizedlist markers are not correctly balanced. I tried to fix that myself, but it occured to me that I'm not sure what your exact intention was. Can you have another look, please? Thank you, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: FAQ entries about emacs
Corinna Vinschen writes: Thank you! Unfortunately I have a problem. The patch applies cleanly, but the result doesn't build. The easy part was to fix the usage of `' in the screen sections, they just have to be converted to `amp;'. But the really big problem is that the para and itemizedlist markers are not correctly balanced. I tried to fix that myself, but it occured to me that I'm not sure what your exact intention was. Can you have another look, please? Try this one: --- faq-using.xml.orig 2009-02-22 20:36:51.078125000 +0100 +++ faq-using.xml 2009-02-23 13:41:38.359375000 +0100 @@ -806,13 +806,46 @@ /answer/qandaentry qandaentry id=faq.using.xemacs -questionparaWhat about XEmacs?/para/question +questionparaIs there a Cygwin port of XEmacs?/para/question answer -paraFor a concise description of the current situation with XEmacs, see -this message from the Cygwin mailing list: -ulink url=http://cygwin.com/ml/cygwin/2002-11/msg00609.html;http://cygwin.com/ml/cygwin/2002-11/msg00609.html/ulink. +paraYes. It can be used in three different modes:/para +paraitemizedlist +listitemparaX11 (ulink url=http://cygwin.com/xfree/;http://cygwin.com/xfree//ulink) GUI/para/listitem +/itemizedlist/para +paraYou have to emphasisset/emphasis the DISPLAY environment variable +before starting xemacs./para +screen + bash$ DISPLAY=127.0.0.1:0 xemacs amp; +/screen +paraitemizedlist +listitemparaWindows native GUI/para/listitem +/itemizedlist/para +paraYou have to emphasisunset/emphasis the DISPLAY environment variable +before starting xemacs./para +screen + bash$ DISPLAY= xemacs amp; +/screen +paraitemizedlist +listitemparaConsole mode/para/listitem +/itemizedlist/para +paraStart xemacs with -nw in a terminal (native or X11) window/para +screen + bash$ xemacs -nw +/screen +paraThe current stable Cygwin version of XEmacs is 21.4.x. But there is also a +Cygwin test release version (21.5.x) available for download via setup.exe. /para +paraTo use all the standard packages with XEmacs you should download the following +two packages:/para +paraitemizedlist +listitemparaxemacs-sumo - XEmacs standard packages/para/listitem +listitemparaxemacs-mule-sumo - XEmacs MULE (MUlti Lingual Emacs) packages/para/listitem +/itemizedlist/para +paraAn alternative emphasisnative/emphasis distribution of XEmacs for +Windows based systems can be downloaded from +ulink url=http://xemacs.org/Download/win32/index.html;http://xemacs.org/Download/win32/index.html/ulink. +It uses an emphasisInnoSetup Kit/emphasis based installer./para /answer/qandaentry qandaentry id=faq.using.ntemacs Ciao Volker
Re: FAQ entries about emacs
On Feb 23 14:41, Dr. Volker Zell wrote: Try this one: --- faq-using.xml.orig2009-02-22 20:36:51.078125000 +0100 +++ faq-using.xml 2009-02-23 13:41:38.359375000 +0100 @@ -806,13 +806,46 @@ Thanks! I've checked this in and uploaded it to http://cygwin.com/1.7/faq/faq.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[RFU-1.7] astyle-1.23-1
wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/astyle-1.23-1.tar.bz2 \ http://emergedesktop.org/cygwin/astyle-1.23-1-src.tar.bz2 Given the email from Corrina (I believe it was) a while back about influencing people to try the 1.7.0 release, I have not created any 1.5.x packages for this release (I don't have a 1.5.x install on my development box any more). Is this acceptable, or do I need to still create a 1.5.x release for this package? Thanx! Chris -- Chris Sutcliffe http://emergedesktop.org
ITP: tack-1.06-1
The tack program is a diagnostic that is designed to create and verify the correctness of terminfo's. This program can be used to create new terminal descriptions that are not included in the standard terminfo database. tack was distributed as part of the ncurses package until (upstream) 5.7, when it was spun out into its own package. Since I have updated cygwin's ncurses package(s) to 5.7, the new versions are deficient compared to the old ones. This package remedies that. tack is part of Fedora 7, 8, 9, and 10: http://koji.fedoraproject.org/koji/packageinfo?packageID=5002 setup.hint == category: Utils requires: cygwin libncurses8 sdesc: Utility for creating and verifying termi ldesc: The tack program is a diagnostic that is create and verify the correctness of terminfo's. can be used to create new terminal descriptions included in the standard terminfo database. setup.hint == cygwin-1.5: http://cygwin.cwilson.fastmail.fm/ITP/tack-1.06-1-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/tack-1.06-1.tar.bz2 cygwin-1.7: http://cygwin.cwilson.fastmail.fm/ITP/tack-1.06-10-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/tack-1.06-10.tar.bz2 OK to upload? -- Chuck
Re: ITP: tack-1.06-1
On Mon, Feb 23, 2009 at 09:10:17PM -0500, Charles Wilson wrote: The tack program is a diagnostic that is designed to create and verify the correctness of terminfo's. This program can be used to create new terminal descriptions that are not included in the standard terminfo database. tack was distributed as part of the ncurses package until (upstream) 5.7, when it was spun out into its own package. Since I have updated cygwin's ncurses package(s) to 5.7, the new versions are deficient compared to the old ones. This package remedies that. tack is part of Fedora 7, 8, 9, and 10: http://koji.fedoraproject.org/koji/packageinfo?packageID=5002 setup.hint == category: Utils requires: cygwin libncurses8 sdesc: Utility for creating and verifying termi ldesc: The tack program is a diagnostic that is create and verify the correctness of terminfo's. can be used to create new terminal descriptions included in the standard terminfo database. setup.hint == cygwin-1.5: http://cygwin.cwilson.fastmail.fm/ITP/tack-1.06-1-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/tack-1.06-1.tar.bz2 cygwin-1.7: http://cygwin.cwilson.fastmail.fm/ITP/tack-1.06-10-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/tack-1.06-10.tar.bz2 OK to upload? Sure. If we can't trust you to know the drill by now then the Cygwin project is in seriously bad shape. cgf
Re: ITP: tack-1.06-1
Christopher Faylor wrote: setup.hint == category: Utils requires: cygwin libncurses8 sdesc: Utility for creating and verifying termi ldesc: The tack program is a diagnostic that is create and verify the correctness of terminfo's. can be used to create new terminal descriptions included in the standard terminfo database. setup.hint == Sure. If we can't trust you to know the drill by now then the Cygwin project is in seriously bad shape. Well, except cut and paste appears to be to difficult for little ol' me. g The actual setup.hint: setup.hint == category: Utils requires: cygwin libncurses8 sdesc: Utility for creating and verifying terminfo descriptions ldesc: The tack program is a diagnostic that is designed to create and verify the correctness of terminfo's. This program can be used to create new terminal descriptions that are not included in the standard terminfo database. setup.hint == Uploading now... -- Chuck
Re: ITP: tack-1.06-1
Charles Wilson wrote: create and verify the correctness of terminfo's. This program ^ Superfluous grocer's apostrophe :) cheers, DaveK
GCC4 status.
Quick progress report. - GNAT EH failures fixed. - Fixed GIJ (and libjvm) shared builds. - Packaging adjusted as per previous discussions. - New-and-final release of 3.3.3 to introduce suffixed executables and alternatives symlinks built, now regtesting. Final steps now underway: - Add alternatives usage to gcc-4 packaging. - Add fix for DLL rebasing problem. - Final build and regtest 4.3.2 compiler and check new packaging works. - Check new packaging works right for 3.3.3 compiler. Immediately after native 4.3.2-2 released: - Adding i686-pc-mingw32 cross compiler build to gcc-4 cygport file (already under way, last build failed with libgomp needs pthreads error - need to get myself win32-pthreads for MinGW, I think). - Minor hacks to package generation for mingw x-compiler. - Build, regtest, package test and upload. (Then I'll start work on 4.5.0 upstream; I want to get upstream gcc using DW2 EH by default, fix weak symbol handling, and we'll see about those foreign frames.) cheers, DaveK
Re: GCC4 status.
Dave Korn wrote: - New-and-final release of 3.3.3 to introduce suffixed executables and Dur. I mean 3.4.4. alternatives symlinks built, now regtesting. BTW, I've chosen a release number of 3.4.4-999 for this, because I felt like no other version number says End of the line quite so well. I needed to skip at least one version number because I used 3.4.4-4 for a custom build that had some patches not suitable for upstream release, and I don't want to have conflicting identically numbered versions floating around out there. (If there's going to be a technical problem with that, please let me know and I'll respin it, but I'd rather not do so for merely cosmetic bikeshed reasons.) The plan is to make this the last ever release on 1.5, and the last ever release of 3.3.3 (punting it into status as a legacy compiler), and hopefully the final experimental release of gcc 4. It'll introduce alternatives usage so that the old 3 and new 4 can be side-by-side installed with either one the default when you don't specify, and I'd like to release them ASAP. I'll then have a bit of time to get the mingw cross working while people play with the DLLs and shake out any bugs, and assuming nothing massive crops up I'll rapidly spin an upgrade to the new 4.3.3 and take it out of experimental status, so it becomes the default 1.7 compiler. cheers, DaveK
Re: ITP: tack-1.06-1
Dave Korn wrote: create and verify the correctness of terminfo's. This program ^ Superfluous grocer's apostrophe :) Cut-n-paste, right from tack-1.06/README. Take it up with T.E.Dickey. g -- Chuck
Re: GCC4 status.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dave Korn wrote: - Adding i686-pc-mingw32 cross compiler build to gcc-4 cygport file (already under way, last build failed with libgomp needs pthreads error - need to get myself win32-pthreads for MinGW, I think). cygport's cross.cygclass needs some serious work, so if you're using it, please let me know what enhancements you need. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkmjcIQACgkQpiWmPGlmQSP3VgCgu8K2QpQJBhnoRb1s5Hi6igMQ PiUAn2kB1HBQBoBKimyLVlWnjHD21kjy =usXM -END PGP SIGNATURE-
Re: GCC4 status.
Yaakov (Cygwin/X) wrote: Dave Korn wrote: - Adding i686-pc-mingw32 cross compiler build to gcc-4 cygport file (already under way, last build failed with libgomp needs pthreads error - need to get myself win32-pthreads for MinGW, I think). cygport's cross.cygclass needs some serious work, so if you're using it, please let me know what enhancements you need. Was just planning on doing a hideous hack where I wrap large chunks of my .cygport file in the equivalent of #ifdefs! :) Don't think it's necessarily suitable for the class file anyway, it's going to be a fairly non-standard x-compiler in that it won't go into the usual $prefix/$target sysroot, it's going to look for headers and libs directly where they live under the native prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api, and it's going to use the native 'as' and 'ld'. So it's going to be an ugly hybrid beast cheers, DaveK
Re: GCC4 status.
Dave Korn wrote: it's going to be a fairly non-standard x-compiler in that it won't go into the usual $prefix/$target sysroot, it's going to look for headers and libs directly where they live under the native prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api, and it's going to use the native 'as' and 'ld'. So it's going to be an ugly hybrid beast Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just because we don't want two copies of w32api and mingw-runtime, or a cross-ld/cross-as? I think the maintenance headaches associated with an ugly hybrid beast outweigh those other, tiny, costs... -- Chuck
Re: GCC4 status.
On Tue, Feb 24, 2009 at 12:05:20AM -0500, Charles Wilson wrote: Dave Korn wrote: it's going to be a fairly non-standard x-compiler in that it won't go into the usual $prefix/$target sysroot, it's going to look for headers and libs directly where they live under the native prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api, and it's going to use the native 'as' and 'ld'. So it's going to be an ugly hybrid beast Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just because we don't want two copies of w32api and mingw-runtime, or a cross-ld/cross-as? I think the maintenance headaches associated with an ugly hybrid beast outweigh those other, tiny, costs... I agree. I think we should relocate mingw and w32api into standard locations. That was part of the reason for getting rid of -mno-cygwin. cgf
Re: GCC4 status.
Christopher Faylor wrote:
On Tue, Feb 24, 2009 at 12:05:20AM -0500, Charles Wilson wrote:
Dave Korn wrote:
it's going to be a fairly non-standard
x-compiler in that it won't go into the usual $prefix/$target sysroot, it's
going to look for headers and libs directly where they live under the native
prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api,
and it's going to use the native 'as' and 'ld'. So it's going to be an ugly
hybrid beast
Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just
because we don't want two copies of w32api and mingw-runtime, or a
cross-ld/cross-as?
I think the maintenance headaches associated with an ugly hybrid beast
outweigh those other, tiny, costs...
I agree. I think we should relocate
relocate? But the regular cygwin gcc needs at least w32api, and that
location is hardcoded in its specs file. Which means that relocate
implies - respin gcc-3.4.4-999, and respin gcc-4.2.3. And it doesn't
really make sense for the cygwin-gcc specs to specify always look in
/usr/i686-pc-mingw32/include/[w32api]. Whuh, huh? *-mingw32?
It makes more sense to me that we have two different w32api packages:
the regular one that installs into /usr/[include|lib]/w32api, and a
mingw-cross-w32api that installs into
/usr/${mingw-triple}/[include|lib]/[w32api].
mingw-runtime...sure, that could probably be relocated without
trouble. I don't think the regular cygwin gcc should care about that.
mingw and w32api into standard
locations. That was part of the reason for getting rid of -mno-cygwin.
--
Chuck
Re: GCC4 status.
On Tue, Feb 24, 2009 at 12:27:47AM -0500, Charles Wilson wrote:
Christopher Faylor wrote:
On Tue, Feb 24, 2009 at 12:05:20AM -0500, Charles Wilson wrote:
Dave Korn wrote:
it's going to be a fairly non-standard
x-compiler in that it won't go into the usual $prefix/$target sysroot, it's
going to look for headers and libs directly where they live under the
native
prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and
/lib/w32api,
and it's going to use the native 'as' and 'ld'. So it's going to be an
ugly
hybrid beast
Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just
because we don't want two copies of w32api and mingw-runtime, or a
cross-ld/cross-as?
I think the maintenance headaches associated with an ugly hybrid beast
outweigh those other, tiny, costs...
I agree. I think we should relocate
relocate? But the regular cygwin gcc needs at least w32api, and that
location is hardcoded in its specs file.
AFAIK, a normal Cygwin installation doesn't use the w32api header files
unless you're building a hybrid Cygwin/Windows program. That is a
pretty sad beast but I guess people really do use that. I guess we
can't think about removing -mno-win32. A limited number of libraries
are used so it wouldn't make sense to move them around.
I don't know how things have changed since I gave up the gcc reins
but it used to be that the installation created a /usr/i686-pc-mingw32/
hierarchy. I always thought that any future cross-compiler would just
actually populate that.
implies - respin gcc-3.4.4-999, and respin gcc-4.2.3. And it doesn't
really make sense for the cygwin-gcc specs to specify always look in
/usr/i686-pc-mingw32/include/[w32api]. Whuh, huh? *-mingw32?
It makes more sense to me that we have two different w32api packages:
the regular one that installs into /usr/[include|lib]/w32api, and a
mingw-cross-w32api that installs into
/usr/${mingw-triple}/[include|lib]/[w32api].
Two versions? Whuh, Huh? When is that ever a good idea?
What I would like to see is all of the Windows stuff isolated as much as
possible from the Cygwin. Possibly all of the windows-only stuff could
either install in a windows hierarchy or a mingw hierarchy and symlinks
into /usr/include and (sparingly) /usr/lib could be made.
mingw-runtime...sure, that could probably be relocated without
trouble. I don't think the regular cygwin gcc should care about that.
I believe that gegular cygwin gcc only cares about w32api for finding:
libuser32.a libkernel32.a libadvapi32.a libshell32.a . It adds the
w32api include when -mwindows is specified and, like I said, I guess we
can't delete that now. But we can make it clearer where these things
come from by installing them in a mingw-specific location and symlinking
them from there.
cgf
Re: GCC4 status.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christopher Faylor wrote: AFAIK, a normal Cygwin installation doesn't use the w32api header files unless you're building a hybrid Cygwin/Windows program. That is a pretty sad beast but I guess people really do use that. I guess we can't think about removing -mno-win32. A limited number of libraries are used so it wouldn't make sense to move them around. Some multimedia packages use mmsystem.h/libwinmm for low-level functions such as optical disc access. OTOH I would be thrilled if winsock.h and friends (which conflict with cygwin's sys/socket.h) would be out of the default search path. Two versions? Whuh, Huh? When is that ever a good idea? What I would like to see is all of the Windows stuff isolated as much as possible from the Cygwin. Possibly all of the windows-only stuff could either install in a windows hierarchy or a mingw hierarchy and symlinks into /usr/include and (sparingly) /usr/lib could be made. That may work, but we would have to decide very carefully what goes into /usr and what not. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkmjlksACgkQpiWmPGlmQSP9VQCdFc8eGBvrXRmRtpJf45Hl8Lcw BKoAni4NGsXg6S7NjP+XxVr6BUQg2AQt =t04W -END PGP SIGNATURE-
