6 ms·

Production compilers often don't have it either. (Having to split up your code manually into separate .cpp [or what have you] files doesn't qualify as incremen

Production compilers often don't have it either. (Having to split up your code manually into separate .cpp [or what have you] files doesn't qualify as incremental compilation—that's just separate compilation. Incremental compilation is when the compiler automatically figures out what needs to be recompiled, even when all you hand it is a big blob of code that hasn't been manually split up by a human in any way.)

taneq 10y ago
If you have a single source file that's big enough for the compiler to bog down on it, then either that compiler is beyond ridiculously slow, or you need to refactor.
- pcwalton 10y ago
  The tricky part is the dependencies between files. This is what C++ uses header files for, but Rust doesn't have those.
  - skybrian 10y ago
    Languages like Go and Java can do separate compilation by reading header information out of the object files of imported packages/classes.
    - pcwalton 10y ago
      Rust has been doing that since day one. What makes this incremental compilation different from that of, say, Go, is that it works inside a package. Before incremental compilation, Rust and Go had the exact same model: package-at-a-time compilation. With incremental compilation, Rust is more fine-grained than that: Rust can compile specific parts of a package while leaving the other parts untouched.
pjmlp 10y ago
Lucid C++ was already doing incremental compilation at function level for 1993 thanks their pivoting from Lisp machines. If I recall correctly they demo it on this video https://www.youtube.com/watch?v=pQQTScuApWk https://www.youtube.com/watch?v=pQQTScuApWk Also IBM had a C++ compiler version for OS/2 based on their Visual Age for... stack that used an image store for code, offering a Smalltalk like editing experience for C++, but it was quite resource heavy for early 90's machines. It had something to do with their CSet++ offering.
barrkel 10y ago
The Delphi compiler has incremental compilation, but by your definition it wouldn't. Delphi uses the source to figure out dependencies. That is, the compiler has make logic, and traces through the 'uses' declarations to recursively discover all the source and object files. It compares timestamps to discover which object files are out of date and need to be recompiled. Thus, if you touch a single file and do a compile, only a couple of files will be compiled - the main program source and the modified file. This dependency logic is in the compiler, not a separate make program. If this isn't the compiler doing incremental compilation, I think we have a terminology problem. Because this is what is meant by incremental compilation as the term is applied to almost all production compilers, and if you persist in making a distinction, you may be confusing more than clarifying. ISTM that you're memoizing more parts of the compilation process than has historically been done in incremental compilers. It may be clearer to use a more qualified phrase to express this, rather than shift the generally accepted meaning of a term.
- Manishearth 10y ago
  I don't see where in pcwalton's comment he alludes that the Delphi compiler's definition of incremental compilation doesn't match his own. He explicitly says "Incremental compilation is when the compiler automatically figures out what needs to be recompiled". (He does say that production compilers don't have incremental compilation, but that's not a matter of definition, and I read that to mean "usually don't")
  - coldtea 10y ago
    >He explicitly says "Incremental compilation is when the compiler automatically figures out what needs to be recompiled". He also says that merely using the separate files to deduce this (which the parent says is what Delphi does) is not incremental compilation.
    - Manishearth 10y ago
      It doesn't "merely use the separate files", it traverses the use statements. There's no manual splitting of .cpp and .h files. No manual management of dependencies.
pjc50 10y ago
Ironically C++ often goes in the other direction: splitting up files causes all of them to rebuilt as soon as you touch a header, but combining them into a huge file gives you a huge speedup in compilation.

taneq 10y ago

If you have a single source file that's big enough for the compiler to bog down on it, then either that compiler is beyond ridiculously slow, or you need to refactor.

pcwalton 10y ago
The tricky part is the dependencies between files. This is what C++ uses header files for, but Rust doesn't have those.
- skybrian 10y ago
  Languages like Go and Java can do separate compilation by reading header information out of the object files of imported packages/classes.
  - pcwalton 10y ago
    Rust has been doing that since day one. What makes this incremental compilation different from that of, say, Go, is that it works inside a package. Before incremental compilation, Rust and Go had the exact same model: package-at-a-time compilation. With incremental compilation, Rust is more fine-grained than that: Rust can compile specific parts of a package while leaving the other parts untouched.

pjmlp 10y ago

Lucid C++ was already doing incremental compilation at function level for 1993 thanks their pivoting from Lisp machines. If I recall correctly they demo it on this video https://www.youtube.com/watch?v=pQQTScuApWk https://www.youtube.com/watch?v=pQQTScuApWk Also IBM had a C++ compiler version for OS/2 based on their Visual Age for... stack that used an image store for code, offering a Smalltalk like editing experience for C++, but it was quite resource heavy for early 90's machines. It had something to do with their CSet++ offering.

barrkel 10y ago

The Delphi compiler has incremental compilation, but by your definition it wouldn't. Delphi uses the source to figure out dependencies. That is, the compiler has make logic, and traces through the 'uses' declarations to recursively discover all the source and object files. It compares timestamps to discover which object files are out of date and need to be recompiled. Thus, if you touch a single file and do a compile, only a couple of files will be compiled - the main program source and the modified file. This dependency logic is in the compiler, not a separate make program. If this isn't the compiler doing incremental compilation, I think we have a terminology problem. Because this is what is meant by incremental compilation as the term is applied to almost all production compilers, and if you persist in making a distinction, you may be confusing more than clarifying. ISTM that you're memoizing more parts of the compilation process than has historically been done in incremental compilers. It may be clearer to use a more qualified phrase to express this, rather than shift the generally accepted meaning of a term.

Manishearth 10y ago
I don't see where in pcwalton's comment he alludes that the Delphi compiler's definition of incremental compilation doesn't match his own. He explicitly says "Incremental compilation is when the compiler automatically figures out what needs to be recompiled". (He does say that production compilers don't have incremental compilation, but that's not a matter of definition, and I read that to mean "usually don't")
- coldtea 10y ago
  >He explicitly says "Incremental compilation is when the compiler automatically figures out what needs to be recompiled". He also says that merely using the separate files to deduce this (which the parent says is what Delphi does) is not incremental compilation.
  - Manishearth 10y ago
    It doesn't "merely use the separate files", it traverses the use statements. There's no manual splitting of .cpp and .h files. No manual management of dependencies.

pjc50 10y ago

Ironically C++ often goes in the other direction: splitting up files causes all of them to rebuilt as soon as you touch a header, but combining them into a huge file gives you a huge speedup in compilation.