-----Original Message----- From: Eli Zaretskii [mailto:[email protected]] Sent: Monday, May 09, 2011 10:26 AM To: Rob Juergens Cc: [email protected] Subject: Re: enhancement request for gmake
> 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? 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. _______________________________________________ Make-w32 mailing list [email protected] https://lists.gnu.org/mailman/listinfo/make-w32
