Getting to "yes" in a world of "no"…

The Eclipse IDE – if you use it (as I do), you probably love it (as I do). But occasionally you’ll run into stupid, historic things that Eclipse does that are broken and have hung around in that state for years.

workspace_loc and project_loc are exactly two such things: these have been known to be broken since at least 2002 (and heaven only knows how long they had already been broken by then).

What you’re supposed to be able to do is to use these to define path variables relative to your workspace or project, so that you can move projects around and rename them nicely. For example, if your workspace and project were C:\MyWorkspace and MyProject (*sigh*), ${workspace_loc} is supposed to return “C:\MyWorkspace”, while ${project_loc} is supposed to return “C:\MyWorkspace\MyProject”. There’s also some slash-themed trickery whereby (I think) you can automatically swap slash directions to match your operating system: e.g. ${project_loc:/include} should get mapped to “C:\MyWorkspace\MyProject\include” in a Windows box etc.

The problem is that… none of this works at all. Or rather, it seems that this mechanism used to work on the “Navigator and Package Explorer perspectives” (I saw claimed in an ancient comment online, though I’m not even sure it works there any more) but not anywhere else.

So, if you try (as I recently did) to use ${project_loc} to set up a project-independent include path in Eclipse (which you’d have thought would be a completely sensible idea), you can’t. It doesn’t work.

I do have a workaround, but note that this only works for me because all my source library subtrees happened to be exactly one directory level down from the main project directory. It’s a bit old-fashioned, but all I did was replace…
* “${workspace_loc:library1/include}”
* “${workspace_loc:library2/include}”
…with…
* ../library1/include
* ../library2/include

If this trick works for you, feel free to shower my board with virtual gold coins, Frank Marshall-style. 🙂