Re: enhancement request for gmake

Eli Zaretskii <[email protected]>
Newsgroups gmane.comp.gnu.make.windows
Message-ID <[email protected]>
> From: Rob Juergens <[email protected]>
> 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?

> 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 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).
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.