Loading ...
Sorry, an error occurred while loading the content.

Compile 6.0ap under Cygwin

Expand Messages
  • Corinna Vinschen
    Hi, I have just build vim 6.0ap under Cygwin using the standard UNIX Makefile. I had to apply the following patch to src/mbyte.c to get it compiled due to a
    Message 1 of 22 , Aug 1, 2001
    • 0 Attachment
      Hi,

      I have just build vim 6.0ap under Cygwin using the standard UNIX
      Makefile. I had to apply the following patch to src/mbyte.c to
      get it compiled due to a collision of the `Status' type with
      an unused Windows header (winspool.h):

      --- mbyte.c.ORIG Wed Aug 1 12:19:52 2001
      +++ mbyte.c Wed Aug 1 12:21:22 2001
      @@ -77,6 +77,7 @@

      #include "vim.h"
      #if defined(WIN3264) || defined(WIN32UNIX)
      +# define WIN32_LEAN_AND_MEAN
      # include <windows.h>
      # ifndef __MINGW32__
      # include <winnls.h>


      I have another question. In the standard Makefile there's a define
      `SUFFIX' which is set to ".exe" but it's commented out. This
      requires manual intervention before compiling it on a Win32 UNIX
      layer like Cygwin. Why doesn't vim use the autoconf macro AC_EXEEXT?
      Is there a special reason for that or would a patch be welcome?

      Corinna

      --
      Corinna Vinschen
      Cygwin Developer
      Red Hat, Inc.
      mailto:vinschen@...
    • Martin Dalecki
      ... The define should be placed on the compiler command line. Using AC_EXEEXT doesn t hurt.
      Message 2 of 22 , Aug 1, 2001
      • 0 Attachment
        Corinna Vinschen wrote:
        >
        > Hi,
        >
        > I have just build vim 6.0ap under Cygwin using the standard UNIX
        > Makefile. I had to apply the following patch to src/mbyte.c to
        > get it compiled due to a collision of the `Status' type with
        > an unused Windows header (winspool.h):
        >
        > --- mbyte.c.ORIG Wed Aug 1 12:19:52 2001
        > +++ mbyte.c Wed Aug 1 12:21:22 2001
        > @@ -77,6 +77,7 @@
        >
        > #include "vim.h"
        > #if defined(WIN3264) || defined(WIN32UNIX)
        > +# define WIN32_LEAN_AND_MEAN
        > # include <windows.h>
        > # ifndef __MINGW32__
        > # include <winnls.h>
        >
        > I have another question. In the standard Makefile there's a define
        > `SUFFIX' which is set to ".exe" but it's commented out. This
        > requires manual intervention before compiling it on a Win32 UNIX
        > layer like Cygwin. Why doesn't vim use the autoconf macro AC_EXEEXT?
        > Is there a special reason for that or would a patch be welcome?

        The define should be placed on the compiler command line.
        Using AC_EXEEXT doesn't hurt.
      • Bram Moolenaar
        ... This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In several files where windows.h is included it is used, in others it is not. What is
        Message 3 of 22 , Aug 1, 2001
        • 0 Attachment
          Corinna Vinschen wrote:

          > I have just build vim 6.0ap under Cygwin using the standard UNIX
          > Makefile. I had to apply the following patch to src/mbyte.c to
          > get it compiled due to a collision of the `Status' type with
          > an unused Windows header (winspool.h):
          >
          > --- mbyte.c.ORIG Wed Aug 1 12:19:52 2001
          > +++ mbyte.c Wed Aug 1 12:21:22 2001
          > @@ -77,6 +77,7 @@
          >
          > #include "vim.h"
          > #if defined(WIN3264) || defined(WIN32UNIX)
          > +# define WIN32_LEAN_AND_MEAN
          > # include <windows.h>
          > # ifndef __MINGW32__
          > # include <winnls.h>

          This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In several
          files where windows.h is included it is used, in others it is not. What is
          the rule for using it?

          > I have another question. In the standard Makefile there's a define
          > `SUFFIX' which is set to ".exe" but it's commented out. This
          > requires manual intervention before compiling it on a Win32 UNIX
          > layer like Cygwin. Why doesn't vim use the autoconf macro AC_EXEEXT?
          > Is there a special reason for that or would a patch be welcome?

          For Cygwin the Make_cyg.mak file should work. Otherwise, I don't think there
          is a reason not to use AC_EXEEXT. It's just that nobody suggested this until
          now. If you can make a patch for it and test it, that's welcome.

          --
          From "know your smileys":
          @:-() Elvis Presley

          /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
          ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
          \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
        • Thore B. Karlsen
          ... Basically, when you re not using MFC you can include this to speed up the compilation. It never _has_ to be used, other than in cases like the above where
          Message 4 of 22 , Aug 1, 2001
          • 0 Attachment
            On Wed, 01 Aug 2001 14:25:18 +0200, you wrote:

            >> I have just build vim 6.0ap under Cygwin using the standard UNIX
            >> Makefile. I had to apply the following patch to src/mbyte.c to
            >> get it compiled due to a collision of the `Status' type with
            >> an unused Windows header (winspool.h):
            >>
            >> --- mbyte.c.ORIG Wed Aug 1 12:19:52 2001
            >> +++ mbyte.c Wed Aug 1 12:21:22 2001
            >> @@ -77,6 +77,7 @@
            >>
            >> #include "vim.h"
            >> #if defined(WIN3264) || defined(WIN32UNIX)
            >> +# define WIN32_LEAN_AND_MEAN
            >> # include <windows.h>
            >> # ifndef __MINGW32__
            >> # include <winnls.h>

            >This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In several
            >files where windows.h is included it is used, in others it is not. What is
            >the rule for using it?

            Basically, when you're not using MFC you can include this to speed up
            the compilation.

            It never _has_ to be used, other than in cases like the above where
            windows.h includes an unused header file and that messes things up.

            I don't know if there are cases when you don't want to use it in a
            non-MFC program.
          • Corinna Vinschen
            ... I m not that sure but I think WIN32_LEAN_AND_MEAN only includes header files which are needed for the basic win32 API. Everything else is dropped (COM,
            Message 5 of 22 , Aug 1, 2001
            • 0 Attachment
              On Wed, Aug 01, 2001 at 02:25:18PM +0200, Bram Moolenaar wrote:
              > Corinna Vinschen wrote:
              >
              > > I have just build vim 6.0ap under Cygwin using the standard UNIX
              > > Makefile. I had to apply the following patch to src/mbyte.c to
              > > get it compiled due to a collision of the `Status' type with
              > > an unused Windows header (winspool.h):
              > >
              > > --- mbyte.c.ORIG Wed Aug 1 12:19:52 2001
              > > +++ mbyte.c Wed Aug 1 12:21:22 2001
              > > @@ -77,6 +77,7 @@
              > >
              > > #include "vim.h"
              > > #if defined(WIN3264) || defined(WIN32UNIX)
              > > +# define WIN32_LEAN_AND_MEAN
              > > # include <windows.h>
              > > # ifndef __MINGW32__
              > > # include <winnls.h>
              >
              > This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In several
              > files where windows.h is included it is used, in others it is not. What is
              > the rule for using it?

              I'm not that sure but I think WIN32_LEAN_AND_MEAN only includes
              header files which are needed for the basic win32 API. Everything
              else is dropped (COM, MFC, etc.). Typically it's a good thing
              since it shortens compile time in 99% of the cases.

              > > I have another question. In the standard Makefile there's a define
              > > `SUFFIX' which is set to ".exe" but it's commented out. This
              > > requires manual intervention before compiling it on a Win32 UNIX
              > > layer like Cygwin. Why doesn't vim use the autoconf macro AC_EXEEXT?
              > > Is there a special reason for that or would a patch be welcome?
              >
              > For Cygwin the Make_cyg.mak file should work. Otherwise, I don't think there

              Uhm..., I don't want to annoy anybody but the Make_cyg.mak is sort
              of a mess from the Cygwin point of view:

              It uses native DOS commands instead of typical UNIX functionality
              ("del" instead of "rm", etc.) which is part of Cygwin for years.

              It links explicitely windows DLLs which are linked automatically
              by Cygwin's gcc (kernel32.dll, user32.dll, etc.)

              It defines symbols which are already defined (__CYGWIN__) and it
              defines symbols which shouldn't be defined (WIN32).

              The Make_cyg.mak file looks as if somebody wants to only use
              Cygwin's gcc to create a native Windows application instead
              of a Cygwin application.

              Cygwin is a UNIX porting layer which allows typically to build
              applications from the UNIX build process in a UNIX-like build
              environment. There's no need to create a separate Makefile for
              Cygwin. A Cygwin vim uses only POSIX system calls except
              when compiled as GVIM for the Win32 GUI.

              Since I'm the maintainer for Vim in the Cygwin net distribution
              I would like to keep the UNIX way of building things.

              Currently vim-6.0ap build OOTB from the UNIX Makefile except for
              the above `WIN32_LEAN_AND_MEAN' problem and the `SUFFIX' part in
              the Makefile.

              > is a reason not to use AC_EXEEXT. It's just that nobody suggested this until
              > now. If you can make a patch for it and test it, that's welcome.

              I'm a bit spare on time but I will try to do this in a week or
              two.

              Corinna

              --
              Corinna Vinschen
              Cygwin Developer
              Red Hat, Inc.
              mailto:vinschen@...
            • Dan Sharp
              ... Exactly. Some people may have Cygwin gcc installed as their only compiler and want to compile a native Windows gvim. Instead of having to download a
              Message 6 of 22 , Aug 1, 2001
              • 0 Attachment
                >The Make_cyg.mak file looks as if somebody wants to only use
                >Cygwin's gcc to create a native Windows application instead
                >of a Cygwin application.

                Exactly. Some people may have Cygwin gcc installed as their only compiler
                and want to compile a native Windows gvim. Instead of having to download a
                whole new compiler (like MingW or Borland 5.5) or always have an X-server
                running to use the Athena or GTK version, they can just use
                Make_cyg.mak. Granted, Make_cyg.mak may not be the cleanest
                implementation, but it works well enough.

                >Since I'm the maintainer for Vim in the Cygwin net distribution
                >I would like to keep the UNIX way of building things.

                I knew I recognized your name from somewhere! :) The Cygwin SSHD server is
                the only remote-access service I run on my Win2k machine anymore. Adding
                cygrunserv was very helpful, too! Thanks for all the work!

                >Currently vim-6.0ap build OOTB from the UNIX Makefile except for
                >the above `WIN32_LEAN_AND_MEAN' problem and the `SUFFIX' part in
                >the Makefile.

                Are you going to be including gvim in the vim 6.0 Cygwin distribution?

                Dan Sharp
              • Dan Sharp
                ... I tried a quick test and stuck #define WIN32_LEAN_AND_MEAN in front of every call to #include and it breaks compilation of if_ole.cpp and
                Message 7 of 22 , Aug 1, 2001
                • 0 Attachment
                  At 02:25 PM 8/1/2001 +0200, Bram Moolenaar wrote:

                  >This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In several
                  >files where windows.h is included it is used, in others it is not. What is
                  >the rule for using it?

                  I tried a quick test and stuck #define WIN32_LEAN_AND_MEAN in front of
                  every call to #include <windows.h> and it breaks compilation of if_ole.cpp
                  and gui_w48.c. Removing it from if_ole.cpp fixed that problem, and
                  removing it from gui.h fixed the gui_w48.c problem (removing it from
                  gui_w48.c didn't help. I guess since it was already done in gui.h, the
                  #include <windows.h> in gui_w48.c is a little redundant, at least for
                  win32). It looks like the idea behind it is to speed up compilation time
                  by not reading in the lesser used header files. I didn't see any change in
                  code size, and didn't really pay attention to compile time differences.

                  Dan Sharp
                • Bram Moolenaar
                  ... I suppose this means we can define it globally then. Vim doesn t use COM or MFC. ... Make_cyg.mak is using the Cygwin compiler to produce a Windows
                  Message 8 of 22 , Aug 1, 2001
                  • 0 Attachment
                    Corinna Vinschen wrote:

                    > > This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In
                    > > several files where windows.h is included it is used, in others it is not.
                    > > What is the rule for using it?
                    >
                    > I'm not that sure but I think WIN32_LEAN_AND_MEAN only includes
                    > header files which are needed for the basic win32 API. Everything
                    > else is dropped (COM, MFC, etc.). Typically it's a good thing
                    > since it shortens compile time in 99% of the cases.

                    I suppose this means we can define it globally then. Vim doesn't use COM or
                    MFC.

                    > Uhm..., I don't want to annoy anybody but the Make_cyg.mak is sort
                    > of a mess from the Cygwin point of view:
                    >
                    > It uses native DOS commands instead of typical UNIX functionality
                    > ("del" instead of "rm", etc.) which is part of Cygwin for years.
                    >
                    > It links explicitely windows DLLs which are linked automatically
                    > by Cygwin's gcc (kernel32.dll, user32.dll, etc.)
                    >
                    > It defines symbols which are already defined (__CYGWIN__) and it
                    > defines symbols which shouldn't be defined (WIN32).
                    >
                    > The Make_cyg.mak file looks as if somebody wants to only use
                    > Cygwin's gcc to create a native Windows application instead
                    > of a Cygwin application.

                    Make_cyg.mak is using the Cygwin compiler to produce a Windows application.
                    When using Makefile you get a Cygwin application. That last method is needed
                    for Unix applications that have not been ported to Windows. But since Vim has
                    been ported, isn't it better to make it work like a Windows application?

                    I suppose you know how to cleanup Make_cyg.mak. Unfortunately it doesn't
                    mention who has been working on this (must be several people). Any comments
                    from them?

                    > Cygwin is a UNIX porting layer which allows typically to build
                    > applications from the UNIX build process in a UNIX-like build
                    > environment. There's no need to create a separate Makefile for
                    > Cygwin. A Cygwin vim uses only POSIX system calls except
                    > when compiled as GVIM for the Win32 GUI.
                    >
                    > Since I'm the maintainer for Vim in the Cygwin net distribution
                    > I would like to keep the UNIX way of building things.

                    The question is why you would want to do this. It probably makes the
                    executable larger, perhaps problems with file names, etc. What would be the
                    advantage?

                    > Currently vim-6.0ap build OOTB from the UNIX Makefile except for
                    > the above `WIN32_LEAN_AND_MEAN' problem and the `SUFFIX' part in
                    > the Makefile.

                    That's a good sign, both for Vim being portable and for Cygwin being able to
                    compile this rather complex program.

                    > > is a reason not to use AC_EXEEXT. It's just that nobody suggested this
                    > > until now. If you can make a patch for it and test it, that's welcome.
                    >
                    > I'm a bit spare on time but I will try to do this in a week or two.

                    I notice it's just a matter of including AC_EXEEXT in configure.in and
                    defining EXEEXT in config.mk.in in the usual way. Oh, and rename SUFFIX to
                    EXEEXT in Makefile, that's clearer anyway. I'll add it and we can test it
                    with the next version. Looks harmless if it's empty anyway.

                    --
                    From "know your smileys":
                    C=}>;*{)) Drunk, devilish chef with a toupee in an updraft,
                    a mustache, and a double chin

                    /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                    ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                    \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                  • Corinna Vinschen
                    ... No. A native Windows port is a different thing. Cygwin provides stuff in it s environment which isn t available under Windows, for example mount points,
                    Message 9 of 22 , Aug 1, 2001
                    • 0 Attachment
                      On Wed, Aug 01, 2001 at 06:04:48PM +0200, Bram Moolenaar wrote:
                      > Make_cyg.mak is using the Cygwin compiler to produce a Windows application.
                      > When using Makefile you get a Cygwin application. That last method is needed
                      > for Unix applications that have not been ported to Windows. But since Vim has
                      > been ported, isn't it better to make it work like a Windows application?

                      No. A native Windows port is a different thing. Cygwin provides
                      stuff in it's environment which isn't available under Windows,
                      for example mount points, symbolic links and so on. If you
                      compile a vim for native Windows it doesn't have access to this
                      POSIX environment. You can Cygwin handle as another UNIX target
                      like Sun, OpenBSD, Linux, etc.

                      > I suppose you know how to cleanup Make_cyg.mak. Unfortunately it doesn't
                      > mention who has been working on this (must be several people). Any comments
                      > from them?

                      Since `Make_cyg.mak' is just for creating a native Windows application
                      I will not touch that file because it's not falling into my expertise.
                      A native Cygwin application should be created by using the UNIX
                      Makefiles.

                      > > Cygwin is a UNIX porting layer which allows typically to build
                      > > applications from the UNIX build process in a UNIX-like build
                      > > environment. There's no need to create a separate Makefile for
                      > > Cygwin. A Cygwin vim uses only POSIX system calls except
                      > > when compiled as GVIM for the Win32 GUI.
                      > >
                      > > Since I'm the maintainer for Vim in the Cygwin net distribution
                      > > I would like to keep the UNIX way of building things.
                      >
                      > The question is why you would want to do this. It probably makes the
                      > executable larger, perhaps problems with file names, etc. What would be the
                      > advantage?

                      As I described above. Cygwin is a whole POSIX layer like U/WIN,
                      Interix, MKS, it's just open source. The net distribution contains
                      a whole lot of UNIX tools for development (gcc, gdb, ...), shells
                      (ash, bash, tcsh), OpenSSH, inetd, a database (postgreSQL), TeX,
                      mutt and much much more. Vim-5.8 is already part of that environment
                      as well.

                      Ask former UNIX guys which are stuck on Windows due to their
                      employers policy about working only in a native Windows environment...

                      > > Currently vim-6.0ap build OOTB from the UNIX Makefile except for
                      > > the above `WIN32_LEAN_AND_MEAN' problem and the `SUFFIX' part in
                      > > the Makefile.
                      >
                      > That's a good sign, both for Vim being portable and for Cygwin being able to
                      > compile this rather complex program.

                      I just found an issue with "\" vs. "/". At one point Vim-6.0 seems
                      to call a Windows function for file access instead of the standard
                      UNIX functions so that a path

                      $ vim machine/setjmp.h

                      doesn't open the file but

                      $ vim machine\\setjmp.h

                      does. I have to debug that.

                      > > > is a reason not to use AC_EXEEXT. It's just that nobody suggested this
                      > > > until now. If you can make a patch for it and test it, that's welcome.
                      > >
                      > > I'm a bit spare on time but I will try to do this in a week or two.
                      >
                      > I notice it's just a matter of including AC_EXEEXT in configure.in and
                      > defining EXEEXT in config.mk.in in the usual way. Oh, and rename SUFFIX to
                      > EXEEXT in Makefile, that's clearer anyway. I'll add it and we can test it
                      > with the next version. Looks harmless if it's empty anyway.

                      It's not all, unfortunately. The symlinks (view, ex, ...) are
                      currently created with $SUFFIX but they should be created w/o
                      the suffix. Only the real executables should have the ".exe".
                      It doesn't disturb Cygwin but it's not usual (lame excuse).

                      Thanks,
                      Corinna

                      --
                      Corinna Vinschen
                      Cygwin Developer
                      Red Hat, Inc.
                      mailto:vinschen@...
                    • Bram Moolenaar
                      ... OK, I get the idea. There are two ways to compile Vim with Cygwin and the results are both useful, but in a different way. I ll add a remark in the
                      Message 10 of 22 , Aug 1, 2001
                      • 0 Attachment
                        Corinna Vinschen wrote:

                        > No. A native Windows port is a different thing. Cygwin provides
                        > stuff in it's environment which isn't available under Windows,
                        > for example mount points, symbolic links and so on. If you
                        > compile a vim for native Windows it doesn't have access to this
                        > POSIX environment. You can Cygwin handle as another UNIX target
                        > like Sun, OpenBSD, Linux, etc.

                        OK, I get the idea. There are two ways to compile Vim with Cygwin and the
                        results are both useful, but in a different way. I'll add a remark in the
                        Make_cyg.mak file about this.

                        > I just found an issue with "\" vs. "/". At one point Vim-6.0 seems
                        > to call a Windows function for file access instead of the standard
                        > UNIX functions so that a path
                        >
                        > $ vim machine/setjmp.h
                        >
                        > doesn't open the file but
                        >
                        > $ vim machine\\setjmp.h
                        >
                        > does. I have to debug that.

                        Strange, since Windows functions also allow using a forward slash. That
                        shouldn't be a problem, unless calling an external program, where the slash is
                        used for options. I would expect problems with backslashes, since the Unix
                        version handles them differently.

                        > > > > is a reason not to use AC_EXEEXT. It's just that nobody suggested
                        > > > > this until now. If you can make a patch for it and test it, that's
                        > > > > welcome.
                        > > >
                        > > > I'm a bit spare on time but I will try to do this in a week or two.
                        > >
                        > > I notice it's just a matter of including AC_EXEEXT in configure.in and
                        > > defining EXEEXT in config.mk.in in the usual way. Oh, and rename SUFFIX
                        > > to EXEEXT in Makefile, that's clearer anyway. I'll add it and we can test
                        > > it with the next version. Looks harmless if it's empty anyway.
                        >
                        > It's not all, unfortunately. The symlinks (view, ex, ...) are
                        > currently created with $SUFFIX but they should be created w/o
                        > the suffix. Only the real executables should have the ".exe".
                        > It doesn't disturb Cygwin but it's not usual (lame excuse).

                        I wonder how you make symlinks at all, since Windows doesn't have them. I
                        have cygwin 1.0, but I can't find a reference to symlinks.

                        I'll use $(LNKEXT) for the targets used with symbolic links. Keeping it empty
                        by default should work then. Example:

                        VIMTARGET = $(VIMNAME)$(EXEEXT)
                        EVIEWTARGET = $(EVIEWNAME)$(LNKEXT)

                        ln -s $(VIMTARGET) $(EVIEWTARGET)

                        --
                        hundred-and-one symptoms of being an internet addict:
                        100. The most exciting sporting events you noticed during summer 1996
                        was Netscape vs. Microsoft.

                        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                        ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                        \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                      • Corinna Vinschen
                        ... I began to debug that and it s not related to backslash issues. It has something to do with fchdir() but I haven t got what the whole function
                        Message 11 of 22 , Aug 1, 2001
                        • 0 Attachment
                          On Wed, Aug 01, 2001 at 08:48:20PM +0200, Bram Moolenaar wrote:
                          >
                          > Corinna Vinschen wrote:
                          >
                          > > No. A native Windows port is a different thing. Cygwin provides
                          > > stuff in it's environment which isn't available under Windows,
                          > > for example mount points, symbolic links and so on. If you
                          > > compile a vim for native Windows it doesn't have access to this
                          > > POSIX environment. You can Cygwin handle as another UNIX target
                          > > like Sun, OpenBSD, Linux, etc.
                          >
                          > OK, I get the idea. There are two ways to compile Vim with Cygwin and the
                          > results are both useful, but in a different way. I'll add a remark in the
                          > Make_cyg.mak file about this.
                          >
                          > > I just found an issue with "\" vs. "/". At one point Vim-6.0 seems
                          > > to call a Windows function for file access instead of the standard
                          > > UNIX functions so that a path
                          > >
                          > > $ vim machine/setjmp.h
                          > >
                          > > doesn't open the file but
                          > >
                          > > $ vim machine\\setjmp.h
                          > >
                          > > does. I have to debug that.
                          >
                          > Strange, since Windows functions also allow using a forward slash. That
                          > shouldn't be a problem, unless calling an external program, where the slash is
                          > used for options. I would expect problems with backslashes, since the Unix
                          > version handles them differently.

                          I began to debug that and it's not related to backslash issues.
                          It has something to do with fchdir() but I haven't got what the
                          whole function `os_unix.c::mch_FullName()' is doing. It has called
                          a fchdir() which returned 0 (and actually has changed the cwd) but
                          a few lines later it calls mch_chdir() which again tries to chdir
                          to the same directory which obviously failes now... As I said, I'm
                          not in a state where I actually understand the code here...

                          > > > > > is a reason not to use AC_EXEEXT. It's just that nobody suggested
                          > > > > > this until now. If you can make a patch for it and test it, that's
                          > > > > > welcome.
                          > > > >
                          > > > > I'm a bit spare on time but I will try to do this in a week or two.
                          > > >
                          > > > I notice it's just a matter of including AC_EXEEXT in configure.in and
                          > > > defining EXEEXT in config.mk.in in the usual way. Oh, and rename SUFFIX
                          > > > to EXEEXT in Makefile, that's clearer anyway. I'll add it and we can test
                          > > > it with the next version. Looks harmless if it's empty anyway.
                          > >
                          > > It's not all, unfortunately. The symlinks (view, ex, ...) are
                          > > currently created with $SUFFIX but they should be created w/o
                          > > the suffix. Only the real executables should have the ".exe".
                          > > It doesn't disturb Cygwin but it's not usual (lame excuse).
                          >
                          > I wonder how you make symlinks at all, since Windows doesn't have them. I
                          > have cygwin 1.0, but I can't find a reference to symlinks.

                          The current Cygwin 1.3.2 version can create symlinks in two
                          different ways. The old method (already supported by 1.0)
                          creates regular files with a special content (a magic cookie
                          and the actual target path) and which has the `system' bit
                          set in the file attributes. This type of symlinks is only
                          recognized by native Cygwin apps.

                          The second way is by creating Windows shortcuts (*.lnk files)
                          with a special content and the R/O bit set. Native Cygwin apps
                          will not see the .lnk extension and native Windows apps are
                          able to use the links as normal Windows shortcuts.

                          > I'll use $(LNKEXT) for the targets used with symbolic links. Keeping it empty
                          > by default should work then. Example:
                          >
                          > VIMTARGET = $(VIMNAME)$(EXEEXT)
                          > EVIEWTARGET = $(EVIEWNAME)$(LNKEXT)
                          >
                          > ln -s $(VIMTARGET) $(EVIEWTARGET)

                          Yes. That's what I meant. Thank you!

                          Corinna

                          --
                          Corinna Vinschen
                          Cygwin Developer
                          Red Hat, Inc.
                          mailto:vinschen@...
                        • Corinna Vinschen
                          ... Yep, it s a good reason to stuck with Make_cyg.mak. It s just that this isn t what I m maintaining so I keep my hands from that file. ... Thanks :-) ...
                          Message 12 of 22 , Aug 1, 2001
                          • 0 Attachment
                            On Wed, Aug 01, 2001 at 11:09:25AM -0400, Dan Sharp wrote:
                            >
                            > >The Make_cyg.mak file looks as if somebody wants to only use
                            > >Cygwin's gcc to create a native Windows application instead
                            > >of a Cygwin application.
                            >
                            > Exactly. Some people may have Cygwin gcc installed as their only compiler
                            > and want to compile a native Windows gvim. Instead of having to download a
                            > whole new compiler (like MingW or Borland 5.5) or always have an X-server
                            > running to use the Athena or GTK version, they can just use
                            > Make_cyg.mak. Granted, Make_cyg.mak may not be the cleanest
                            > implementation, but it works well enough.

                            Yep, it's a good reason to stuck with Make_cyg.mak. It's just that
                            this isn't what I'm maintaining so I keep my hands from that file.

                            > >Since I'm the maintainer for Vim in the Cygwin net distribution
                            > >I would like to keep the UNIX way of building things.
                            >
                            > I knew I recognized your name from somewhere! :) The Cygwin SSHD server is
                            > the only remote-access service I run on my Win2k machine anymore. Adding
                            > cygrunserv was very helpful, too! Thanks for all the work!

                            Thanks :-)

                            > >Currently vim-6.0ap build OOTB from the UNIX Makefile except for
                            > >the above `WIN32_LEAN_AND_MEAN' problem and the `SUFFIX' part in
                            > >the Makefile.
                            >
                            > Are you going to be including gvim in the vim 6.0 Cygwin distribution?

                            Probably not. At least not if my time slices for such stuff keep
                            as thin as currently. I will concentrate on a clean non-GUI
                            version for the Cygwin net distribution first. Sure I would
                            like to have a Cygwin gvim as well but which version should I
                            build, a native Windows GUI or a version for Cygwin-XFree86?

                            I think if Cygwin-XFree86 will become part of the net distro
                            once, that's the way to go but that's only _my_ opinion. I
                            can already see heated debates...

                            Corinna

                            --
                            Corinna Vinschen
                            Cygwin Developer
                            Red Hat, Inc.
                            mailto:vinschen@...
                          • Corinna Vinschen
                            ... Ok, got it. It s a buggy implementation of fchdir() in Cygwin which doesn t correctly handle changing to relative paths under all circumstances. Since I
                            Message 13 of 22 , Aug 1, 2001
                            • 0 Attachment
                              On Wed, Aug 01, 2001 at 09:16:21PM +0200, Corinna Vinschen wrote:
                              > I began to debug that and it's not related to backslash issues.
                              > It has something to do with fchdir() but I haven't got what the
                              > whole function `os_unix.c::mch_FullName()' is doing. It has called
                              > a fchdir() which returned 0 (and actually has changed the cwd) but
                              > a few lines later it calls mch_chdir() which again tries to chdir
                              > to the same directory which obviously failes now... As I said, I'm
                              > not in a state where I actually understand the code here...

                              Ok, got it. It's a buggy implementation of fchdir() in Cygwin
                              which doesn't correctly handle changing to relative paths under
                              all circumstances. Since I have implemented fchdir() in Cygwin
                              I have to blame myself.

                              Probably it would be the best way to stuck with chdir() (not
                              defining HAVE_FCHDIR for Cygwin even if the function is
                              available) for two reasons.

                              - fchdir() is currently implemented only in the Cygwin developer
                              snapshots. Even the current official Cygwin release (1.3.2)
                              doesn't have it.
                              - It's incorrect as aforementioned. I have to rethink the implementation
                              somehow...

                              Corinna

                              --
                              Corinna Vinschen
                              Cygwin Developer
                              Red Hat, Inc.
                              mailto:vinschen@...
                            • Bram Moolenaar
                              Dan - ... Thanks for verifying that. I can imagine the OLE version needs some extra header files. gui_w48 must also use something that requires an extra
                              Message 14 of 22 , Aug 1, 2001
                              • 0 Attachment
                                Dan -

                                > >This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In
                                > >several files where windows.h is included it is used, in others it is not.
                                > >What is the rule for using it?
                                >
                                > I tried a quick test and stuck #define WIN32_LEAN_AND_MEAN in front of
                                > every call to #include <windows.h> and it breaks compilation of if_ole.cpp
                                > and gui_w48.c. Removing it from if_ole.cpp fixed that problem, and
                                > removing it from gui.h fixed the gui_w48.c problem (removing it from
                                > gui_w48.c didn't help. I guess since it was already done in gui.h, the
                                > #include <windows.h> in gui_w48.c is a little redundant, at least for
                                > win32). It looks like the idea behind it is to speed up compilation time
                                > by not reading in the lesser used header files. I didn't see any change in
                                > code size, and didn't really pay attention to compile time differences.

                                Thanks for verifying that. I can imagine the OLE version needs some extra
                                header files. gui_w48 must also use something that requires an extra header
                                file (resolving the .lnk file perhaps?).

                                I'll include the define in the places where it's possible, not in a global
                                place. Will do some more testing later (it might depend on the features
                                included).

                                - Bram

                                --
                                hundred-and-one symptoms of being an internet addict:
                                103. When you find yourself in the "Computer" section of Barnes & Noble
                                enjoying yourself.

                                /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                                \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                              • Bram Moolenaar
                                ... mch_FullName() expands a path name to an absolute path. Thus it becomes independent of changing directory. The fchdir() doesn t change directory the first
                                Message 15 of 22 , Aug 1, 2001
                                • 0 Attachment
                                  Corinna Vinschen wrote:

                                  > I began to debug that and it's not related to backslash issues.
                                  > It has something to do with fchdir() but I haven't got what the
                                  > whole function `os_unix.c::mch_FullName()' is doing. It has called
                                  > a fchdir() which returned 0 (and actually has changed the cwd) but
                                  > a few lines later it calls mch_chdir() which again tries to chdir
                                  > to the same directory which obviously failes now... As I said, I'm
                                  > not in a state where I actually understand the code here...

                                  mch_FullName() expands a path name to an absolute path. Thus it becomes
                                  independent of changing directory.

                                  The fchdir() doesn't change directory the first time, it's used to remember
                                  the current directory ".". The mch_chdir() then changes directory and another
                                  fchdir() takes us back to the old current directory. This works fine on Unix,
                                  perhaps the special handling of directories under Cygwin has some problems
                                  with this construction.

                                  > > I wonder how you make symlinks at all, since Windows doesn't have them. I
                                  > > have cygwin 1.0, but I can't find a reference to symlinks.
                                  >
                                  > The current Cygwin 1.3.2 version can create symlinks in two
                                  > different ways. The old method (already supported by 1.0)
                                  > creates regular files with a special content (a magic cookie
                                  > and the actual target path) and which has the `system' bit
                                  > set in the file attributes. This type of symlinks is only
                                  > recognized by native Cygwin apps.

                                  Ah, a trick. That doesn't explain why the ".exe" can't be added though.

                                  > The second way is by creating Windows shortcuts (*.lnk files)
                                  > with a special content and the R/O bit set. Native Cygwin apps
                                  > will not see the .lnk extension and native Windows apps are
                                  > able to use the links as normal Windows shortcuts.

                                  Even more complicated trick (the .lnk file format is undocumented, at least we
                                  couldn't find it). I suppose that .lnk extention is the reason we can't use
                                  .exe.

                                  --
                                  hundred-and-one symptoms of being an internet addict:
                                  104. When people ask about the Presidential Election you ask "Which country?"

                                  /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                  ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                                  \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                • Denis (work)
                                  ..snip.. ... ..snip.. ... ah, i would pay to have some ms windows programmers around here, and hear them say something similar about some things in that other
                                  Message 16 of 22 , Aug 1, 2001
                                  • 0 Attachment
                                    ..snip..

                                    | Since I have implemented fchdir() in Cygwin
                                    | I have to blame myself.


                                    ..snip..

                                    | - It's incorrect as aforementioned. I have to rethink the implementation
                                    | somehow...


                                    ah, i would pay to have some ms windows programmers around
                                    here, and hear them say something similar about some things
                                    in that other OS :)

                                    denis

                                    ps. dont get me wrong, i like windows and all...

                                    --

                                    /*
                                    * Denis Perelyubskiy
                                    * icq : 12359698
                                    * mailto: denisp@...
                                    * PGP : http://www.cs.ucla.edu/~denisp/files/pgp.asc
                                    */
                                  • Corinna Vinschen
                                    ... You can read and write them using COM functions. ... Sorry if that was unclear in my first mail. The .exe extensions are no problem anymore for the current
                                    Message 17 of 22 , Aug 1, 2001
                                    • 0 Attachment
                                      On Wed, Aug 01, 2001 at 10:43:13PM +0200, Bram Moolenaar wrote:
                                      > > The second way is by creating Windows shortcuts (*.lnk files)
                                      > > with a special content and the R/O bit set. Native Cygwin apps
                                      > > will not see the .lnk extension and native Windows apps are
                                      > > able to use the links as normal Windows shortcuts.
                                      >
                                      > Even more complicated trick (the .lnk file format is undocumented, at least we
                                      > couldn't find it).

                                      You can read and write them using COM functions.

                                      > I suppose that .lnk extention is the reason we can't use
                                      > .exe.

                                      Sorry if that was unclear in my first mail. The .exe extensions
                                      are no problem anymore for the current implementation of the symlink
                                      code but IIRC they were a problem a few months ago and they are
                                      somehow *gulp* unaesthetic. The symlinks to executables don't
                                      have a .exe suffix in the whole net distro, so...

                                      Corinna

                                      --
                                      Corinna Vinschen
                                      Cygwin Developer
                                      Red Hat, Inc.
                                      mailto:vinschen@...
                                    • Corinna Vinschen
                                      ... Hey, I like Windows NT/W2K as it is! I wouldn t have that fun working on Cygwin if Windows would be perfect ;-) OTOH, don t talk about 9x/ME... Corinna --
                                      Message 18 of 22 , Aug 1, 2001
                                      • 0 Attachment
                                        On Wed, Aug 01, 2001 at 01:54:53PM -0700, Denis (work) wrote:
                                        >
                                        > ..snip..
                                        >
                                        > | Since I have implemented fchdir() in Cygwin
                                        > | I have to blame myself.
                                        >
                                        >
                                        > ..snip..
                                        >
                                        > | - It's incorrect as aforementioned. I have to rethink the implementation
                                        > | somehow...
                                        >
                                        >
                                        > ah, i would pay to have some ms windows programmers around
                                        > here, and hear them say something similar about some things
                                        > in that other OS :)
                                        >
                                        > denis
                                        >
                                        > ps. dont get me wrong, i like windows and all...

                                        Hey, I like Windows NT/W2K as it is! I wouldn't have that fun
                                        working on Cygwin if Windows would be perfect ;-)

                                        OTOH, don't talk about 9x/ME...

                                        Corinna

                                        --
                                        Corinna Vinschen
                                        Cygwin Developer
                                        Red Hat, Inc.
                                        mailto:vinschen@...
                                      • Thore B. Karlsen
                                        ... But they do, maybe not so often in public, but they do. When I was up at Microsoft the developers weren t brainwashed to the extent one would think. The
                                        Message 19 of 22 , Aug 1, 2001
                                        • 0 Attachment
                                          On Wed, 1 Aug 2001 13:54:53 -0700, you wrote:

                                          >| - It's incorrect as aforementioned. I have to rethink the implementation
                                          >| somehow...

                                          >ah, i would pay to have some ms windows programmers around
                                          >here, and hear them say something similar about some things
                                          >in that other OS :)

                                          But they do, maybe not so often in public, but they do. When I was up at
                                          Microsoft the developers weren't brainwashed to the extent one would
                                          think. The users, on the other hand. :)
                                        • Corinna Vinschen
                                          ... I have further investigated that problem and I have fixed fchdir() in the Cygwin CVS repository. However, since the current official and previous releases
                                          Message 20 of 22 , Aug 3, 2001
                                          • 0 Attachment
                                            On Wed, Aug 01, 2001 at 10:31:38PM +0200, Corinna Vinschen wrote:
                                            > Ok, got it. It's a buggy implementation of fchdir() in Cygwin
                                            > which doesn't correctly handle changing to relative paths under
                                            > all circumstances. Since I have implemented fchdir() in Cygwin
                                            > I have to blame myself.
                                            >
                                            > Probably it would be the best way to stuck with chdir() (not
                                            > defining HAVE_FCHDIR for Cygwin even if the function is
                                            > available) for two reasons.
                                            >
                                            > - fchdir() is currently implemented only in the Cygwin developer
                                            > snapshots. Even the current official Cygwin release (1.3.2)
                                            > doesn't have it.
                                            > - It's incorrect as aforementioned. I have to rethink the implementation
                                            > somehow...

                                            I have further investigated that problem and I have fixed fchdir()
                                            in the Cygwin CVS repository. However, since the current official
                                            and previous releases don't have fchdir() at all, I think it's better
                                            to not use fchdir() for Cygwin to keep backward compatibility.

                                            For that reason I would like to propose the following patch to
                                            `configure.in' which results in skipping the fchdir check when
                                            configuring for Cygwin:

                                            --- configure.in.ORIG Fri Aug 3 13:16:07 2001
                                            +++ configure.in Fri Aug 3 13:15:57 2001
                                            @@ -59,6 +59,13 @@ case `uname` in
                                            QNX=no; AC_MSG_RESULT(no);;
                                            esac

                                            +dnl If Cygwin is found, assume we don't want to use fchdir to be
                                            +dnl backward compatible to versions before 1.3.3
                                            +AC_MSG_CHECKING(for Cygwin)
                                            +case `uname` in
                                            + CYGWIN*) ac_cv_func_fchdir=no;;
                                            +esac
                                            +
                                            AC_SUBST(OS_EXTRA_SRC)
                                            AC_SUBST(OS_EXTRA_OBJ)


                                            Corinna

                                            --
                                            Corinna Vinschen
                                            Cygwin Developer
                                            Red Hat, Inc.
                                            mailto:vinschen@...
                                          • Bram Moolenaar
                                            ... OK. But it s a bit strange to do this in configure. I rather do this in vim.h. How about this instead: ... *************** ... # if (SIZEOF_INT == 0)
                                            Message 21 of 22 , Aug 3, 2001
                                            • 0 Attachment
                                              Corinna Vinschen wrote:

                                              > I have further investigated that problem and I have fixed fchdir()
                                              > in the Cygwin CVS repository. However, since the current official
                                              > and previous releases don't have fchdir() at all, I think it's better
                                              > to not use fchdir() for Cygwin to keep backward compatibility.
                                              >
                                              > For that reason I would like to propose the following patch to
                                              > `configure.in' which results in skipping the fchdir check when
                                              > configuring for Cygwin:

                                              OK. But it's a bit strange to do this in configure. I rather do this in
                                              vim.h. How about this instead:

                                              *** vim.h~ Fri Aug 3 15:55:26 2001
                                              --- vim.h Fri Aug 3 17:41:05 2001
                                              ***************
                                              *** 37,42 ****
                                              --- 37,49 ----
                                              # if (SIZEOF_INT == 0)
                                              Error: configure did not run properly. Check auto/config.log.
                                              # endif
                                              +
                                              + /*
                                              + * Cygwin may have fchdir(), but in most versions it doesn't work well.
                                              + */
                                              + # if defined(__CYGWIN32__) && defined(HAVE_FCHDIR)
                                              + # undef HAVE_FCHDIR
                                              + # endif
                                              #endif

                                              #ifdef __EMX__ /* hand-edited config.h for OS/2 with EMX */

                                              --
                                              hundred-and-one symptoms of being an internet addict:
                                              145. You e-mail your boss, informing him you'll be late.

                                              /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                              ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                                              \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                            • Corinna Vinschen
                                              ... I m usually trying to solve such problems in the configuring to minimize target dependent code. If you like the below solution more, that s ok with me. I
                                              Message 22 of 22 , Aug 3, 2001
                                              • 0 Attachment
                                                On Fri, Aug 03, 2001 at 05:49:24PM +0200, Bram Moolenaar wrote:
                                                > OK. But it's a bit strange to do this in configure. I rather do this in
                                                > vim.h. How about this instead:

                                                I'm usually trying to solve such problems in the configuring to
                                                minimize target dependent code. If you like the below solution
                                                more, that's ok with me. I would like to see another comment,
                                                though. As I said, fchdir() is only implemented in the developers
                                                version and not in an official release. So not using fchdir()
                                                is mainly to keep backward compatibility even if the next Cygwin
                                                release is out. And, btw., due to restrictions of the Win32 API
                                                the fchdir() function is actually slower than chdir()...

                                                Corinna

                                                >
                                                > *** vim.h~ Fri Aug 3 15:55:26 2001
                                                > --- vim.h Fri Aug 3 17:41:05 2001
                                                > ***************
                                                > *** 37,42 ****
                                                > --- 37,49 ----
                                                > # if (SIZEOF_INT == 0)
                                                > Error: configure did not run properly. Check auto/config.log.
                                                > # endif
                                                > +
                                                > + /*
                                                > + * Cygwin may have fchdir(), but in most versions it doesn't work well.

                                                + * Only newer Cygwin releases have fchdir(). We don't use it to
                                                + * keep the binary backward compatible.

                                                > + */
                                                > + # if defined(__CYGWIN32__) && defined(HAVE_FCHDIR)
                                                > + # undef HAVE_FCHDIR
                                                > + # endif
                                                > #endif
                                                >
                                                > #ifdef __EMX__ /* hand-edited config.h for OS/2 with EMX */
                                                >
                                                > --
                                                > hundred-and-one symptoms of being an internet addict:
                                                > 145. You e-mail your boss, informing him you'll be late.
                                                >
                                                > /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                                > ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                                                > \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///

                                                --
                                                Corinna Vinschen
                                                Cygwin Developer
                                                Red Hat, Inc.
                                                mailto:vinschen@...
                                              Your message has been successfully submitted and would be delivered to recipients shortly.