Live data from Hacker News

A Simple Makefile for Medium-Sized C/C++ Projects

spin.atomicobject.com

81–90 of 120 posts

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#81
post #42

Earlier quoted context omitted.

Still hell of a lot simpler than hand-writing Makefiles though. For both small and large projects. I mean, a "hello world" CMakeLists.txt can be literally just this: add_executable(hello hello.c) And it's cross-platform, can generate Visual Studio/Xcode/... projects, etc.

I think we have to go deeper than that to really see an advantage of cmake. A corresponding makefile would be: all: hello That's not really complicated either.

The thing is that these are not equivalent hello worlds. I mean, if only for the fact that the cmake example does proper header dependency management, which is essential to correctly compiling c/c++ code as it changes. It's not something you can leave out of a makefile and still call it correct.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#82
post #16

It always annoys me that we don't have better solutions for building C and C++ projects by now. My own take on the generic drop-in makefile[1] has over 1000 stars on github, which says pretty loudly to me that this is a common pain point for many people. Alas I haven't had a brilliant idea for a solution (yet). [1]: https://github.com/mbcrawfo/GenericMakefile

True. Other languages have it way easier because: - proper module system, none of this header file nonsense - no compiler flags to worry about - no preprocessor definitions to worry about - as a consequence of the above, no dependencies that require their own linker flags, include directories and preprocessor definitions to work - no need to support different compilers/platforms with different configurations (which w…

Out of curiosity, how do other languages cope with:

a. Targeting different release types (debug vs release)

b. Changing behaviour of the compiler

c. Having different code paths between debug and release (#ifdef _DEBUG)

d. Having macros and helpful macro expansion

I do not understand the dislike of header files: how would you recommend distributing DLLs and libs while exposing their functions to be developed against?

I suppose you could implement everything in a header file if you wanted a simple "module" system (thinking of the header as a module), but this would establish a very simple system with no interdependencies or reusability.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#83

This approach is flawed because it uses "find" to discover the source files which means that if you delete a source file, it won't cause a rebuild since it won't see any changed files.

It's probably possible to adapt it to do that by using find much like you use gcc -MM to get header deps, generating a make snippet that you then depend the executable output on. But then we're getting pretty nasty.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#85
post #10

Please don't brew your own build system. It likely won't handle at least one of the following situations: * installing into a DESTDIR * setting custom CFLAGS/LDFLAGS * changing prefix, libdir, sysconfdir * cross-compilation * parallel builds * conditional features * missing requirements and will make packaging your software in Linux distros much harder than it needs to be.

The LibreOffice build system (which is plain GNU Make, without generated unreadable intermediate build files) does all these and more. Doing the same with autotools would be a nightmare.

We do however have some serious gnu make gurus to make that tractable.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#86
post #16

It always annoys me that we don't have better solutions for building C and C++ projects by now. My own take on the generic drop-in makefile[1] has over 1000 stars on github, which says pretty loudly to me that this is a common pain point for many people. Alas I haven't had a brilliant idea for a solution (yet). [1]: https://github.com/mbcrawfo/GenericMakefile

We do. We have decent tooling (Visual Studio, Xcode) which let us set options and let us run compilers from the commandline using the options in the project and solution files (nmake, msbuild, xcodebuild) to save us having to use a hand-written Makefile.

If you're still writing small projects and insisting on running a build in a command window, or writing code in a simple editor then I can perhaps understand the complaint. But you quickly grow out of that when you start writing larger projects.

I couldn't imagine the 2+ million line codebase at work using hand-written makefiles. It builds for debug, release, MBCS and Unicode, and with different versions from source control every night, so multiple versions for different branches are built.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#87

The problem with Makefiles is that they don't work on Windows with Visual Studio, and generally only have very limited support in IDEs like Xcode, QtCreator, etc... and once stuff like cross-compilation and feature selection comes in, they get really messy really fast. That's where meta-build-systems like cmake etc come in. They all have their faults (cmake has a terrible scripting language), but they solve real prob…

I agree that cross-platform is tricky and in the past I have used SCons with some success for that.

Although, at least for Xcode, I can build my entire Xcode project from a Makefile: you just have to use command-line tools like "xcodebuild", and if you want a clickable version you set up a build phase that runs "make". And, while Apple’s ".xcconfig" files are not exactly "make" syntax, they support a subset that looks exactly the same so it is possible to have files with variable settings, etc. that can be referenced by both Xcode and any Makefile that needs to stay in sync. Environment variables are yet another option.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#88

I'm going to take this opportunity to rant about sad state of C++ open source. I would really really like to write some C++ but I'm not a C++ guru; so I tried installing facebook/folly and facebook/fatal on my Mac OS. That just doesn't work. It wasn't written cross platform and it probably never will. So I spun up a ubuntu VM and tried there. fatal compiles, folly still doesn't... And so ends my brief foray into C++.…

Why not just use Xcode and xcodebuild from the CLI if you don't like the IDE?

I write all my OSX projects in C++ using it.

Learning to build projects and solve compiler and linker errors is part of the journey. Stroustrup's book takes longer to read than 5 minutes, so writing C++ will take longer. It is a rewarding journey, where you will suddenly find all other languages (Java, C#, C, JavaScript, Swift) very similar or simplified in comparison.

To get you started you could install xcode and the commandline tools, write your file.cpp and use:

g++ -o myprogram file.cpp

This assumes no linker options, no preprocessor options or anything, and on OSX will use clang, which it secretly symbolic links as g++. You might find it easier to get your head around it by starting a project in Xcode, setting the options in the IDE and then observing the output that it runs.

Note that installing a library on most Unix platforms isn't complicated - configure, make, make install.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#89
post #32

Earlier quoted context omitted.

cmake generally works great, but the larger and more complex the project gets (and the more platforms you need to support), it gets exponentially uglier. I've had the displeasure of needing to maintain a single cmake infrastructure for a large (~500K or so lines plus 3rd party libs) project that targeted Windows, Linux, Mac, iOS, Android, and a few other obscure mobile platforms. Here was the progression: 1. Linux ta…

Would you write an article detailing your experience? It sounds fun to read.

Honestly, I don't think I could afford the therapy that I would need to re-live that part of my career in the detail that it would take to do a proper write-up. To this day, I still have no idea how an Android project actually winds up getting built, and their build system philosophy seems to boil down to "keep adding layers of magic, each making lower levels of magic harder to hand-edit and understand".

Most of the difficulty to be honest was with: 1. third party libraries, and 2 the Android NDK.

For third party libraries, every one was slightly different in some frustrating way. Some of them used bog-standard makefiles (thank you, third party developers who do this!), so they basically just worked. Some of them used autoconf/automake, which makes me sad but you can generally get cmake to mate successfully with them. Some of them helpfully had their own CMakeLists.txt, which would build the library, but invariably could never be successfully integrated into a larger project. Some non-open-source libraries came with just one platform's build support, so you'd have to hand-build CMake support for them, and guess which files actually needed to be built/linked. Some of them cleverly generated some of their own source files during the build process ("This is fun to maintain" said nobody ever).

The Android NDK seems to be some Googler's frankenstein hobby project that got accidentally electrified into life and set loose on the world. Like Donald Trump, the NDK is kind of an embarrassing offshoot from the "mainstream Android development story," one that Google would like to pretend doesn't exists. They, in fact, tell you in their docs "Yea, you can use native C and C++ to write Android apps with this thing, but you really shouldn't!" [1] Seriously, their "Getting Started" guide spends a paragraph or so trying to convince you not to get started. Convincing Google's own development tools to build C++/NDK is pretty frustrating itself, so you can imagine how difficult it is to convince cmake to do it.

In short, if you are working on a project that targets desktop, embedded, and mobile platforms and has lots of third party code, and one day that little voice in your head starts saying "Hey we waste a lot of time maintaining separate Makefile, .xcodeproj, .vcproj, etc. Why don't we switch to a single glorious build system that lets us list our source files in one place!?" IGNORE THAT VOICE. Go play some foosball, fix a few bugs, have a cup of coffee, but by no means try to use cmake for this.

1: https://developer.android.com/ndk/guides/index.html

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#90

Earlier quoted context omitted.

True. Other languages have it way easier because: - proper module system, none of this header file nonsense - no compiler flags to worry about - no preprocessor definitions to worry about - as a consequence of the above, no dependencies that require their own linker flags, include directories and preprocessor definitions to work - no need to support different compilers/platforms with different configurations (which w…

Out of curiosity, how do other languages cope with: a. Targeting different release types (debug vs release) b. Changing behaviour of the compiler c. Having different code paths between debug and release (#ifdef _DEBUG) d. Having macros and helpful macro expansion I do not understand the dislike of header files: how would you recommend distributing DLLs and libs while exposing their functions to be developed against?…

In Java with maven as a package manager:

a. Different build goals with different settings in a build file.

b. Build steps can be changed in the build file but there are a lot of sane defaults.

c. Plain constants and if statements. The compiler optimizes away dead code.

d. Code gen is done as another step before the build and not really a task of the compiler.

Post reply on HN