[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: enhancement request for gmake
From: |
Eli Zaretskii |
Subject: |
Re: enhancement request for gmake |
Date: |
Mon, 09 May 2011 20:26:06 +0300 |
> 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?
> 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).
- Problems with GNU make in Windows 7 (64-bit), Rob Juergens, 2011/05/06
- Re: Problems with GNU make in Windows 7 (64-bit), Eli Zaretskii, 2011/05/07
- enhancement request for gmake, Rob Juergens, 2011/05/09
- Re: enhancement request for gmake, Rob Walker, 2011/05/09
- Re: enhancement request for gmake,
Eli Zaretskii <=
- RE: enhancement request for gmake, Rob Juergens, 2011/05/09
- Re: enhancement request for gmake, Eli Zaretskii, 2011/05/09
- RE: enhancement request for gmake, Rob Juergens, 2011/05/09
- Re: enhancement request for gmake, David Highley, 2011/05/09
- Re: enhancement request for gmake, Eli Zaretskii, 2011/05/09