Slashdot Mirror

← Back to Stories (view on slashdot.org)

Arranging Multi-Language Source Code Trees?

Posted by Cliff on from the laying-it-all-out-sensibly dept.

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."

5 of 8 comments (clear)

  1. Organize by function, not language! by Manax · · Score: 2, Interesting
    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.

    --
    "Why should I be content to simply live in this world, when I, as a human being, can CREATE it?" - Oertel
    1. Re:Organize by function, not language! by Twylite · · 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:

      • 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.

      --
      i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
    2. Re:Organize by function, not language! by Ayende+Rahien · · Score: 2

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

      You would use hardlinks...

      --

      --
      Two witches watched two watches.
      Which witch watched which watch?
  2. why not.. by ameoba · · Score: 2

    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?

    --
    my sig's at the bottom of the page.
    1. Re:why not.. by Rentar · · Score: 2

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