I'm using Doxygen-1.8.7, which i have downloaded from official website in dmg version. I'm using 10.9.3 MacOS. I have installed graphviz 2.38.0.0 via macports.
I use Doxygen GUI to configure it and run. Everything works great, if i choose "use build-in diagram generator". But when i use dot tool, i get this:
error: problems opening map file
/Users/pavelantonov/qtProjects/doxygen/result/11-06
1207/html/inherit_graph_21.map for inclusion in the docs!
I've tried to change SHORT_NAMES and FULL_PATH_NAMES as i find in solution from 2008, but it doesn't help.
GraphViz/bin is in paths.
There are no white spaces in *.dot names.
I got this message 'problem opening map file for inclusion in the docs', if doxygen is not able to find graphviz/dot in the path.
Try setting the path explicitly using DOT_PATH in the doxyfile.
As albert, already mentioned remove any whitespace in the path to the output path.
Another good idea is to completely remove your output directory, e.g. html, and regenerate your documentation.
It also seems that doxygen is for activating dot.exe space sensitive. Make sure your path is like this or at least without whitespaces:
D:/Graphviz2.38/bin
based on experience of Graphviz 2.38 on windows 10
The following method worked for me on Windows 10 with Doxygen 1.8.14.
Open cmd and type dot -c. Then, delete the doxygen output folder and regenerate it.
Make sure you have graphviz in your path. My graphviz is installed at C:\Program Files\Graphviz 2.44.1. So, there is no problem, even if spaces are there.
Related
Trying to play around with shaders on the browser and just installed the GLSL Lint extension for VSCode, which apparently needs to know the path to a glslangValidator binary before working properly.
Said binary can (I'm assuming) be found here: https://github.com/KhronosGroup/glslang/releases/tag/master-tot
However, I've already tried multiple combinations of installation paths, both within Linux and Windows, to no avail: the extension keeps spewing an ENOENT error as can be seen in the picture below:
Considering my setup (Using VS Code on Windows with WSL), where exactly should I place this binary file so that GLSL Lint can properly find it?
I tried, for example, both ~/glslang/bin/glslangValidator and C:\\Users\\{User}\\AppData\\Local\\Packages\\TheDebianProject.DebianGNULinux_31v5hhsz12ds6\\LocalState\\rootfs\\home\\glslang\\bin\\glslangValidator (among other installation paths), but so far none worked.
What am I missing?
I just figured it out--the problem is that using VSCode with WSL will change the file system that the path should be written in. Instead of downloading the windows binary glslangValidator.exe, you should download the linux binary glslangValidator. Check this link and copy the url of the latest release, then download it like so:
cd ~ # Or wherever you want it
wget https://github.com/KhronosGroup/glslang/releases/download/master-tot/glslang-master-linux-Release.zip
unzip glslang-master-linux-Release.zip -d glslang
Then, you need to set the glslangValidatorPath to the WSL path:
"glsllint.glslangValidatorPath": "/home/<username>/glslang/bin/glslangValidator"
*Of course, replace <username> with your username, and if you installed it in a different directory, use that path instead.
I'm using Windows and installed glslang in my root path. After that I set the path parameter like this and it worked:
"glsllint.glslangValidatorPath": "C:/glslang/bin/glslangValidator.exe"
Alternatively, you could add C:/glslang/bin to your PATH variable.
I am using Windows
The following helped me: change the extension of the vertex shader file to ".vert" and the extension of the fragment shader file to ".frag".
I am using Conan package manager on Windows to create a package. The conan command to create the package copies files to a folder within %USERPROFILE%\.conan (or C:\Users\xxxxxxx\.conan). Then from this location it builds a Visual Studio project and ultimately calls doxygen.exe to create a .chm help file in a post-build command. The doxygen command fails with:
error : failed to run html help compiler on index.hhp
Further investigation reveals the hhc.exe command executed by doxygen is failing with:
C:\Users\xxxxxxx\.conan\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation>"C:/Program Files (x86)/HTML Help Workshop/hhc.exe" html\index.hhp
HHC5010: Error: Cannot open "C:\Users\xxxxxxx\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation\html\Module.chm". Compilation stopped.
Close inspection reveals that in the error message, the ".conan" folder is missing. Sure enough, I confirmed that hhc.exe fails when the index.hpp resides in a folder that has a parent folder that starts with a ".".
Attempts to resolve this:
changing the Doxyfile setting OUTPUT_DIRECTORY to "$(TMP)/DoxygenModule" resolves the error, but creates the .chm file in another location, which I do not prefer.
navigating to the 8DOT3 name of the ".conan" folder, which is "CONAN~1", to run the hhc.exe command, succeeds, but unfortunately I have no way of getting conan to use this 8DOT3 path for creating the package. E.g. C:\Users\xxxxxxx\CONAN~1\...
I can live with the using the %TMP% folder but would prefer generating the .chm in the current folder. Anyone have any ideas?
HTML Help Workshop v1.31 is installed on my machine at C:\Program Files (x86)\HTML Help Workshop, probably from a Visual Studio installation (not sure). I attempted using a version downloaded from Microsoft website (v1.30) as well, which made no difference.
Other info: Conan version 1.18.0, Doxygen version 1.8.14, Windows 10 Version 1809
Unfortunately not a solution, but this is a known limitation in the hhc.exe, see: https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
Edit 2019-11-15:
I've just pushed a proposed patch to github (pull request 7402, https://github.com/doxygen/doxygen/pull/7402).
This proposed patch changes inside doxygen from the current directory to the short named current directory, but just for the HTML Help compilation.
Edit 2019-11-16:
Code has been integrated in the master version on github.
This is not an answer either. Actually, you found the answer and workaround[s] yourself.
Use OUTPUT_DIRECTORY to specify a directory containing no folder names beginning with periods.
The error you described is a known issue of the MS HTML Help compiler. More general, the HTML Help compiler does not like some folder and file names. Try and stick with these characters _, a..z, A..Z, 0..9. Do not use these signs in particular ., -, # .
Please note that the proprietary CHM file format is about 20 years old (Windows 95, ...). HTML Help is in maintenance mode, which means no new features and bug fixes are expected for either the runtime or the compiler. All mainstream development on HH has stopped.
There is no way to avoid this error if a directory name above begins with a period. Not even if only the necessary files are written by Doxygen and compiling of the index.hhp is done by a third-party tool like FAR HTML using your path that contains .conan. This is because all applications are using the faulty HHA.dll.
The above applies of course to the entire workflow you have described. Maybe you can interrupt it.
Doxygen can be configured not to call the HTMLHelp compiler. Just uncheck the GENERATE_HTMLHELP option (DoxyWizard: Experts > Topics > HTML). You have all files generated by Doxygen in your preferred output directory - but of course without the CHM file. This can be imported later e.g. by HelpNDoc and compiled as a CHM file in another location.
If you can interrupt the workflow and can also make changes to Doxygen's settings, then a preference setting of OUTPUT_DIRECTORY to e.g. C:/CacheMenu/CONAN~1/DOXYGE~1 also works as expected (here used as test case).
No matter what you do, your workaround and copy and paste from another directory outside is a quick solution at this stage. Please note the EDIT in #albert's answer.
I am using Netbeans 8.0.2 and phpdocumentor 2.8.2 on a windows 7 platform.
I would like to use custom phpdoc.dist.xml config files by project so I can specify framework directories and etc. to exclude from the generated doc. I also want to keep my Netbeans PHPDOC plugin config as generic as possible, without specific output directories, ignore options, config path parameters, etc., so on, so that that the config will apply to all my projects.
The phpdoc.dist.xml file works great. The doc generated is exactly what I want.
The problem or feature, and it seems to be a phpdocumentor one as it also applies from plain command line, is that the phpdoc.bat command (without a specific config parm) has to be run from the same root directory as the phpdoc.dist.xml file, or it ignores it. No problem if I'm using command line as I can change into that directory first, but I would like to use Netbeans. I have searched on this extensively and cannot find an answer.
I considered whether to modify the phpdocumentor files to insert cd /D path/to/myproject/dir to change the directory using some Netbeans variable to represent myproject/dir, but I could not find the right place in the code or the variable to use. Plus, then I'm supporting a custom mod to phpdocumentor.
I did find these directions for a PHPStorm setup, where the author specified a PHPStorm variable for the --config command line option to point to his custom phpdoc.dist.xml.
--config="$ProjectFileDir$/phpdoc.dist.xml"
If I could do the same in Netbeans like maybe "${BASE_DIR}/phpdoc.dist.xml" it would be great, but so far I haven't hit on anything Netbeans will recognize/pay attention to in the PhpDoc script: box.
I have also tried writing a wrapper .bat file to capture my own command line variable %1 and do the directory change to that before calling phpdoc.bat, but Netbeans throws and error and says that's not a valid .bat file. I cannot find any phpdocumentor parameter to configure by specific Netbeans project but the output directory. And I would prefer not to be defining a bunch of projects on subdirectories in Netbeans, just to address phpdocumentor.
Now I am out of ideas. Can anyone point me to a solution?
I'd like to know whether there is a way to change the default tool to generate message sequence charts (msc) of Doxygen. Actual default tool for Doxygen is the mscgen (http://www.mcternan.me.uk/mscgen/) and it's a good tool, but I'd like to use msc-gen (https://sites.google.com/site/mscgen2393/) that seems to be a more complete tool.
I've already tried to create a link at "MSCGEN_PATH = /usr/bin/" to the msc-gen (like ln -s /usr/bin/msc-gen ./mscgen) but command line of tools are different. There is a specific way to configure Doxygen to "learn" this new tool command line?
For the current msc-gen version (v4.0.0), your solution should work.
I just tried setting the MSCGEN_PATH to the msc-gen installation directory and it worked for me. msc-gen already brings a copy of its main executable with the name mscgen.exe to be called by doxygen.
This solution is also described in the second paragraph of:
http://msc-generator.sourceforge.net/help/4.0/
You may also like to have a look at Plant UML and its doxygen integration:
http://plantuml.com/index.html
http://plantuml.com/doxygen.html
I'm using NSIS 2.46. Plugin I'm trying to use is HwInfo plug-in (Official Link). The ZIP file comes with some source codes and a DLL file. I put the HwInfo.dll inside \NSIS\Plugins directory. When adding a plugin, I'm supposed to !include the .nsh file as well, which HwInfo does not supply.
I'm trying to analyze the client's harware before installing-
Function .onInit
HwInfo::GetCpuSpeed
StrCpy $R0 $0
MessageBox MB_OK "You have a $0GHz CPU"
HwInfo::GetSystemMemory
StrCpy $0
MessageBox MB_OK "You have $0MB of RAM"
FunctionEnd
But the line HwInfo::GetCpuSpeed is 'invalid command'.
How do I use a plugin without a NSH file? And are there any alternatives?
Solved:
I added !addplugindir "${NSISDIR}\Plugins" at the very top of this script. This helped detect HwInfo.dll inside \NSIS\Plugins directory at compile-time.
Not all plugins have a .nsh file but the wiki page usually tells you how to use a specific plugin.
If you run makensis /V4 yourscript.nsi it will list all plugins and the functions they export, if your plugin is not on the list it is probably not in the correct directory. Make sure you put it in the correct directory or use !addplugindir...
I know this question has an accepted answer, but for info for people using NSIS v3.x:
The plugin folder now has two sub-folders, one for ANSI and one for UNICODE, so you'd need to copy your plugins into ${NSISDIR}\Plugins\x86-ansi\ and ${NSISDIR}\Plugins\x86-unicode\ for the ANSI and UNICODE versions of the plugin dlls respectively.
I'm guessing if you use the 64-bit NSIS port, you'd have \x64-ansi\ and \x64-unicode subfolders too, but I've not checked that specifically.