I have a burning need to learn GTK development. I have a little dialog based app that needs to run on Windows, Linux, and Solaris. I have the Windows version done using MinGW's support for win32 programming (now there is an experience for you). Now I need to implement the same thing in GTK for Linux and Solaris.
So I'm going through the GTK 2.0 tutorial on the GTK web site and the first thing it get's me to type in is:
#include <gtk/gtk.h>
The first thing the CDT does is throw up a warning marker on the line complaining that the CDT indexer couldn't find that include file. Being suspicious, I did a build and sure enough the header file wasn't found. With all the great work the indexer team is doing I really should trust what it's telling me.
So I fired up the Ubuntu package manager and found out that the GTK devel package is indeed installed. What's up?
Then I remembered one of the new CDT features I stumbled across in my 5.0 testing that we really should tell people about more. I went back to the #include statement and after <gtk, I pressed Alt-/ (I use the emacs key bindings, Ctrl-Space for the rest of you). And sure enough, content assist offered me all the include files and dirs that being with 'gtk', including the one I needed, gtk-2.0.
It's just a little thing, but one of the great examples of the information that the CDT can gather for you to help improve your productivity. And it's time to tell people about it...
great tip ^^
ReplyDeleteIf you start a wiki page about with more tips like this, please tell us.
This happened because Gtk on *nix use pkg-config to add the correct include paths to gcc when compiling. You probably noticed that the initial path you entered (gtk/gtk.h) was at the end of the "correct" one (probably gtk-2.0/gtk/gtk.h). Gtk recommends using the first one for portability reasons, so its up to pkg-config/autotools to find out where the "gtk/gtk.h" part is. BTW, i've been using CDT for some time for gtk development and (apart from this "portability" problem) it works like a charm when indexing and showing completions. Just a suggestion: add pkg-config support to the autotools integration in CDT (if ever done), and you'll have the most feature complete OSS C/C++ IDE on Linux that I know of.
ReplyDeleteI was waiting for someone to point that out. Of course as soon as I got to the compile step of the tutorial, I was reminded of pkg-config. So I switched over to a Makefile project and hooked it up to spit out the includes at build time so that it got picked up by the scanner discovery.
ReplyDeleteI'd like to get this kind of support into managed make. This is part of the extensibility we're missing and need to consider it in 5.1.
Could you share with us that "hooked it up to spit out the includes at build time so that it got picked up by the scanner discovery" part? I've managed to solve that problem by manually adding the folders (i.e. pkg-config --cflags output) to project properties (either makefile or managed makefile). I really would like to know how to do it automatically. Maybe a Wiki article?
ReplyDeleteSure I just did:
ReplyDeleteCXXFLAGS = $(shell pkg-config --cflags gtk+-2.0)
Simply seting it to `pkg-config ...` doesn't work since Make passes it as is to the command line. $(shell) makes sure it runs first and then gets sent out so we can see what the result was, especially what the -I's are.
Hmm, so that's how scanner discovery works... That´ll make things a lot easier to me (and convice some of my friends to use CDT too!). Maybe I'm just stupid but I couldn't find any docs on that. Thanks for the hint.
ReplyDeleteHello, i have a question concerning how cdt can manage the following situation. I have inherited with a bunch of code doing:
ReplyDelete#include ‹cstdlib›
omitting the .hpp extension. BTW cdt says "unresolved inclusion". Is there a way to bypass this (except adding .hpp at the end of all my include, because of course I have thousand of this). Sorry for the bad trick...