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...
--
Michael
