[Rubyinstaller-devel] make.cmd?

Luis Lavena luislavena at gmail.com
Sat Apr 19 19:23:04 EDT 2008

On Sat, Apr 19, 2008 at 11:51 AM, Gordon Thiesfeld <gthiesfeld at gmail.com> wrote:
> On Fri, Apr 18, 2008 at 8:15 PM, Luis Lavena <luislavena at gmail.com> wrote:
>  >
>  >  There is no need to add mingw or msys to the path, since when bash
>  >  start it parses profile and setup $PATH to include both, mingw and
>  >  msys tools.
>  >
>  >  Anyway, we will need wrap 'gcc' too, since is something extconf uses
>  >  to try definitions that create the makefile.
>  >
>  >  The only problem is that ruby doesn't like it, and I had problems in
>  >  the past due that, and was ruby exec code.
>  >
>  >  Let me explain:
>  >
>  >  When you issue 'make' in the command line, the cmd interpreter
>  >  (cmd.exe) will try to find an executable of make, based on 'make' +
>  >  one of the extensions in PATHEXT environment variable, in the order
>  >  they are listed:
>  >
>  >  make.com, make.exe, make.bat, make.cmd, etc.
>  >
>  >  The problem is ruby exec doesn't work like that. if you supply a
>  >  command without the extension, it will look for executables (com and
>  >  exe), but you must explicitly indicate .bat or .cmd when executing
>  >  batch files.
>  >
>  >  try creating a make.bat that just echo something and do:
>  >
>  >  ruby -e "system('make --version')"
>  :-P
>  C:\ruby\ruby_mingw>which make.exe
>  which: no make.exe in
>  (c:\wix;c:\windows\system32;c:\windows\system;C:\Program
>  Files\Subversion\bin;C:\Program Files\Bazaar;C:\Program
>  Files\Git\cmd;C:\ruby\ruby_mingw\bin;C:\bin;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program
>  Files\Putty;c:\bin\console2)
>  C:\ruby\ruby_mingw>which make.cmd
>  C:\ruby\ruby_mingw\bin\make.cmd
>  C:\ruby\ruby_mingw>irb
>  >> `make --version`
>  => "GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.\nBuilt for
>  i686-pc-msys\nCopyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97,
>  98, 99, 2000\n\tFree Software Foundation, Inc.\nThis is free software;
>  see the source for
>  copying conditions.\nThere is NO warranty; not even for
>  to <bug-make at gnu.org>.\n\n"
>  >>

What The Hell???

I tried that before send the mail to the list, just to confirm what I
was getting for the past years... and it failed...

Now that I try again, and again, and again, it works???

(make.bat) put into %HOME%/bin (which is in PATH).

ECHO.Simulate Make.
ECHO.parameters to be passed: %*

Now, using CMD.exe, in HOME or any other drive letter:

C:\>make --version
Simulate Make.
parameters to be passed: --version

(make.bat is in D:\Users\Luis\bin\make.bat), don't have msys tools in
the path for this test.

Ok, now Ruby:

C:\>ruby -e "puts Dir.pwd; system('make --version')"
Simulate Make.
parameters to be passed: --version

The damn thing worked!

I always got mixed results from system/backticks/exec ...

But!, now I know how to make it fail...

1) Create a empty 'make' file and put in a path that is listed
*before* the one that holds your make.bat (system32 is a good place).

D:\Users\Luis>ruby -e "puts Dir.pwd; system('make --version')"

No output from system call... because it found the first occurrence of
make (extension less).

2) Now move the empty make file into a directory of PATH that happens
*after* the position make.bat is located (example, I moved it to
c;\program files\putty)

C:\>ruby -e "puts Dir.pwd; system('make --version')"
Simulate Make.
parameters to be passed: --version


so it seems is not just looking for executable files, but any file
that matches the search criteria (make.*), the first found, the first
served, no matter if is an executable or not.

>  OK, I've seen this problem before too, with Rakefiles that shell out
>  to use 'gem' and things like that, and I've always made the same
>  assumption that Ruby didn't process bat or cmd file. But what was
>  bugging me after I read your email was that my make.cmd worked, and
>  there is no other make in the path.  First of all, it does seem to run
>  bat and cmd files, but they have to be in the path not in the same
>  folder you're in.  This may be a 'feature' ;-), similar to the way
>  *nix won't let you run shell commands in your current folder without
>  adding ./ in front of them. Make a simple batch file, like this:

Yes, a true feature :-P

>  REM test.cmd
>  @echo off
>  date /t
>  Stick it in ruby\bin, or somewhere else in the path and then try to
>  run it.  It works for me.
>  The problem with the gem command and commands created by RubyGems, is
>  that Ruby will find the ruby file at the command first and try to
>  execute it, and the shell doesn't know how to run it (Windows doesn't
>  do shebang lines). So, if you move the ruby file with no extension out
>  of the bin folder, and adjust the batch file to point to it, it will
>  work.  At least it works on my machine ;-).

The issue with 'gem' is that rubygems generates to files: gem and
gem.bat which is a stub to execute the true gem ruby script.

If we move from script+stub to scripts similar of what ruby ships
(take a look at irb.bat) can workaround the issues with
"cross-compatibility" raised of being using

>  >  I like the idea and you aren't oversimplifying it, I think Ruby is
>  >  broken in that aspect.
>  >
>  >  Maybe we can fix that damn thing in ruby C code and workaround that?
>  >
>  >  win32/win32.c:989 (CreateChild function), call dln_find_exe
>  >  dlc.c:1671 (dln_find_exe function), call dln_find_1
>  >  dlc.c:1796 (dln_find_1 function), call eaccess
>  >  file.c:897 (eaccess function), call access API with 'path' and mode =
>  >  X_OK (io.h)
>  >
>  Maybe Ruby's not totally broken here, just undocumented?  Take a look
>  and let me know what you think.

Please let me congrats you Gordon, you just hit one of the big issues
that blocks true cross-platform implementation.

Also, these injected stubs/scripts can workaround the pipes issues for
scripts using .rb and being tried to executed standalone (this is an
old issue of ruby and how cmd creates the process and pass the
information to the child process).

With the fix for Vista the MinGW guys are working, maybe then we could
add a 'gcc' and 'make' stubs that transparently load the mingw/msys
environment for you :-D

So the Developer Kit only will be the packages we already have (a bit
of cleanup) and let it drop these stubs into ruby/bin :-)

I love the idea! Thank you for taking the time exposing your point, It
was really enlightening

Luis Lavena
Multimedia systems
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

More information about the Rubyinstaller-devel mailing list