Arranging Multi-Language Source Code Trees?

jodonn queries: "Often software developers are called upon to write code in multiple languages for a single project. For instance, I've had to write Java applications with C hooks into legacy native applications and batch processes primarily in C++ with some additional code in Perl, and of course I have to support the build process for all these things, often across platforms using Make and Ant. I'd like to hear some tips about best practices when laying out the source code hierarchy for situations like these, with an eye toward ease in compiling and deployment."

Comments

Organize by function, not language!

[Manax]

Gah, I HATE it when projects I've worked on store their code based on language... perl in one directory, C++ in another, SQL in another... or all top-level code in one directory (regardless of use) and all 'function-files' in another directory...

In general, I'd suggest basing the heirarchy on functionality.... something along the lines of "node_type/functional_area/process/{main|libs}/*". Sure, there are difficulties with that too, but symbolic links are a good thing! ;)

Although a bad tree is difficult, the most painful thing I've encountered is how the 'product' is released. That you need to specify that up front, that everything is built in it's own dir, but installs itself into a "release" area, that can be tarred up/archived/copied as necessary. To be fair, it depends a lot on your product, but I hate it when there isn't a release process, you just have to know the files, and where to copy them... bleck.

babble... babble.

Re:Organize by function, not language!

[lmenke]

I have to agree; the functionality is the most logical sorting method. Otherwise you will be duplicating a lot of structures. Besides, are you tying to save work for the compilers or your self? All the compiler needs is the correct file extension and a general direction of where the file is stored. Lorenz H. Menke, Jr.

Re:Organize by function, not language!

[megalomaniacs4u]

You ever heard of symbolic links?

This sounds like a nice way to have both structures.

Sorting by functionality and organisation is essential. But being able to find all the perl/C(++)/java/SQL files is also necessary.

Of course if you are on a MS platform...

Still SourceSafe sort of works...

Re:Organize by function, not language!

[Twylite]

Typically the various languages separate programs and utilities, and therefore function. But a logical grouping takes off of these into account.

Look no further than Freshmeat. Projects are classified and categorised. At some point you get to the source code for a particular project (as a tarball), at which point you are considering a single project.

Follow the same hierarchy for a project which has subprojects:

• Complete project repository
• Main application section
  Main application make files
  
  • docs
  • source
  • java
  • c++

Utility application one section

• source
  • perl

Utility application two section

and so on...

Your source tree needs to have no resemblance to the final product. What is important is logical separation and navigation of source. That is why you should keep the applications separate at the top. Then keep the languages separate: even when it comes to JNI the languages don't work together, but cooperate across an interface. Even your code for a single language should be broken into directories according to its logical units (any cohesive library or application with a defined interface).

Your make process can ensure that all the sources are properly colated (either implicitly or explicitly by copying or using symlinks) and build into whatever form you want.

Re:Organize by function, not language!

[Ayende Rahien]

> Of course if you are on a MS platform...

You would use hardlinks...

why not..

[ameoba]

Why not just place all your source in a single directory, and instead of worrying about makefiles, get an intern to take care of all your compilation?

Re:why not..

[Rentar]

'Cause a Makefile will at least make the errors reproduceable. Try to teach that to an intern.

Group source by build target

[Andrew Wiles]

You should group source code by build target.

E.g. For the Java/C application, the C code generally builds to a dynamic library (a DLL or .so), while the Java code probably builds to a .jar file or such. These are nicely independent build targets, so they should be in separate directories.

Hopefully your project is well architected at a high level, and each of the build targets is semi-autonomous. Every directory should contain a chunk of code that can be tested semi-independently. If your project doesn't work this way, you need to refactor.