Arranging Multi-Language Source Code Trees? 8
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."
Organize by function, not language! (Score:2, Interesting)
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! (Score:1)
Re:Organize by function, not language! (Score:1)
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! (Score:2)
You would use hardlinks...
Re:Organize by function, not language! (Score:2)
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:
Main application make files
Utility application one section
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.
why not.. (Score:2)
Re:why not.. (Score:2)
Group source by build target (Score:1)
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.