5 ms·

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 st

by Merad 10y ago

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 https://github.com/mbcrawfo/GenericMakefile

vvanders 10y ago
The solution is good tooling, Visual Studio makes this a non-issue with sane defaults that can be extended if needed. I haven't tried CLion yet but I would assume it's decent given JetBrain's track record.
realharo 10y ago
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 work differently with libraries that require different linker flags and include directories and...)
- 72deluxe 10y ago
  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.
  - jayd16 10y ago
    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.
  - oblio 10y ago
    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-debug-and-release-build-mode-like-c 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-mojo.html https://maven.apache.org/plugins/maven-source-plugin/jar-moj... b. configuration files -> Maven: https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html 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 :)
  - winstonewert 10y ago
    > 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?
72deluxe 10y ago
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.
- nostrademons 10y ago
  Usually if you're distributing a Makefile with a project, it's for portability. Insisting that your Linux users of a C/C++ library install Visual Studio or Xcode is a complete non-starter. It's different at a company - every company I've been at had its own proprietary wrapper around make - but then you need to be able to integrate all the open source libs you're depending on. At least there's autotools, which has its own set of problems, but you can be reasonably confident it'll generate a portable Makefile.
joezydeco 10y ago
I'm a fan of qmake for my projects, even the ones that don't use Qt. Are there any other make systems that have Project Mode like qmake does?

by Merad 10y ago

vvanders 10y ago

The solution is good tooling, Visual Studio makes this a non-issue with sane defaults that can be extended if needed. I haven't tried CLion yet but I would assume it's decent given JetBrain's track record.

realharo 10y ago

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 work differently with libraries that require different linker flags and include directories and...)

72deluxe 10y ago
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.
- jayd16 10y ago
  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.
- oblio 10y ago
  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-debug-and-release-build-mode-like-c 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-mojo.html https://maven.apache.org/plugins/maven-source-plugin/jar-moj... b. configuration files -> Maven: https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html 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 :)
- winstonewert 10y ago
  > 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?

72deluxe 10y ago

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.

nostrademons 10y ago
Usually if you're distributing a Makefile with a project, it's for portability. Insisting that your Linux users of a C/C++ library install Visual Studio or Xcode is a complete non-starter. It's different at a company - every company I've been at had its own proprietary wrapper around make - but then you need to be able to integrate all the open source libs you're depending on. At least there's autotools, which has its own set of problems, but you can be reasonably confident it'll generate a portable Makefile.

joezydeco 10y ago

I'm a fan of qmake for my projects, even the ones that don't use Qt. Are there any other make systems that have Project Mode like qmake does?