draw call graph for C source codes using cppDepend - c

I have a problem with using cppDepend tool. I have a source code which is written in C language and I need to draw Its dependency or call graph. cppDepend's compiler's source code extension is set to c;cpp;cxx;cc but when I want to open source codes in C, the file chooser box only let me to choose source codes in C++.
What should I do????

In Linux? Why don't you use other options? Hast to be cppDepend? Look at cflow, callgrind (my favorite), or even gperf (which outputs a callgraph in graph form!)

Related

How can I get a `Makeheaders` binary for Windows?

I'm tired of seperately having to generate a declaration in the header file for most of the functions I'm defining in my C file. Hence, I would like to automatize this.
I've found an ideal application for this: Makeheaders
Unfortunately only the sources seem to be available, no readymade binary.
Documentation: https://www.fossil-scm.org/xfer/doc/trunk/src/makeheaders.html
Code: https://code.launchpad.net/~lockal/makeheaders/head
Does someone know where to get a binary? Would it be hard to somehow build it myself?
You can download the source code from here. It is a single makeheaders.c file.
then you just need to call cl.exe makeheaders.c it will generate a makeheaders.exe that you can use.

How to avoid having to reference an external XML file?

I am writing an app in C and using Glade3 to make the GUI (and GTK builder).
Glade 3 doesn't allow C code generation anymore (which I understand the reasons for), but now all applications need to have the XML file hanging around the compiled app like an annoying .dll file. Does anyone have any knowledge of project to create C code for it, or how to embed the XML file in the code itself? I imagine this could be done, but it would be a pain I bet.
What you probably want is:
gtk_builder_new_from_string(const gchar *string, gssize length);
https://developer.gnome.org/gtk3/3.10/GtkBuilder.html#gtk-builder-new-from-string
Just stringify the glade3 xml file (in GtkBuilder format) and include it as a string.
It is still possible to use glade-2.12 to generate gtk2 code and then port it to gtk3; however if you are going to do that it may be worth it to simply modify that version of glade to output the gtk3 syntax directly.

Programmatically capture X11 region with ffmpeg in C/whatever

There is an input format option to ffmpeg -- x11grab which allows one to capture specified region and output it to file/stream. I'm trying to do the same thing programmatically, but i haven't found any non-basic tutorials/reference for ffmpeg API.
I wonder, how it is possible to open x11 region with avformat_input_file or something like this. Or should i do it with XCopyArea/etc?
(Any programming language will satisfy)
There are many applications that take a screenshot. Major hint: it's open source, use the source. If you can't find the code in ffmpeg, any example application will do:
http://git.gnome.org/browse/gnome-screenshot/tree/src/screenshot-utils.c#n425
This is gnome-screenshot source code. This example uses gdk_get_default_root_window().

How are C "spec" files like this created?

How do I create foo.spec files like this one from a C header file?
i.e. I'm looking for an automated way to convert all of a header file's declarations into something simple like:
stdcall CreateFileW(wstr long long ptr long long long)
which I can easily use to perform operations later.
I realize it might not be possible for some types, but it should be possible in a large number of cases.
How do I do this?
Ok, there is the tool likely used in wine project: http://www.winehq.org/docs/winedump
Intro:
winedump is a Wine tool which aims to help:
A: Reimplementing a Win32 DLL for use within Wine, or
B: Compiling a Win32 application with Winelib that uses x86 DLLs
For both tasks in order to be able to link to the Win functions some
glue code is needed. This 'glue' comes in the form of a .spec file.
The .spec file, along with some dummy code, is used to create a
Wine .so corresponding to the Windows DLL. The winebuild program
can then resolve calls made to DLL functions.
Creating a .spec file is a labour intensive task during which it is
easy to make a mistake. The idea of winedump is to automate this task
and create the majority of the support code needed for your DLL. In
addition you can have winedump create code to help you re-implement a
DLL
Spec generation mode:
Spec mode:
<dll> Use dll for input file and generate implementation code.
....
Files output in spec mode for foo.dll:
foo.spec
This is the .spec file.
foo_dll.h
foo_main.c
These are the source code files containing the minimum set
of code to build a stub DLL. The C file contains one
function, FOO_Init, which does nothing (but must be
present).
Makefile.in
This is a template for 'configure' to produce a makefile. It
is designed for a DLL that will be inserted into the Wine
source tree.
So, winedump will dump DLL interface to SPEC file. The Spec file can be additionaly edited by hand.
And the spec describes real DLL interface, not a high-level language interface (like it is encoded in .h headers). So, you can compile your code (.h and .c and maybe something like .def to fix DLL function numbers) on win32 to DLL as usual and then dump the spec from DLL.

Graph of included files

When I work on someone else's code, I tipically need to abuse of grep in order to find data types declarations etc, and this usually makes me confused.
I'd like to have some tool which analyzes the source code and produces some graphviz-like drawing and allows me to follow dependencies.
Also I've found this on the internet, but I think is taylored for the linux kernel only.
Have you tried doxygen?
Doxygen can produce dot files, and you can build the documentation without changing the source code with the right options set in the Doxyfile.
Do you use an editor that can take advantage of tags ? In Emacs, I just type M-. to go to the definition of a symbol, and M-* to go back to where I was once I have read it. This also enables the command tags-search to grep among the files of the software project (very convenient if they are in multiple directories).

Resources