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

Re: [Jal_developers] minGW

Expand Messages
  • Craig Franklin
    ... mingw sets the __unix__ macro. It was not intended to be used for mingw. The install path is used even though the path is incorrect. I placed a patch on
    Message 1 of 7 , Apr 7, 2003
    • 0 Attachment
      Mark Gross wrote:
      >
      > I'll have to look into this. The default search path isn't right when JAL is
      > build with MS-Dev either. (Most likely its the path name slashes not working
      > well with the Winodos/FAT/NTFS file systems.)
      >

      mingw sets the __unix__ macro. It was not intended to be used for
      mingw. The install path is used even though the path is incorrect. I
      placed a patch on the patch manager. It should be commited. That will
      take care of some of the problems.

      > One thing we should close on is under a Windows install where should the
      > default install / search path be for the jal libraries? Do we want to
      > implement to the MS standards and use someing in "program files", or simply
      > assume something off or root and avoid long file names with white spaces?
      >

      This is why I tried to prevent using the default path with win32. There
      isn't a right answer. Probably adding a jal.ini with a pointer to
      libaries is the only way to make everyone happy. For gputils, I hard
      wired the header path to c:\gputils\header.

      > --mgross
      >
      >
      > To unsubscribe from this group, send an email to:
      > Jal_developers-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • japus10
      Hi Mark, The JAL_LIB_PATH I was talking about is inside the MinGW application. When I execute make install the jal.exe file it s placed in /local/bin and
      Message 2 of 7 , Apr 7, 2003
      • 0 Attachment
        Hi Mark,

        The JAL_LIB_PATH I was talking about is inside the MinGW
        application. When I execute "make install" the jal.exe file it's
        placed in /local/bin and libraries in /local/share/jal/lib.

        The compiler (jal.exe) accepts one or more -s parameter (we can use
        a system library path and others user paths). If after the "make
        install" there's a fixed location of the executable and the
        libraries, this path shouldn't be already into the jal.exe?.

        MinGW can be a silly application, but it's great for me: I can
        compile, make and install a source file and see the results easilly.
        I'm learning to use commands like grep, bach files, etc. I think that
        this application is a good step to learn unix command and ussage.


        > One thing we should close on is under a Windows install where
        should the
        > default install / search path be for the jal libraries? Do we want
        to
        > implement to the MS standards and use someing in "program files",
        or simply
        > assume something off or root and avoid long file names with white
        spaces?
        >

        JAL it's a DOS application, and you know what's happen when you
        are using DOS appl. with long names like "c:\Program files\JAL\BIN".

        A better solution is to use a ini file to read the default
        parameters.


        Regards, Javi.
      • Mark Gross
        ... oh. I was thinking you where concerned about the behavior from the perspective of a binary install of JAL on a Win32 platform. ... Yes this is true. But,
        Message 3 of 7 , Apr 8, 2003
        • 0 Attachment
          On Monday 07 April 2003 10:51 pm, japus10 wrote:
          > Hi Mark,
          >
          > The JAL_LIB_PATH I was talking about is inside the MinGW
          > application. When I execute "make install" the jal.exe file it's
          > placed in /local/bin and libraries in /local/share/jal/lib.

          oh. I was thinking you where concerned about the behavior from the
          perspective of a binary install of JAL on a Win32 platform.

          >
          > The compiler (jal.exe) accepts one or more -s parameter (we can use
          > a system library path and others user paths). If after the "make
          > install" there's a fixed location of the executable and the
          > libraries, this path shouldn't be already into the jal.exe?.

          Yes this is true. But, its an extra step the user needs to know about to use
          JAL. Also, under Win32 "make install" doesn't hold much meaning.

          >
          > JAL it's a DOS application, and you know what's happen when you
          > are using DOS appl. with long names like "c:\Program files\JAL\BIN".
          >

          Technicaly, the JAL that is built using the MSDev make files I checked in are
          Win 32 command line programs. The runtime libraries its linked with have no
          problems handling long path names. I guess what I'm saying is long path
          names "should work" when running JAL from a windows command or cmd window.
          If it doesn't then its a bug.

          > A better solution is to use a ini file to read the default
          > parameters.
          >
          ini files are so old-school. I think it would be better to use Win32
          enviornment variables if we need to go this way.

          --mgross
        • Javier Martinez
          We forget that JAL works in DOS with cwsdpmi.exe . How many people are running a PC with only MS-DOS as a system? When the JAL sources wasn t free have a
          Message 4 of 7 , Apr 8, 2003
          • 0 Attachment
            We forget that JAL works in DOS with 'cwsdpmi.exe'. How many people are
            running a PC with only MS-DOS as a system? When the JAL sources wasn't free have
            a meaning to other OS, because they run jal in a ms-dos emulator. And now?
            Change it into a console application? I think that now there's no users working
            with JAL in ms-dos 6.2.

            > ini files are so old-school. I think it would be better to use Win32
            > enviornment variables if we need to go this way.


            You are right, for win users the jal compiler can have this information in
            via Win32 enviornment variables (done in a installation, there's also done for
            Unix/Linux users, but I don't know what to do with other people working with
            other SOs.



            Javi.
          • Mark Gross
            ... I don t think there are any, and if there are I m thinking that I don t care to worry about them. I m sorry if I sound cold hearted, but thats the way I
            Message 5 of 7 , Apr 8, 2003
            • 0 Attachment
              On Tuesday 08 April 2003 08:57 am, Javier Martinez wrote:
              > We forget that JAL works in DOS with 'cwsdpmi.exe'. How many people are
              > running a PC with only MS-DOS as a system? When the JAL sources wasn't
              > free have a meaning to other OS, because they run jal in a ms-dos emulator.
              > And now? Change it into a console application? I think that now there's no
              > users working with JAL in ms-dos 6.2.

              I don't think there are any, and if there are I'm thinking that I don't care
              to worry about them. I'm sorry if I sound cold hearted, but thats the way I
              feel. Someone other than myself can do the maintance needed to keep the dos
              compatability tested and working. (I can't even test on dos, I no longer
              have any 16 bit OS systems.)

              >
              > > ini files are so old-school. I think it would be better to use Win32
              > >
              > > enviornment variables if we need to go this way.
              >
              > You are right, for win users the jal compiler can have this
              > information in via Win32 enviornment variables (done in a installation,
              > there's also done for Unix/Linux users, but I don't know what to do with
              > other people working with other SOs.

              I'm willing to make someithing "work" for JAL programmers running Windows, and
              the Linux/Cygwin side, but other OS's need to be supported by someone with
              intrests in these other OS's. If its a low user base then the support could
              be maintained as a patch against the CVS tree. In manner similar to the
              way Linux support multiple platforms.

              --mgross
            Your message has been successfully submitted and would be delivered to recipients shortly.