I am using doxygen to generate a chm document for my header files. I have a problem in removing the path of the source (i.e header files) in my chm. For example if the path of my header files is c:\users\dx\Desktop\myprogram, my path seems to appear in the file reference, right below File List and File Members (i.e when i click on files -> and then on my header file name i am able to see the absolute path of my header files )
The link below is an image of a screen shot of the problem i am facing.
https://www.dropbox.com/sc/qzodmybui6nxub2/BeAqf7y2jM
How do i remove the directory reference, header file reference, how can i prevent those paths from displaying?
I tried removing source_browsers, verbatim_headers, strip_from_inc_path none of them worked
Thanks in advance.
Ps- Extremely sorry about the poor description, i hope the link would help to understand my problem
Set FULL_PATH_NAMES = YES and STRIP_FROM_PATH = ../
The value passed to STRIP_FROM_PATH is dependent on where you are running doxygen from. I am assuming you are running doxygen in a subdirectory of the root of the source.
Enable Full_Path_Names
set the strip_from_ path and the strip_from_inc_path as the source path
e.g. if my header files are in a folder XX within a folder YY in the desktop, then MY STRIP FROM PATH and STRIP FROM INC PATH should be C:\Users\dx\Desktop\YY\XX\
Related
When I copy a file path from the Windows file explorer and paste it into VSCode, it looks like that:
\\network_name\project\file 1.txt
For the link to be clickable and point to the right location, I figured that I needed to make 3 modifications: change the backslashes to forward ones, add "file:" at the beginning of the link, and replace spaces by "%20" (yes, my colleagues put spaces in file names everywhere, I can't do anything about that). The working link is the following:
file://network_name/project/file%201.txt
I want to be able to change all file paths from the pasted version to the working version at once in the open Markdown document in VSCode. How can I achieve that? It seems that this is the job for an extension, but I can't find one that does it.
You can use relative links like explained in next solution https://stackoverflow.com/a/59226851/1654688
Also, to use absolute path, this works for me:
[Folder](<file:///C:/Users/username/folder/filename.md>)
Note that including the path inside <> is intended to allow using spaces in the path or filename
tl;dr question:
What is the actual algorithm doxygen uses to find images referenced to in doxygen comments? And the corollary, what's considered best practice which won't break in future doxygen versions?
Details:
We're trying to institute a policy where any images associated with doxygen comments should be localized to the reference, which means we'll have images distributed throughout the source tree. Obviously, we need to make sure that we refer to the images appropriately and that doxygen can find them to produce the correct documentation.
The doxygen documentation states:
doxygen will look for files in the paths (or files) that you specified after the IMAGE_PATH tag
However, in my tinkering I've come to the conclusion that this doesn't seem strictly correct. Here are some experimental results:
================================================
Experiment
File system configuration:
/full/
path/
doxygen.cfg
to/
this/
header.h
images/
image.png
other/
images/
image.png
The doxygen config file is in the "root" of the tree (i.e., /full/path/) and doxygen is executed from this same folder.header.h references images/image.png located in the same tree (/full/path/to/this). There is an identically named image file located elsewhere in the tree. header.h has the line:
#file html [filename]
reference where [filename] is one of the following:
image.png
images/image.png
./images/image.png
/full/path/to/this/images/image.png
Then I play with the IMAGE_PATH variable.
Case 1:IMAGE_PATH = (i.e., no path defined).
"Wrong" image loaded (other/iamges/image.png)
no image
no image
Correct image loaded
Case 2: IMAGE_PATH = /full/path (path provided to root, but not full path to header file).
Correct image loaded
Correct image loaded
Correct image loaded
Correct image loaded
Case 3: IMAGE_PATH = /full/path/other (path provided to root which does not include the header file).
"Wrong" image loaded (other/iamges/image.png)
"Wrong" image loaded (other/iamges/image.png)
"Wrong" image loaded (other/iamges/image.png)
Correct image loaded
================================================
Inferred Algorithm Properties
Relative paths only work if the relative path is in the tree rooted in a path specified in IMAGE_PATH.
In the case where the image file name can resolve into different images, doxygen appears to pick the one "closest" to the reference.
First thing first... thanks for posting this, I was starting to think I was missing something obvious. Now I know there are at least two of us...
I was attempting to include a picture in a markdown file; this may explain the slightly different results I got. Also, I tested with \image command only. At first I only got a long series of "image not found" warnings, but eventually I reached some consistent positive results suggesting that:
The image is only found when IMAGE_PATH setting points directly to the folder where the image is (no parent folder). The manual slightly hints towards this by suggesting that IMAGE_PATH may ba a collection of paths or files
IMAGE_PATH can be expressed as a full path or relative to the location where DOXYGEN is run
Moreover, in order for the image to be "found", the file name and path should match a part of the actual full name and path of the image
For instance, given a markdown page and an image in the following folders:
/some-path/work/my-page.md
/some-path/work/images/some/more/folders/the-image.png
In order to copy the page while running DOXYGEN in the "work" folder, IMAGE_PATH should be set as one of the following:
/some-path/work/images/some/more/folders/the-image.png
/some-path/work/images/some/more/folders
images/some/more/folders/the-image.png
images/some/more/folders
In all cases, the image can be successfully referenced in the markdown page as either "the-image.png" or "folders/the-image.png", "more/folders/the-image.png" etc. The criteria is the reference matching part of the actual file path and name (while one could expect the image reference to be relative to the markdown file it appears in - this seems wrong).
I say again, these tests were conducted using a markdown file, and it's possible in this case the mechanics be different from the one applicable to images referenced in source files.
In html documentation, images were replaced with the broken image icon.
After two days of trial and error, I found out that the reason was in the set text direction (Project->OUTPUT_TEXT_DIRECTION), it should be None, not LTR. The documentation was carried out in two ways:
#image html my_picture.png
I have very starnge behavior with doxygen. I have source file named as Float32Add.c, when i try to generate the pdf document using doxygen, the documentation does not appear. When i change the same source file name(.c), for e.g. try.c the documentation inside the source file appears (I didnt modify anything except the src file name). I also verified length of the source file is not a problem. Is there any property thats i can look and it helps. Any help regarding this would be appreciated
I am trying to run doxygen on some source files for a project that I downloaded source files for. The files are located in the following directories:
doc/ - Documentation files, such as .dox files.
src/ - Source files
My settings in my doxygen.config file are:
INPUT = ../ .
FILE_PATTERNS = *.h *.dox *.dxx
When I run doxygen (doxygen doxygen.config), it generates all of the documentation from the .h files correctly, but it does not generate the mainpage correctly. I have a file titled intro.dox in the doc folder, with a command \mainpage Documentation Index, and a bunch of text, but doxygen is not using this to generate the main page.
What am I doing wrong?
There are (at least) two possible reasons for this:
You are not including the /doc directory in you INPUT list. Try modifying this to
INPUT = ../ . ../doc
Did you mean to write ../doc instead of ../? I am guessing that your doxygen.config file is in your src directory. If this is not the case can you make this clear in the question.
Doxygen requires that your documentation files (your .dox files) are plain text with your text wrapped with Doxygen C++ comments (i.e. /** ... */).
Without knowing where doxygen.config is located, and since you are using relative paths in INPUT, it is difficult to determine what might cause this, however since the files you are looking for are in parallel directories, it is possible that doxygen is not search recursively for your files. You may want to confirm that RECURSIVE is set to YES in doxygen.config.
Anybody can help show examples of using libarchive to extract ZIP files to a specified folder? It looks like the sample programs provided (untar.c, tarfilter.c and minitar) all extracts the archive to the current working directory. Is there a way to say "extract to this folder and below" to libarchive and not clobber the program's active folder?
One of the main drivers is that the extraction code will be run in a background thread, and thus changing the program working directory may create problems. Also this will be used in an iOS application (iPhone, iPad), which is picky on what folders that the application can write to.
Thanks in advance.
You can rewrite each archive_entry's pathname before calling archive_read_extract. For example:
const char* path = archive_entry_pathname( entry );
char newPath[PATH_MAX + 1];
snprintf( newPath, PATH_MAX, "/SomeOtherDirectory/%s", path );
archive_entry_set_pathname( entry, newPath );
untar.c can be easily modified to do this by prepending the path you want to use to the pathname that is passed to create_dir() and create_file() from untar().
Note that untar.c is a standalone decompressor, seperate from libarchive.
The same effect is easily achievable with libarchive - it gives you full control over the creation of files and directories when unarchiving.