Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Quasar

Why I'm a Windows programmer

Recommended Posts

CHECK_INCLUDE_FILES (stdint.h HAVE_STDINT_H)
IF (NOT HAVE_STDINT_H)
        IF (MSVC)
                ## FIXME: This is bad. stdint.h and inttypes.h should be
                ## moved to a seperate folder. They are not used by MinGW or
                ## in Visual Studio 2010 onwards, and break those builds.
                INCLUDE_DIRECTORIES (${CMAKE_SOURCE_DIR}/source/win32/)
        ENDIF (MSVC)
ENDIF (NOT HAVE_STDINT_H)
Why is this shit executing when the CMakeLists script is used in cygwin? I hate this kind of bullcrap. MSVC is not supposed to be defined on that platform.

Share this post


Link to post

What I gathered: You're a Windows programmer because you're having troubles compiling... on Windows.

In more seriousness, I would suspect it's defined to ease porting pre-existing Windows code bases.

Share this post


Link to post

Post would be better titled "Why I use MSVC in the Windows environment" because if you're a unix programmer that entire block of code means not a god damn thing, and if you're a cross platform programmer you can always make an MSVC project, and then that code still means not a god damn thing. Alternatively Quasar is post-title trolling.

Share this post


Link to post

<ConSiGno> INCOMING PASTE
<ConSiGno> In file included from /usr/include/cygwin/types.h:21,
<ConSiGno>                  from /usr/include/sys/types.h:373,
<ConSiGno>                  from /usr/include/stdio.h:46,
<ConSiGno>                  from /home/caf/eternity/source/win32/i_cpu.cpp:35:
<ConSiGno> /home/caf/eternity/source/win32/stdint.h:33:2: #error "Use this header only with Microsoft Visual C++ compilers!"
All I know is, this should not be happening, and I don't know how to fix it.

Share this post


Link to post

the whole error if anyone cares:

/home/caf/eternity/source/win32/i_cpu.cpp:32:2: #error This version of i_cpu.c is for Win32 only.
In file included from /usr/include/cygwin/types.h:21,
                 from /usr/include/sys/types.h:373,
                 from /usr/include/stdio.h:46,
                 from /home/caf/eternity/source/win32/i_cpu.cpp:35:
/home/caf/eternity/source/win32/stdint.h:33:2: #error "Use this header only with Microsoft Visual C++ compilers!"
In file included from /usr/include/cygwin/types.h:21,
                 from /usr/include/sys/types.h:373,
                 from /usr/include/stdio.h:46,
                 from /home/caf/eternity/source/win32/i_cpu.cpp:35:
/home/caf/eternity/source/win32/stdint.h:55: error: `__int8' does not name a type
/home/caf/eternity/source/win32/stdint.h:56: error: `__int16' does not name a type
/home/caf/eternity/source/win32/stdint.h:57: error: `__int32' does not name a type
/home/caf/eternity/source/win32/stdint.h:59: error: `__int8' does not name a type
/home/caf/eternity/source/win32/stdint.h:60: error: `__int16' does not name a type
/home/caf/eternity/source/win32/stdint.h:61: error: `__int32' does not name a type
/home/caf/eternity/source/win32/stdint.h:65: error: `int8_t' does not name a type
/home/caf/eternity/source/win32/stdint.h:66: error: `int16_t' does not name a type
/home/caf/eternity/source/win32/stdint.h:67: error: `int32_t' does not name a type
/home/caf/eternity/source/win32/stdint.h:69: error: `uint8_t' does not name a type
/home/caf/eternity/source/win32/stdint.h:70: error: `uint16_t' does not name a type
/home/caf/eternity/source/win32/stdint.h:71: error: `uint32_t' does not name a type
/home/caf/eternity/source/win32/stdint.h:75: error: `int8_t' does not name a type
/home/caf/eternity/source/win32/stdint.h:76: error: `int16_t' does not name a type
/home/caf/eternity/source/win32/stdint.h:77: error: `int32_t' does not name a type
/home/caf/eternity/source/win32/stdint.h:79: error: `uint8_t' does not name a type
/home/caf/eternity/source/win32/stdint.h:80: error: `uint16_t' does not name a type
/home/caf/eternity/source/win32/stdint.h:81: error: `uint32_t' does not name a type
make[2]: *** [source/CMakeFiles/eternity.dir/win32/i_cpu.o] Error 1
make[1]: *** [source/CMakeFiles/eternity.dir/all] Error 2
make: *** [all] Error 2

Share this post


Link to post

Try including <windows.h> before standard headers, and it seems silly to test for _WIN32 before including windows.h (that is where it gets defined, right?)

Share this post


Link to post

I do not do much Windows, so I am no expert, but I had to go through this for MinGW on Win98. I am assuming those are precompiler macro names.

Try (substitute your preprocessor or compiler for gcc)
> touch dummy.h
> gcc -dM dummy.h > dummy.txt

to see what that compiler thinks it is. It is even possible that you are not getting the compiler that you thought you were.
Look for the VERSION macro.

I thought MSVC was Microsoft-visual-c, which would not be that amazing that some Windows c compiler thinks it can compile it. For a unix system (from those path names it looks like unix), it would be a bit strange. A compiler defining a macro like MSVC is like all gnu C compilers defining __GNU_C__. You might have to find a more specific macro name to identify the compiler. Look for a __MSVC__.

I got an Ada GNAT compiler on a MAC that compiles C using GCC, and giving macros identical to it (except for one VERSION string).

Share this post


Link to post
Maes said:

More like "Why am I a Windows programmer?"



I actually think what he meant is that someone programming for Windows only wouldn't have to bother with all this crap.

Share this post


Link to post

