The GNOME OPW for Summer 2012 is approaching to the end. By working with the code of GUPnP through the internship, I have learned a lot about C programming with GLib/GObject. I think it is a great time to share some from what I learned to everyone, especially the beginners.
Here I collect five small suggestions focusing on coding:
-
Avoid the trailing white space in your code and patch. Set your editor to be aware of the unnecessary white spaces at the end of line. Git doesn’t like them nor your mentor. If you use Vim, you can look at this page.
-
Use
--enable-shared=noduring theconfigurephase to disable the build of shared library. This makes the test programs undertestsdirectory statically linked to the target library. Otherwise the test programs will be Bash wrapper scripts. Doing so make it easier when you usegdbto load the test programs. -
Use
CFLAGS=-gin theconfigurephase to generate the debugging info. Even though you may findconfigure --helpshows you an option called--enable-debug, it basically will convert to-g -O3forgcc. This-O3will optimize your code and make it hard to track the execution ingdb. -
Combine your local commits into a single patch. After finishing a specific feature or fixing a particular bug, you may have many local commits in your Git commit tree. You may also have merges from the upstream repository. I find this link is extremely helpful to form a single patch from the mess.
-
Use DevHelp. Even though you might prefer to the online documentation, you should give DevHelp a try. It is more convenient and faster. It can only show the documentation you are interested.
All right. That is it. Hopefully you will find them helpful.
Orchid Garden 
Thanks for the tips ! Especially –enable-shared=no.
2 is wrong, to debug an in-build-tree binary that links to a shared library you do:
libtool –mode=execute gdb test/the-binary
In fact, i have a shell alias like:
alias lgdb=’libtool –mode=execute gdb’
then i can just
lgdb test/the-binary
Using shared linking is just a pain.
Eh, i mean using *static* linking is just a pain
(2) Don’t use static linking, but create a wrapper script or an alias in bash named lgdb that just runs libtool –execute $@
(3) My CFLAGS are “-g -O0 -fno-inline -fno-omit-frame-pointer”
-O0 turns off all optimizations (in particular code reordering)
-fno-inline does not inline functions, which means gdb will always give a proper stack trace
-fno-omit-frame-pointer helps older profiling tools (most notably sysprof) generating stack traces.
(5) I stopped using devhelp for online documentation for one single reason: I can link to online docs in chat discussions. Oh, and the fact that Google Search (with site:developer.gnome.org) is better than devhelp helps, too (It finds typos, for example).
Combine your local commits into a single patch
Please don’t. Use git rebase -i and split your commits in logical steps that are easier to review.
Regarding #2, there’s an easy way around (without requiring static linking), IIRC:
$ libtool –mode=execute gdb test/mytest
(Learned that one on #gnome-hackers back in the days…)
About 2: libtool has means to cope with that:
libtool –mode=execute gdb ./test-program
As for the 4th tip… have you tried git rebase -i HEAD~5 ? It allows you to reorder, remove, merge, split, amend, the last 5 commits in an interactive way (it loads your $EDITOR and allows you to play with the commits).
You should try it, it’s way faster and more powerful (but be aware of more powerful is also more risky if you delete a line you didn’t want to, for that look at git reflog 😉
Great tips!!
Hey, this is really useful info!
One thing, though – you don’t need to force static linking to be able to debug the tests. Instead, you can run:
libtool exec gdb mytest
and it will run gdb on the real binary, which is the same as doing:
gdb .libs/lt-mytest
Using –enable-shared=no isn’t very pretty. If you want to debug a prorgam that is hiding behind a libtool wrapper, you can just use: libtool –mode=execute gdb path/to/libtool_wrapped_program
Hello,
some additional suggestions:
“Use –enable-shared=no during the configure phase to disable the build of shared library.”
It’s not really necessary; some configure scripts even disable this option nowadays. Instead, I prefer to:
* create an alias, for instance: alias lgdb=”libtool –mode=execute gdb –args”. You can add it to your ~/.bashrc or ~/.bash_aliases file.
* now you can just invoke: “lgdb progname arguments”.
http://www.gnu.org/software/libtool/manual/html_node/Debugging-executables.html
“Use CFLAGS=-g in the configure phase to generate the debugging info.”
It’s better to specify CFLAGS=”-g3 -O0″. “-g3” will enable additional debug information, for instance to expand macros in the debugger. And “-O0” will make sure to override any previous instance of “-Osomething” in the command line — sometimes “-O3” is added automatically because of the Makefile.
Keep up the good work!
Eeek. #2 is not really a good idea, because if you’re working on say glib, it will break your ability to install the shared libraries and use them to test *other* things.
To run gdb on an uninstalled test program:
$ libtool –mode=execute gdb –args ./testprogram –some-test-args
Agreed. =)