Friday, November 23, 2007

Using Linux-like Directories in Windows

Being a linux user at home and using it at my previous work place for some years left a mark in me that carried away to other OS (in this case, MS Windows). One of them are directory structure and naming, the goold-old bin, doc, man etc. I've used to looking for documentation of libraries and applications on the same dir e.g: /usr/local/share/doc, having an executable in one dedicated place (the mighty /bin directory) and so on. Having files collected by the function is quite intuitive in most cases.

I can't do too much to replicate those in MS Windows since it has it's own convention in doing things. However, some "hack" based on the principle above still useful and makes things easier. Here's what I do :

  • Put documentation together in doc dir, especially for libraries. Even when they are installed by default in their own dir, I would copy them under it. This make searching for something like an API doc very convinient, especially in a development that use several libraries at a time.
  • Put command-line based tools under bin dir and put this dir on PATH environment variable. It makes PATH variable less cluttered and you have your tools accessible wherever directory you are currently in. I puts tools like ctags, cscopy, sort, custom scripts and sytem hacks here.
  • Put libraries outside work source tree, use a dedicated lib dir. Despite their source, how they are used and accessed, I put libraries used in development in one single dir. I find this practice easier for me to just take a glance and in an instant I saw all libraries that I used (or used to used/tried). It's also make the working dir of active code cleaner and give me more clarity. I don't find any urgency to "localize" library within working directory of actively-worked code so far and find this setup to be better.
I find it useful to have more exposure to other way of doing things. It gives us insights and useful tricks to be used in other context which we won't get otherwise.

No comments: