-1

With Haskell I can "ghc --make Main.hs" and with Ada I can just "gnatmake Main.adb" and that is it.

Isn't there anything like that for C++? Why not?

I do not want to write buildscripts nor makefiles for C++ projects. I have those damn #include lines there. Why isn't that information enough?

note: I vaguely remember a feature like that mentioned once in the context of Clang.

update:

It seems possible to have a C++ compiler (or write a wrapper script), that recursively looks for included headers and expects either sourcefile or objectfile to be in the same dir; compiles and links everything automatically. Skipping if source and object file have same timestamp. Link-time-decisions are left as a special case necessiating a compiler-flag/switch to select one from multiple source/object-files for the single header, or specify dynamic linking. E.g.: awesomecompiler Main.cpp --link-choice=DrawStuff.h-->DrawStuffGL.o.

Hence there must be another reason for using make or its alternatives. What is it?

To rephrase the question as suggested by martin: Why can't we just get all the build-information from the header files, and a few commandline flags for special cases?

rebrfbsj
  • 3
  • 2
  • [Damn includes...](http://stackoverflow.com/questions/333889/why-have-header-files-and-cpp-files-in-c?rq=1) : What information is enough for what ? What do you want to do ? – quantdev Aug 13 '14 at 07:24
  • You want to get all the build information needed to compile (and link) just from the header files, is that your question? – martin Aug 13 '14 at 07:25
  • 1
    C++ is a language, not a system. Haskell and Ada may take a different approach and offer something more integrated. – Kerrek SB Aug 13 '14 at 07:31
  • You can build a single C++ file just by passing it as a parameter to the compiler. It will locate all included header files; you don't need to explicitly specify those. However, if you want to build *multiple* C++ files, you need to specify those somehow, since you *never* include C++ source files. So it is not clear what the question is. – Cody Gray - on strike Aug 13 '14 at 08:18
  • @martin: Well not personally. I just expect a compiler to figure that out, since what I enter into makefiles, typically mirrors the includes. But yes, you can formulate my question like that. – rebrfbsj Aug 13 '14 at 17:00

1 Answers1

0

Some languages have a system whereby the "main" file is specifying everything else that makes up that program as "modules" or some such. Ada certainly does, I don't know enough Haskell to comment there.

C and C++ rely on modules being compiled separately and linked at the end, and the software developer decides exactly what the process is here. This has some advantages, such as that you can build a module for one solution, and a different module for another solution. This is not possible if all modules are specified by the source file (you then have to make the files appear/disappear in the filesystem instead, which of course means some other "work outside the compiler", so you end up with a makefile or some such anyway).

Say for example, we make a game, and we encapsulate all the drawing, then we can choose whether we use DirectX9, DirectX10, OpenGL or OpenGLES by simply linking with the relevant "DrawStuffDX9.o" or "DrawStuffGL.o" etc.

As always, freedom means more choice, but also a bit more work. Just like buying a ready made piece of furniture is simple, but if you want it to fit exactly to your house, floor to ceiling, you have to be lucky. A bespoke piece of furniture will cost more and require some detailed measurements, but will be a perfect fit for your home.

[gcc -MM somefile(s) will give you a rudimentary makefile for the source file(s) you specified].

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • Thanks for the answer. I accept the technical facts. – rebrfbsj Aug 13 '14 at 16:51
  • But it seems possible, to have a C++ compiler, whith a default convention, by which it recursively looks for included headers and expects sourcefiles to be in the same dir, and compiles and links everything recursively/automatically. Skipping if source and object file have same timestamp. And link-time-decision, which is relatively rare, is left as a special case that necessiates a compiler-flag/switch to select one from multiple sourcefiles for the single header (e.g.: awesomecompiler Main.cpp --link-choice=DrawStuff.h-->DrawStuffGL.cpp). – rebrfbsj Aug 13 '14 at 16:55
  • Are link-time choices so common that such a compiler(feature) is not desired by most programmers? Or are there some reasons making such not feasible/practical? – rebrfbsj Aug 13 '14 at 16:56
  • In a non-trivial project, you will need to have a makefile (or equivalent build instructions) *anyway*, @rebrfbsj, so there is just little point in having a feature that tries to deduce these things automatically. It would only be useful in toy projects, and in most cases, those can be written as a single module. Aside from that, it is rather naïve to assume that headers will have identically-named source files. That assumption would be wrong as often as it is correct. – Cody Gray - on strike Aug 13 '14 at 23:18
  • @CodyGray: The reason for "you will need to have a makefile anyway" is eactly what I am curious about. What is it? Surely not just the differently named source files. – rebrfbsj Aug 14 '14 at 06:10
  • C++ was derived from C. C doesn't have a strict relationship between headers and source files - yes, there is often a x.h and x.c file. But like has been explained, for any non-trivial project, there are probably OTHER steps, such as external data files, various other components (other source files that build to an executable), and so on, so you STILL need to build several different things, and thus need some sort of "project description". But ultimately, it's "a choice by the designers of the language" - we can't change it now. – Mats Petersson Aug 14 '14 at 07:36