7 ms·
The nice alternative is MinGW(-w64) with MSYS or Cygwin supplying the unix utilities, though it has the problem of linking against msvcrt.dll You can use MingW
by stinos 10y ago
The nice alternative is MinGW(-w64) with MSYS or Cygwin supplying the unix utilities, though it has the problem of linking against msvcrt.dll
You can use MingW's make but compile with cl instead of gcc and that problem is not present. You will have to check if all compiler flags are supported though. Or use a wrapper around cl which translates compiler flags, pretty sure that exists already.
My preferred approach lately is an amalgamation build
That won't scale well though. For large projects you'll really want to use something as mentioned above, or have seperate Makefiles and VS projects, or use a build file generator like CMake.
edit another thing I wanted to add: instead of using
#if defined(_WIN32)
void foo() {
//win implementation
}
#else
void foo() {
//unix implementation
}
#endif
all over the place another option is to split the implementations over source files like impl/win32.c and impl/unix.c then have the build system deal with selecting the correct one. Especially when there are more than a couple of platforms this is much cleaner and more convenient.
- petters 10y agoCompletely agree about Cmake. The language may be quirky, but it has solved all the hard problems. Often the build files will be trivially short as well.
- exDM69 10y agoYes, I've been using CMake again after a few years of something else. I came back to CMake because it seems to be the build system that sucks the least. I use CMake with Ninja, which is faster and nicer than plain old Make. CMake completely falls apart if you're trying to do anything else than normal user space applications that link with commonly used libraries. Some years ago I tried building a bare metal project with CMake and the job got done but the experience was atrocious. But CMake really shines in building "normal" applications and in particular cross compiling them.
- pjmlp 10y agoAlso at least for those of us that care about C++, Google and Microsoft's adoption of it pretty much settles the question which build system to use.
- Keyframe 10y ago#if defined(PLATFORM) I would recommend against that as well. I have a directory structure where there's a module/hello.c (stub or generic, platform independent code) and then there's module/platform/hello.c which my Makefile selects over the generic one based on the platform. Primary issue is that there's some code duplication, and it's hard to keep .h files general across platforms all the time (not possible all the time), but in general it does make life a lot easier - especially if platform number grows over time or certain are removed.
- logicchains 10y agoThat's quite similar to how Go does it (Go would have something like hello_platform.c), which in my opinion works quite well. I actually find it to be one of the nicest things about Go, compared even to Haskell, which for some bizarre reason uses the C preprocessor (!!) to pepper code with #ifdefs.
- ycmbntrthrwaway 10y agoGo took this idea from Plan 9. In fact, Go shares a lot with Plan 9 C compiler structure. Related: http://doc.cat-v.org/henry_spencer/ifdef_considered_harmful http://doc.cat-v.org/henry_spencer/ifdef_considered_harmful
- Keyframe 10y agoInteresting! I never went in-depth into Go, apart from spending an afternoon with it to have a go at it.
- marcosdumay 10y ago> for some bizarre reason uses the C preprocessor (!!) to pepper code with #ifdefs. I always thought that was funny. You are using the most powerful (of the widely used) language available for transforming text, but must fall back to the C preprocessor.
- pjmlp 10y agoThat has always been my approach as well, much easier than #ifdef spaghetti.