"Eli Zaretskii wrote:" > > > From: Rob Juergens <rjuerg...@esri.com> > > 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
Ah, if it were only that simple. You can look at an example of what needs to be considered when dealing with Microsoft compilers across different versions by looking at the file: http://www.highley-recommended.com/make_process/bld/mkcommondefs.mk Every update brings a complete set of new directories and may include some interesting internal implementation that must be figured out like the appending of the XML text to binary files to implement the version specific library dependencies that came along with the side by side implementation. You may have multiple versions of Visual Studio installed on a system and need to configure for each at run time. We are in the process of extending our build processes to accommodate the 32 bit and 64 bit architecture build differences and the latest Visual Studio. > > 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). > > _______________________________________________ > Make-w32 mailing list > Make-w32@gnu.org > https://lists.gnu.org/mailman/listinfo/make-w32 > -- Regards, David Highley Highley Recommended, Inc. Phone: (206) 669-0081 2927 SW 339th Street WEB: http://www.highley-recommended.com Federal Way, WA 98023-7732 _______________________________________________ Make-w32 mailing list Make-w32@gnu.org https://lists.gnu.org/mailman/listinfo/make-w32
