RE: enhancement request for gmake

[Rob Juergens]

-----Original Message-----
From: Eli Zaretskii [mailto:address@hidden 
Sent: Monday, May 09, 2011 10:26 AM
To: Rob Juergens
Cc: address@hidden
Subject: Re: enhancement request for gmake

> From: Rob Juergens <address@hidden>
> Date: Mon, 9 May 2011 09:51:17 -0700
> 
> In most Unix environments, the "cc" program has a switch to build either a 
> 32-bit or a 64-bit environment,
> For example "gcc -m32 ..." or "gcc -m64 ...".
> 
> However, in Windoze, there are separate programs that must be invoked:
> 
>       32 bit: C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe
>       64 bit: C:\Program Files\Microsoft Visual Studio 
> 9.0\VC\bin\x86_amd64\cl.exe

You can always write a batch file, cc.cmd, say, that accepts the -m32
etc. switches and invokes the right program.  It would be a very
simple batch file, no?

No, such a batch file is not simple.  The make files must be able to run in any 
environment (Windoze, Solaris, Linux, etc).

> Add a new function "shortname", which in Windoze creates a short name of the 
> given name, and in all other environments just copies the name.  Thus, I can 
> then do the following:
> 
>       VSINSTALLDIR := $(strip $(shortname C:/Program Files/Microsoft Visual 
> Studio 9.0/VC/bin))
> 
> And then just invoke the command "$(VSINSTALLDIR)/cl.exe".

Don't you already have environment variables that point to that
directory?  E.g., on every Windows system, $(ProgramFiles) has as its
value "C:\Program Files".  I'd imagine that Visual Studio defines
similar variables as well.  Doesn't it?  If it does, you could use
existing variables instead of creating them.

The problem here is that make still doesn't understand the issue.  If I have 
the lines:

        %.$(OBJ_EXT) : %.c
                $(ProgramFiles)/Microsoft ...     or
                $(VSINSTALLDIR)/bin/cl
Make will still only look for the first token (up to the first space).
If I put quotes around it, make includes the quotes when looking for the name.

> The only changes would be in function.c.  Here is the code:
> 
> #if _WIN32
> #include <windows.h>
> #endif
> 
> .....
> 
> static char *
> func_shortname (char *o, char **argv, const char *funcname)

I don't really object, but it doesn't feel right to introduce a
function whose semantics makes sense only on Windows.  If one of the
above solutions is acceptable, I think it's better not to add such a
function.  If you insist, I'll let Paul decide.

> {
>   /* Expand the argument.  */
>   const char *p3 = argv[0];
>   const char *p2;
>   PATH_VAR(path);
>   int doneany=0;
>   unsigned int len=0;
> 
>   while ((p2 = find_next_token (&p3, &len)) != 0)
>     {
> #if _WIN32
>        len = GetShortPathName(p2, path, PATH_MAX);

Are you sure it's okay to call this in a loop like that?  The argument
file name could have blanks, right?  And find_next_token will deliver
the file name in chunks of non-whitespace characters, right?  Is that
what you want?

> #else
>        strcpy(buf, p2);
>        len = strlen(buf);
> #endif

Note that the _WIN32 and the #else branches have different semantics:
the Windows branches requires that the argument exists as a file in
the file system, while the non-Windows branch will happily work with a
name of a non-existent file.  Also, the Windows branch does not deal
with failures of GetShortPathName (it returns zero in that case).


You are correct.  The code should probably be:

static char *
func_shortname (char *o, char **argv, const char *funcname)
{
  /* Expand the argument.  */
  const char *p3 = argv[0];
  const char *p2;
  PATH_VAR(path);
  unsigned int len=0;

  p2 = find_next_token (&p3, &len);
  if ( p2 != 0 )
        {
#if _WIN32
           len = GetShortPathName(p2, path, PATH_MAX);
#endif
         if (len == 0)
           {
              strcpy(path, p2);
            len = strlen(path);
         }
           o = variable_buffer_output (o, path, len);
        }

  return o;
}

Then the $(strip(...) isn't needed.