A fast, easy to use, free, and community supported 2D game engine
"then got 67,000 errors."
Dude, I wish:
1. you worked on a big software team,
2. you accidentally checked that in.
You would be the most legendary build breaker on the planet. That would be the Hiroshima of checkins.
ps
Love the way you're so casual about it :) I'd be freaking out!!
Benihana
Member
Oh, well the blocks extension was written by Apple, but since it is an extension of C, it is not terribly different than, say, adding a type like int or char. Very different from simply adding a class. I also think Apple was probably hoping blocks would become more standard.
I know this thread is old, but I just ran into this and thought I'd leave this here for future googlers. I'm really using cocos2d-x, so mostly writing C++, but it's the same issue biting me. I named a file Block.h. It's for blocks. Like in a game. That has blocks, among other thing. No big deal, blocks are a time honored concept in video games, right?
It worked fine for several days. My blocks blocked things. Then I was trying to add an external library and needed to add a header search path. Poof. Several hundred errors before I even tried to #include anything from it. "That's odd, it must have some conflicting header in it." Take search path back out, everything builds again. After trying a couple of things and always getting the same errors, I added an empty directory, completely empty, to my header search path, and got the same issue. WTF! It would still work fine if I put the header search paths back the way they were. So I spent some time googling "too many header search paths xcode" and the like and found nothing. Then I tried just changing the order of my existing search paths and it all broke again.
Eventually I got down into manually deleting all the shared cached precompiled headers. That finally broke it consistently everywhere, even with my original configuration. Progress!
At some point, I managed to get an error out of it that showed Prefix.pch was the file being compiled when I actually had problems. Still no "Block.h" apparent. But I added a syntax error to another header it was telling me about a random name conflict from (which there was no reason for it to be grabbing from Prefix.pch!) and finally got a header path showing my Block.h being included from the system CFBase.h. Crazy! It's not even in any of my search paths, it's in a subdirectory of my project and I don't have recursive searching turned on for anything, but it's doing so anyway.
The reason it worked for me for a while when I first added that file must be that it never thought it needed to rebuild the precompiled header when I first added it (which ought to be true), so I was happily building with an old pch cache that had the correct system Block.h in it. Only when I changed something (adding a header search path) that required a new PCH to be built did everything blow up. And the caching of PCHs was "smart" enough when I changed my header paths back to exactly how they started that things worked again in that case too.
I guess at this point my solution is to rename my Block.h. There doesn't seem to be another way around it. Also, I did find another page with the same problem building on MacOS, so it's not just the iOS SDK with this issue. I didn't see a real solution in that thread either though.
You must log in to post.
