As Casey started moving from the single win32_handmadehero.cpp into handmade.cpp, handmade.h and win32_handmadehero.cpp - Visual Studio now goes berserk with build errors, most worryingly that in handmade.h and handmade.cpp it refuses to recognize 'internal void' as valid.
Even more awesome is the cl commandline build is FINE. I may have to switch over, that's cool, but I was hoping to keep trucking solely in VSS.
Thanks!
Even more awesome is the cl commandline build is FINE. I may have to switch over, that's cool, but I was hoping to keep trucking solely in VSS.
Thanks!
I'm guessing you simply added all *.cpp files to Visual Studio project?
That's now how you should do it. Casey is using unity build - basically he is compiling only one translation unit. So you need to add to project only one "master" .cpp file. Other files will be included in it. That's why commandline build works - it compiles only one .cpp file, not each one individually. If you would change cl.exe to use *.cpp as input (all .cpp files), you would get exactly same errors when compiling from IDE.
That's now how you should do it. Casey is using unity build - basically he is compiling only one translation unit. So you need to add to project only one "master" .cpp file. Other files will be included in it. That's why commandline build works - it compiles only one .cpp file, not each one individually. If you would change cl.exe to use *.cpp as input (all .cpp files), you would get exactly same errors when compiling from IDE.
Edited by Mārtiņš Možeiko
on
I'm totally laughing because there was a very strong urge when I did that saying "Welll he is doing this unity build thing, but NAH! - VSS will figure it out...it is 2015 after all..."
Thanks, it totally worked :)
BTW this forum needs a kudos/thank you system, you've been great.
Thanks, it totally worked :)
BTW this forum needs a kudos/thank you system, you've been great.
I would be afraid to use such build system which tries to guess how to compile my sources and decide on its own which files to compile and which ones not to. Too easy to make mistake and wonder why compiled software doesn't work at the end... I like my build system as dumb as possible :) Let me provide list of files to compile, and let it do its magic for each file. Or just one file if it is unity build.
Haha yeah that's an excellent point.
Never mind figured it out. It was the order of the includes and defines. I had to define the internal static first then include the typedefs. then the rest of the includes after.
#define internal static
#define local_persist static
#define global_variable static
#define Pi32 3.14159265359f
#include <stdint.h>
typedef int8_t int8; typedef int16_t int16; typedef int32_t int32; typedef int64_t int64; typedef int32 bool32; typedef uint8_t uint8; typedef uint16_t uint16; typedef uint32_t uint32; typedef uint64_t uint64; typedef float real32; typedef double real64; #include <windows.h> #include <stdio.h> #include <xinput.h> #include <dsound.h> #include "handmade.cpp"
#define internal static
#define local_persist static
#define global_variable static
#define Pi32 3.14159265359f
#include <stdint.h>
typedef int8_t int8; typedef int16_t int16; typedef int32_t int32; typedef int64_t int64; typedef int32 bool32; typedef uint8_t uint8; typedef uint16_t uint16; typedef uint32_t uint32; typedef uint64_t uint64; typedef float real32; typedef double real64; #include <windows.h> #include <stdio.h> #include <xinput.h> #include <dsound.h> #include "handmade.cpp"