Official Windows build no longer uses nmake.
The binaries are built using MSBuild.
Please look at readme_winbuild.txt or winbuild/readme.txt.
regards,
Hiroshi Inoue
(2014/06/02 20:11), Michael Paquier wrote:
> On Mon, Jun 2, 2014 at 7:48 PM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> On 06/02/2014 10:41 AM, Heikki Linnakangas wrote:
>>> On 06/02/2014 10:33 AM, Michael Paquier wrote:
>>>>> This MSDN page lists the valid values:
>>>>> http://msdn.microsoft.com/en-us/library/5wy54dk2.aspx. (the makefile
>>>>> passes
>>>>> /MACHINE:{CPUTYPE} to the compiler). We don't support compiling for ARM
>>>>> with
>>>>> the Windows toolchain, and I have no idea what EBC means, so that leaves
>>>>> just x64 and x86 as the valid options.
>>>> Let's just hardcode them and be done. Do you need a patch?
>>>
>>> Nah, I'll just do it. Thanks!
>>>
>>> (I'm trying to set up the toolchain to build Windows binaries and
>>> installers ATM, and also trying to clean up and update the docs while
>>> I'm at it.)
>>
>> So, I started looking at win32.mak and win64.mak, and couldn't resist
>> cleaning them up some more.
>>
>> I removed the CPU argument altogether, but I also removed all references to
>> it within win64.mak, and replaced them with TARGET_CPU. The "setenv /x86" or
>> "setenv /x64" command that you can use in the Visual Studio command line
>> environment to choose the target platform sets TARGET_CPU. So now you can
>> use win64.mak to build 32-bit binaries too, just do "setenv /x86" first.
> It is not mandatory to use Visual studio to compile the code as you
> can do it as well with a simple Windows SDK prompt and nmake. Wouldn't
> it be better to return an error if TARGET_CPU is not set?
>
>> Ideally, we could remove win32.mak altogether. But I don't understand the
>> differences well enough yet to go ahead with that. Thoughts?
> I'd vote +1 for removing win32.mak and rename win64.mak to win.mak.
> The only differences being that win32 can link optionaly to mt, a
> multithread lib, while win64 has support for gss. It is hard to guess
> why each option is available only on one Makefile but not the other,
> so we'd better merge them...
