Re: [Axiom-developer] Re: directory/truename transition

[Bill Page]

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.