Chickens and eggs on Win32

[Chad Loder]

Hi Paul. This isn't strictly a GNU make issue, but you've
been very helpful in the past.

I am trying to set up our build system using the multi-architecture
GNUmake setup you wrote about on your website. I am running on
Windows 2000 (basically Windows NT + 1), and I run into problems
at every turn.

Bash is not behaving as the manual describes (in particular, it does
not parse the bash startup files like /etc/profile, etc. as stated
in the bash 2.02 manual). So I figured I would download the bash 2.04
sources from a GNU mirror and try a fresh build.

Having done this, I need to run ./configure in order to build
the distribution. Using my somewhat flaky (but otherwise OK) version
of bash (sh.exe) which I had downloaded prebuilt from some GNU site,
I run ./configure.

Halfway through the config script, I get a Windows dialog box saying
that EXPR.exe has crashed. OK, I figure, maybe I need to build my
shell utils from scratch (this includes expr.exe). So I download the
newest sh-utils distribution from a GNU mirror. I run ./configure,
but it can't guess my host/build type (why not?). So I look through the
configure script and determine that my type should be i586-winnt.

I ran "./configure --host=i586-winnt" with somewhat better success,
but still get a failure (can't find some binaries it needs). I see that
it can't even find tar, which I surely have. Taking a closer look at
the configure script, I find the logic which checks for needed
programs:

  IFS="${IFS=   }"; ac_save_ifs="$IFS"; IFS=":"
  ac_dummy="$PATH"
  for ac_dir in $ac_dummy; do
    test -z "$ac_dir" && ac_dir=.
    if test -f $ac_dir/$ac_word; then
      ac_cv_prog_AMTAR="$ac_prog"
      break
    fi
  done
  IFS="$ac_save_ifs"

You see that IFS is being set to : (colon) before the PATH
variable is being split up. As you're aware, the colon character is the
drive letter separator on Windows NT. So my fix is to set IFS to
semicolon instead.

This gets the path split correctly, which brings us to the next
problem. The "test -f" command is looking for "C:/bin/tar", but the
file name is actually "C:/bin/tar.exe" on a Windows system (why
the hell didn't they just run "which tar" and use the return code???).

So my solution is to hack the code. Windows has a variable called
PATHEXT which gets exported to bash. The variable looks like this:

   PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH

The application is obvious: I use a for loop on $PATHEXT and look
for tar.COM, tar.EXE, tar.BAT, etc. in each of the $PATH directories.

  IFS="${IFS=   }"; ac_save_ifs="$IFS"; IFS=";"
  ac_dummy="$PATH"
  for ac_dir in $ac_dummy; do
    test -z "$ac_dir" && ac_dir=.
    for pathext in $PATHEXT; do
       if test -f $ac_dir/$ac_word$pathext; then
         ac_cv_prog_AMTAR="$ac_prog$pathext"
         echo Found $ac_cv_prog_AMTAR
         break
       fi
    done
  done

Believe it or not, this actually works. Now on to the next problem.
It wants a cc or gcc type program. So far I have avoided installing
gcc because it requires that whole Cygnus layer (we won't be using
gcc in production so I thought I could get away with it). I'd much
rather stick to native compilations.

My question is, do you think I should download the Cygnus gcc
and install it, or should I try to hack the configure script and
makefiles to work with Microsoft's compiler?

Thanks,
        Chad