On 04 Jul 2007 13:28:04 -0400, Camm Maguire wrote:
... How big is the mingw-ex-gcc? Is it unreasonable to include the full environment in the installer? Even macosx has bash.
Well first of all you need to distinguish between MinGW and MSYS. See: http://www.mingw.org What is MinGW? MinGW ("Minimalistic GNU for Windows") refers to a set of runtime headers, used in building a compiler system based on the GNU GCC and binutils projects. It compiles and links code to be run on Win32 platforms... providing C, C++ and Fortran compilers plus other related tools. If you see references to "mingw32" instead of "MinGW", they are referring to the same compiler system. The project's name changed from mingw32 to MinGW is to prevent the implication that MinGW will only works on 32 bit systems (as 64 and higher bit machines become more common, MinGW will evolve to work with them). MinGW uses the Microsoft runtime libraries, distributed with the Windows operating system. Unlike other ports of GCC to Windows, the runtime libraries are not distributed using Gnu's General Public License (GPL). You, therefore, do not have to distribute your source code with your programs unless, of course, you use a GPL library in your programs.. What is MSYS? MSYS or Minimal SYStem is a POSIX and Bourne shell environment use with MinGW. It provides a hand picked set of tools to allow a typical configuration script with Bourne syntax to execute. This allows most of the GNU packages to create a Makefile just from executing the typical configure script which can then be used to build the package using the native MinGW version of GCC. The POSIX layer used by MSYS is a fork of the 1.3.3 version of Cygwin . Cygwin is a full POSIX layer and UNIX-like environment for Win32 providing both server and client utilites. ------- So in short MinGW is the gcc compiler system for windows and MSYS is the rest of a simple posix-compliant development environment (unix tools like ls, rm, mv and optionally bash). It is quite possible to use MinGW without MSYS by relying on the Windows command line environment or from an IDE that supports MinGW. On my Windows system MinGW is 90 Mbytes and MSYS is 40 Mbytes. So, yes I think it would be unreasonable to include all of this in a gcl installer. The part of MinGW that is included with the Axiom on Windows installer is only about 4 Mbytes. This provides only the gcc C compiler and the necessary libraries required to compile code generated by GCL. It does not include any of the MSYS components.
Speaking of which, does anyone know how to make the mingw installer for the next GCL release?
I forget exactly what installer Mike Thomas used for the last gcl binary for Windows but there are seveal good open source ones to choose from. We used NSIS for Axiom on Windows.
> Although it requires a little more knowledge of Windows internals, I > strongly recommend that gcl on windows continue to call the windows > API instead of relying on external support for posix/unix commands in > a particular shell that is not native to Windows. For similar reasons > I also would not recommend trying to utilize the Windows non-posix > command interpreter for this purpose. > I'm happy to go along with this, though I'm not sure what benefit the user would see other than a little less disk space usage. I can only justify minimal time learning anything windows specific for this purpose, but of course will eagerly accept all offers of assistance in this regard.
Although MSYS can access the full Windows file system, it does so in a way that would be unfamilar and somewhat unnatural to a Windows user. It is better to think of MSYS as a porting environment rather than a replacement posix shell for Windows users. Of course this probably could be hidden by some clever programming in gcl but a fear that it might also be a source of problems. I understand your reluctance to spend much time learning windows specific API details. In spite of limited available time, I am willing to help with this where/when I can, but my only real experience is that gained while working with Mike Thomas for a few months a few years ago on the previous version Axiom on Windows. I do not think I know enough about either Windows or GCL internals.
Now perhaps there is just a lower level api to which I could write that would transparently be portable. E.g. implementing directory via readdir and opendir. Re-implementing all the shell pattern matching from scratch is certainly doable, but there should be some clear benefit visible that would justify the work. Its hard for me to see at the moment.
Some of these things might be available in an MSYS library but I do not know how accessible or adaptable to gcl it would be. In any case I seriously doubt that it would end up being "transparently portable".
Please see related post regarding an extra-spec posix support function proposal.
Yes, I think that's good. Now we just need to find resources to help implement this for gcl-2.7 on windows. I am also a little worried that because of the extensive differences in 2.7 memory management and other deep changes, there may be some more issues besides the file system waiting to be discovered in the windows port. :-( Has anyone actually attempted to build gcl-2.7 on Windows yet? Regards, Bill Page. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