But you would, provided someone tried to compile on Cygwin, which is Windows only. You could argue the same if you tried to write it Linux only, then you wouldn't have to deal with all the different Windows compilers and defines one might be using(VC++ 2005,08,11 GCC 3.X, 4.X, MinGW, MinGW64(different projects), and Cygwin). Compare this to supporting back to maybe GCC 4.2 and making sure it compiled up to GCC 4.6 on Linux. One compiler, just different versions. At most you might need to support clang too, which is pretty much fully gcc compatible.

Share this post


Link to post

Why should I bother with a MinGW setup? It's only added work for no real benefit in a Windows only project.

VC++ Express can be downloaded free of charge so it's not that by making a VC only project that someone can't use it for other reasons as stubbornness to install the required software.

Share this post


Link to post
Graf Zahl said:

Why should I bother with a MinGW setup? It's only added work for no real benefit in a Windows only project.

VC++ Express can be downloaded free of charge so it's not that by making a VC only project that someone can't use it for other reasons as stubbornness to install the required software.


Absolutely agree - never understood the 'free willy' attitude of making something complicated.
Only idea I could follow is an extra option without having to resort to MS software - from a freedom perspective understandable.

Share this post


Link to post
Graf Zahl said:

VC++ Express can be downloaded free of charge so it's not that by making a VC only project that someone can't use it for other reasons as stubbornness to install the required software.


Compulsory registration is a minor turndown, albeit I guess you could always "warez" your way into obtaining a key. Would it still be considered warez since there's no charge involved (other than your personal data and needing to have an MS Live/Hotmail account)

Share this post


Link to post

In general, I don't like GUI tools (except for stuff like graphics programs, Doom map editor, etc), so at my previous job I installed cygwin and other similar CLI stuff on the WinXP laptop they allocated for me to use. Eventually though I just repartitioned the damned thing and installed a nicer OS that came with lots more dev tools in the base system, and thousands more available instantly via the package manager. The only time I rebooted into XP was to use their crazy, proprietary version control system that only worked in Win32 (and had the clumsiest interface I'd ever seen). Many times I didn't check my code back in until several projects were completed (less time wasted that way). For the intermediate steps, I just used a personal CVS repo on one of their Linux servers.

Share this post


Link to post
Maes said:

Compulsory registration is a minor turndown.


So what? They know I use it. Big deal! Programming is my job so nothing I wouldn't mind other people to know.

Share this post


Link to post

Especially when you can register the software to Poopie McFarthead who lives at the South Pole and trains penguins to fetch beer from the fridge.

Share this post


Link to post

To even log in to the registering procedure you gotta have a valid Hotmail/Live account. Unless you ALSO registered that one as Poopie McFarthead. And despite that, they still ask a crapload of data which they could've lifted off your account anyway, plus some more.

Share this post


Link to post

Did a grep of the /usr/include files to see what they use to detect MSVC. MSVC is mentioned, but not tested anywhere I saw.
I think it they were testing _MSC_VER to detect that compiler (better check for yourself).
They must know something.

Share this post


Link to post
Quasar said:

CHECK_INCLUDE_FILES (stdint.h HAVE_STDINT_H)
IF (NOT HAVE_STDINT_H)
        IF (MSVC)
                ## FIXME: This is bad. stdint.h and inttypes.h should be
                ## moved to a seperate folder. They are not used by MinGW or
                ## in Visual Studio 2010 onwards, and break those builds.
                INCLUDE_DIRECTORIES (${CMAKE_SOURCE_DIR}/source/win32/)
        ENDIF (MSVC)
ENDIF (NOT HAVE_STDINT_H)
Why is this shit executing when the CMakeLists script is used in cygwin? I hate this kind of bullcrap. MSVC is not supposed to be defined on that platform.


I wrote this code.

MSVC IS NOT defined when building with Cygwin.

The problem you have is clearly listed in the comments. I brought it up with you when I wrote the code. You include your own copies of stdint.h and inttypes.h in source/win32 - this include path is added to your search directory when trunk/source/CMakeLists.txt is parsed. I did not test cygwin at the time, if I had, it would also be listed as broken in the comments.

The solution now, is the same as I proposed when I wrote the code. Move the replacement stdint.h and inttypes.h to another directory, so it doesn't break on MinGW, Cygwin, VS2010+ - yes this will involve a small patch to the CMakeLists.txt to include the new directory for old MSVC compilers.

Share this post


Link to post
Yagisan said:

I wrote this code.

MSVC IS NOT defined when building with Cygwin.

The problem you have is clearly listed in the comments. I brought it up with you when I wrote the code. You include your own copies of stdint.h and inttypes.h in source/win32 - this include path is added to your search directory when trunk/source/CMakeLists.txt is parsed. I did not test cygwin at the time, if I had, it would also be listed as broken in the comments.

The solution now, is the same as I proposed when I wrote the code. Move the replacement stdint.h and inttypes.h to another directory, so it doesn't break on MinGW, Cygwin, VS2010+ - yes this will involve a small patch to the CMakeLists.txt to include the new directory for old MSVC compilers.


THANK YOU

Share this post


Link to post
Csonicgo said:

THANK YOU

I already knew the fix to this the night you left saying you wouldn't have time to test it. Yagisan and I discussed it in IRC and he thinks the same thing I thought - the line of code adding /source/win32 as an include directory in /source/CMakeLists.txt is unnecessary.

So, please get your ass back in IRC.

Share this post


Link to post
Quasar said:

I already knew the fix to this the night you left saying you wouldn't have time to test it. Yagisan and I discussed it in IRC and he thinks the same thing I thought - the line of code adding /source/win32 as an include directory in /source/CMakeLists.txt is unnecessary.

So, please get your ass back in IRC.


I won't be around during the holidays.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×