Reasons for separate source and generated trees

Question

What are the reasons for putting the generated files in a tree parallel to the source trees? For example, in Eclipse I usually choose to put the sources to .../src and the compiler generated files in .../classes. Mixing both in a single tree looks dirty to me, however I can't find any advantage in the separation:

• Theoretically, I could backup the sources more easily, but that's not true. I'm using git and ignoring all *.class files everywhere is just trivial. With other version control systems it should be very easy, too.
• Theoretically, it helps to find a given source file faster as the tree is not polluted by the class files. Actually, I seldom need it (the IDE offers much faster ways). For looking at the classes I'm using the Class View, which abstracts from the directory structure.
• Theoretically, there may be tools requiring that, but I'm not aware of any.

There's two disadvantages of the separation:

• The IDE copies all non-java files ("resources") from the source tree to the generated one. If the IDE doesn't notice a changed resource, then there's an old version on the classpath (i.e., in the generated tree) and I'll find myself running a program working with the old version... this may cost me quite a lot of time.
• Once upon a time, I need to find the class-file corresponding with a given java-file (or vice versa), which takes quite a lot of time.

So what are the real advantages of the separation?

This question is not Java (Eclipse) specific. However, in Java the problem of navigating to a parallel tree is aggravated by the fact that the trees tend to be very deep (because of the directory structure mirroring the package structure and because of the world-wide package naming convention).

Answer 1

It's easier to package for deployment and easier to make a clean build, but mostly I think it's just because source and class files are two different things.

Also, if you think java class files are hard to find, you should try a language that doesn't enforce such a directory hierarchy sometime :-)

Answer 2

It keeps things simple

Typically you want to separate your derived resources from your source. Compiled code (.class) is clearly derived, source driven documentation (Javadocs) falls under this category, and so does code metrics, unit test results, automatic site generation and on and on.

All of these derived resources contribute in some way to the final artifact (your application) but are certainly not source code. Consequently, mixing these derived resources into your source tree is kind of weird. Sure, you can filter them out, but why bother? Why not simply have a separate place to put them which you can clean out with a simple directory delete and have total certainty that nothing has been missed.

And thus the /target (or /build or whatever) directory is born.

Answer 3

I rely on grep & friends a lot to answer questions about the sources of a project, and with co-located binaries you always have to exclude them (bothersome) or ignore the spurious matches in them (also bothersome, and inefficient to boot).

• Frits: You should take a look at ack as a replacement for many common grep tasks. It's recursive by default and automatically ignores non-source files, VCS directories, backup files, etc. (It also produces nicer output, IMHO)