I have two C source files. A comment to a function bar()in file A needs to refer to a function foo() in file B. How can I make this link?
I tried:
Writing something like: B.c::foo() hoping that doxygen would go to file B and find function foo there.
Also tried simply ::foo() but that did not help.
Then I tried giving file B.c a special tagname as in doing //! #file specialtag on first line of B.c and then doing specialtag::foo() in my comment but not much has changed.
I tried to force the link with \ref and \link but even that did not help.
The //! #file line is present in both A.c and B.c so doxygen should be aware of the code.
EDIT
I tried what #doxygen suggested but with no luck. I made an example project to show where I am running into problems, its here: http://www.filedropper.com/testdoxygen2tar
I used the default setup file, made with doxygen -g.
The output I am getting:
You can see that the foobar function is not being linked to.
EDIT 2
Found the problem. Function foo was undocumented and so no page for it was generated, so of course doxygen had no page to link to. (I was generating documentation with the SOURCE_BROWSER option enabled and hoping that a link to function definition would be generated)
This is pretty straightforward. Here's a minimal example that works with a default configuration file (doxygen -g):
First create file foo.c with the following contents:
/** #file */
/** Function foo, see also bar(). */
void foo()
{
}
then create file bar.c with the following contents:
/** #file */
/** Function bar, see also foo(). */
void bar()
{
}
Run doxygen and observe in the HTML output that both functions will have a link to the other function.
Related
I got two C program files, a basic code
main.c and function.c
the function.c file contains the function which I need to call in main.c file
i've tried merging files using -o
the error appears to be : liker not found, although all the libraries and stuff are perfectly present in my system.
I'am facing this problem in vsCode in macOS.
Let's begin with taking an example in the attachment there are two pictures if you see the picture which has code for one.c there I have used a line
#include "two.c"
Just to tell the compiler that I want to see every single definition in two. c
In file one.c I have called a function named print which is defined in two. c
One thing that can be noticed and is a really important observation is that in two.c, the file from where definitions needed to be called doesn't have a main function. Can you guess why? The reason is simply because when you click on one.c your system will call the main function located in one.c. Upon seeing two main functions on the second file it gets confused and throws error, and just think why you even need the main function in two.c. There is no need because we use the main function just to perform certain actions and in two.c you really don't need to perform any action but you only need a function to be exported on another file.
In your case, you need to eliminate the main function from the function .c file and in main .c just include the path of your function .c
I have an IAR STM32 project where I am need to wrap a library function with some custom logic. I do not have the ability to recompile the library itself, so what I would like to do is create a function libfunction_shim that calls into the original libfunction. Using the --redirect linker option (--redirect libfunction=libfunction_shim), I can redirect calls to the original function to the shim, including calls inside the library itself. However, I need to call the original function from the shim.
If I add another redirect (--redirect libfunction_original=libfunction), it ends up redirecting libfunction_original to libfunction_shim, rather than the original libfunction. I've tried reordering the redirects, but it does the same thing regardless of order.
The linker log demonstrates this:
Symbol Redirected to Reason
------------- ------ ------
...
libfunction libfunction_shim command line
libfunction_original libfunction_shim command line
What I would like this:
Symbol Redirected to Reason
------------- ------ ------
...
libfunction libfunction_shim command line
libfunction_original libfunction command line
Is it possible to do this using the linker?
This is not possible using linker redirects, you have to write your shim function in a specific way. A complete description is available in the manual (pg 225 in the 8.40.1 version) but to summarize: First you name the shim $sub$$libfunction, where libfunction is the name of the function to shadow. From inside the shim you can use $super$$libfunction to call the original version of libfunction. A minimal example is shown below.
extern void $Super$$foo(void);
void $Sub$$foo(void)
{
$Super$$foo(); /* calls the original foo() function */
}
Let's say I have two files named "AA.c", "BB.c"
/* in AA.c */
inline void AA(void) __attribute__((always_inline));
void AA()
{
/* do something */
}
and then
/* in BB.c */
#include "AA.c"
extern void funcAA(void);
int main(void)
{
funcAA();
return 0;
}
does funcAA( ) also become inline???
no matter the answer is yes or no, could you explain some more about the under the hood??
including a .c file is equivalent of copying and pasting the file contents directly in the file which includes that, exactly like if the function was directly defined in the including file.
You can see what the compiler is going to compile by trying to compile your file with -E flag (preprocessor output). You'll see your function pasted-in.
So it will be inline just because of the inline keyword, and forced with the always_inline attribute even if the compiler would have refused to inline it because of function size for instance.
Word of advice: know what you're doing when including a .c file from another one. Some build systems/makefiles just scan the directories looking for files called *.c so they can compile them separately. Putting a possibly non-compiling C file there can make the build fail, and if it builds, you could have duplicate symbols when linking. Just don't do this.
If you want to do this, put your function in a .h file and declare it static so it won't fail the link if included in many .c files (each function will be seen as different)
The header comments in my main.c are not being processed by doxygen, however if I rename the file from main.c to for example mainn.c it works very well.
Why is main.c treated differently from an other file name?
How do I make Doxygen manage main.c as other .c files?
Or alternatively, what is the best practice here? My purpose in Main.c is to put a short (maybe not so short) product description and use cases in the header documentation.
The header file starts as such:
/**********************************************************//**
* #file main.c
* #author Somebody
* #brief Main function and support functions.
* #details
Then continues with application level things I want to document.
Doxygen configuration is the default as it is installed, except for a few items, such as optimised for C, include call charts etc...
Thanks..
Kinda hard to tell without seeing how you've tried to document it... But make sure you have a line in the main.c file that reads
/*! file */
or
/** #file */
(Doxygen doesn't document global objects by default)
After mucking around a bit here is the solution. (As proposed by MPI_What.
As mentioned in my question
/**********************************************************//**
* #file main.c
* #author Somebody
* #brief Main function and support functions.
* #details
Works for all files except main.c (Of course the line #file main.c is different for the other files. However the following works well for main.c also:
/**********************************************************//**
* #file
* #author Somebody
* #brief Main function and support functions.
* #details
Why it works is a mystery, but it does.
Thanks, Adrian
How do you have a header file for a function and the implementation of that function in different files? Also, how do you have main in yet another file and call this function?
The advantage is so that this function will then be an independent component which can be reused, right?
This is best illustrated by an example.
Say we want a function to find the cube of an integer.
You would have the definition (implementation) in, say, cube.c
int cube( int x ) {
return x * x * x;
}
Then we'll put the function declaration in another file. By convention, this is done in a header file, cube.h in this case.
int cube( int x );
We can now call the function from somewhere else, driver.c for instance, by using the #include directive (which is part of the C preprocessor) .
#include "cube.h"
int main() {
int c = cube( 10 );
...
}
Finally, you'll need to compile each of your source files into an object file, and then link those to obtain an executable.
Using gcc, for instance
$ gcc -c cube.c #this produces a file named 'cube.o'
$ gcc -c driver.c #idem for 'driver.o'
$ gcc -o driver driver.c cube.c #produces your executable, 'driver'
Actually you can implement any function in header files for better performance(when implementing libraries for example) as long are not referenced to a specific object(actually it won't compile that).
By the way even with that way, you have separate interface and implementation ;)
Of course you will have include gurads in you header files to avoid "multiple definition" errors.
In C/C++, non-inline functions should be defined only once. If you put function defination
in header files, you will get "multiple defination" link error when the header file is included more than once.