Tweaking Waf for integration with Eclipse CDT

First, the way not taken: there is an official Waf extra named "eclipse.py" which theoretically creates the files that Eclipse expects in a project. But that extra is from 2011; both Waf and Eclipse have evolved since then, and I didn't have the time nor inclination to dig into both Waf and Eclipse internals. Also, what would be the end result of that extra: only build support, or full indexing? No docs, no idea, forget it.

So let's make it easier. We already know that Eclipse's indexing system only needs to see the compiler command lines to get an idea of what files are related, where are the includes, what are the compiler flags, etc. So what about just making Waf spit out the command lines? And turns out, it's even easy: there is another extra called "print_commands" which does just that.

(A sidenote: waf extras in general are unsupported, undocumented and might break or disappear, but looks like the Samba project – meaning, a big and important project – does use the print_commands extra as of 2015 with Waf 1.8, with collaboration from the very Waf maintainer. So I don't expect it to break soon.)

What to do then to have Waf list the lines? We need a Waf which includes the print_commands extra. If yours doesn't include it, you can create a new one easily. Follow the normal Waf creation instructions, just add the extra to the waf-light call:
python waf-light --tools=compat15,print_commands

(I just left compat15 in there because it was the most straightforward way)

Now, substitute your Waf file for the freshly created one.

Then add a ctx.load('print_commands') to your wscript's def configure(ctx).

And that's it. Now when you run waf build -v, what previously was shown as a python list of tokens making up the command line, now will be a plain old command line that Eclipse can understand.

1 comment

  1. Well, actually since waf adds a prefix to its verbose output, Eclipse's build output parser needs to be configured for that. IIRC, adding ".*" to the regexp just before the compiler's name is enough.

    You should already have that in place anyway to get rid of the possible compiler path...