Dude use cmake like a proper adult
A Simple Makefile for Medium-Sized C/C++ Projects
91–100 of 120 posts
Re: A Simple Makefile for Medium-Sized C/C++ Projects
#92Ummmm use cmake like a proper adult
Re: A Simple Makefile for Medium-Sized C/C++ Projects
#93Earlier 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?…
Examples from Java:
a. debug/release doesn't matter much so all Java code is in "debug" mode (http://stackoverflow.com/questions/8613535/does-java-have-de... ); the actual debugging is handled via source code/source code jars (jars are just zip files with a standard structure) -> Maven: https://maven.apache.org/plugins/maven-source-plugin/jar-moj...
b. configuration files -> Maven: https://maven.apache.org/plugins/maven-compiler-plugin/compi...
c. don't do that? :)
d. no macros and most people seem to agree that's a good thing; C macros are not really the kind of tool you want to be using, unless forced to; code generation is used instead
Regarding header files: Javadoc for humans, code inspection on the class files for IDEs. No need for separate files in a system designed after the 70s :)
Re: A Simple Makefile for Medium-Sized C/C++ Projects
#94I'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++.…
C++, regardless of open/closed source is not in a sad state IMO. The problems you describe sound like they're from the perspective of someone who's worked with much higher level languages. C++ is as good (or as bad) as it's always been, it hasn't evolved to a bad state.
New language designers have the luxury of having been bit by C/C++'s misfeatures and wrinkles. They also have the luxury of high end computers which can solve lots of problems in reasonable computation time. This means that modern languages can afford to trade off more computation resources in favor of development simplicity.
> But I'm just a user of the language. I don't have time and expertise to tackle those build issues and quite frankly installing any library is a major PITA.
I have a hard time understanding what "just a user" of the language means. It sounds like you're confessing to being a novice. That's fine, but you should be prepared to have to do a lot of work before you become proficient in C/C++. Much more so than modern languages.
Re: A Simple Makefile for Medium-Sized C/C++ Projects
#95Earlier quoted context omitted.
Auto tools is great. To compile all you do is ./configure make make install It couldn't be simpler. Even though I am part of the GitHub generation, I don't see why so many of my peers hate it. I actually like it.
This only works in the Unix world, on Mac only for command line tools (but only after installing autoconf and make), and not at all on Windows unless you install a complete Unix environment (cygwin or mingw).
Why would it only work with command line programs on the Mac? That's definitely not true, unless something changed very recently.
Also, you don't need autotools itself to build a autotoolized program. The generated configure script is portable sh.
Re: A Simple Makefile for Medium-Sized C/C++ Projects
#96Earlier 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?…
> 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?
Do you enjoy writing out all your function signatures twice? Haven't you ever wished the compiler could automatically build the header file for you?
Re: A Simple Makefile for Medium-Sized C/C++ Projects
#97This is a good start. Could be made a bit more minimal.
I'll throw my base Makefile into the fray [0].
It supports cross compilation, CFLAGS & LDFLAGS usage, dependency file generation, source file autodetection (add the file to right folder and it's automatically included in the build), library building (`make lib`), Continuous Integration (`make start_ci/stop_ci`), Continuous Testing (`make start_ct/stop_ct`), Continuous Deployment (`make start_cd/stop_cd`), Installation (`make install`), Uninstallation (`make uninstall`), parallel compilation (`make -j4`), there's some build machine detecting/autoconfiguration support, build artifact generation, and even some git shortcuts (`make gstat/make make gpush`).
All in about 190 lines of Makefile (including some comments, and lots of blank space lines). It does depend on GNU watch if you use any of the `start_/stop_` targets. I'm about to add self-documentation to it as well.
For more minimal, comprehensible approaches, see the work of the suckless people [1][2][3].
[0] https://github.com/lpsantil/NewProj
[1] http://git.suckless.org/dwm/tree/Makefile
Re: A Simple Makefile for Medium-Sized C/C++ Projects
#98Can we kill raw makefiles already? Projects that don't handle out of source builds in a sane way are awful to integrate.
Re: A Simple Makefile for Medium-Sized C/C++ Projects
#99Earlier quoted context omitted.
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…
Absolutely crazy.
Thanks for the write up.
Re: A Simple Makefile for Medium-Sized C/C++ Projects
#100This is a good start. Could be made a bit more minimal. I'll throw my base Makefile into the fray [0]. It supports cross compilation, CFLAGS & LDFLAGS usage, dependency file generation, source file autodetection (add the file to right folder and it's automatically included in the build), library building (`make lib`), Continuous Integration (`make start_ci/stop_ci`), Continuous Testing (`make start_ct/stop_ct`), Cont…
> a bit more minimal
ie. smaller, which is ironically smaller than the quote
edit: compared to 'gcc $CFLAGS $LDFLAGs *.c' it's all rather bloated