How can I get the differences between my Doxyfile and the default one?.
I have been looking for this question in internet but did not found anything. And it seems there is no information on this in the man or info for doxygen.
There is no command for this in doxygen itself, but can be accomplished quite easy.
create a new Doxyfile: doxygen -g new_doxyfile
in case your Doxyfile is from the same version of doxygen as the above mentioned file:
*nux: diff new_doxyfile <your_doxyfile>
Windows: fc new_doxyfile <your_doxyfile>
in case your Doxyfile is from a previous version
update the Doxyfile
doxygen -u <your_doxyfile>
compare the files (see above)
in both cases post ONLY the parts related to <your_doxyfile>
Related
I'm planning to use doxygen to document a project. It's an OSS project whose current documentation is of questionable quality. The reason I've decided to go with doxygen is because from version 1.8, doxygen has added support for Markdown (text formatter; think we use it on this site too).
A concern of mine is for the people who might end up using older versions of Doxygen (for example, it hasn't been updated in the current Ubuntu LTS release).
Is it possible to add some setting or marking in the Doxyfile (doxygen configuration file), such that it will issue an error/warning if someone tries to generate the documentation using an older version of doxygen?
(Ideally, explaining the cause of error as well)
Doxygen itself provides a sort-of warning for these circumstances. If your doxyfile includes things like MARKDOWN_SUPPORT = YES and the incumbent doxygen is not one that supports markdown, then you do get a warning that the option is unrecognised.
Warning: ignoring unsupported tag 'MARKDOWN_SUPPORT'...
Alternatively, you could implement some script that parses the return from doxygen -v which will either return a handy '1.8.5' or the usage help, including a line version 1.y.z - so something based around doxygen -v | grep "1\." would extract a suitable line.
Where do I configure doxygen to use the 64-bit verions of ghostscript? It seems by default doxygen calls for gswin32c.exe rather than gswin64c.exe.
Thank you.
Lazy solution: copied gswin32c.exe to gswin64c.exe. Sorry, I'm in a rush and couldn't find the proper solution and didn't want to install 32-bit ghostscript.
I'm setting up the doxygen for a project. The module files have their language standard extension (.py), but the executable scripts do not. How can I get doxygen to read these correctly (Python in this case)? I tried
EXTENSION_MAPPING = ''=Python
But that looks for files named "blah.". I'm on a Unix system, so the concept of a file extension doesn't even exist here. And this is an existing project, so renaming all of the existing scripts is not an option.
Any ideas?
I modified doxygen to handle filenames without dots in them, and I'll submit the patch to the maintainers.
One simple trick is to make a symbolic link to the script that does have the right extension, and let doxygen then process the symbol link.
Say you have a python script called test, then do
ln -s test test.py
and then specify the test.py file in doxygen's configuration file
INPUT = test.py
According to doxygen's EXTENSION_MAPPING docs,
EXTENSION_MAPPING = ".no_extension=python"
should work.
I've authored the README file in my Perl module in Markdown. Github treats this README file as plain text. I tried renaming the file to "README.md"—which looks great on Github, but is invisible to Perl tools that look for a file named "README."
Is there any way I can have both a README file, and have my Markdown formatting be interpreted correctly by Github?
The only option I could come up with was to have both a README and a README.md, but I'd prefer not to have to manually keep the two files in sync.
Thanks for your help.
Format your README in pod, rename it README.pod and then it works both places! Example
For my purposes I actually just generate my README.pod from the main pod by doing
$ podselect lib/My/Main/Module.pm > README.pod
One caveat, named external links don't work correctly L<GitHub|http://github.com> will unfortunately point to search.cpan.org looking for a GitHub module. I have tried to inform them of this glitch but it got me nowhere. Instead you can just use plain external links (i.e. GitHub: L<http://github.com>) and they work fine.
Good news, it appears that they have fixed this since the last time I checked!
Just a question, what parts of the Perl toolchain expect a README file? If you mean including it in your tarball, just be sure to add the file to your MANIFEST and it should get included.
Have you heard of POD? This is the standard documentation tool in Perl. POD is a simple text documentation format that actually lives in your code. One of the commands that come with perl is perldoc. You can use it to get the information of any Perl command. Try these:
$ perldoc File::Find
$ perldoc -f split
All Perl modules in CPAN are required to incorporate POD documentation. In fact, this is how the CPAN webpages themselves are built.
So, where am I going with this and how is this going to help you?
You should include POD documentation in your Perl program. Then, you can use the pod2text command to create your README for your Perl program:
$ pod2text myperl.pl > README
That handles half of your issue.
The other half is a bit more tricky. You need to install from CPAN the Pod::Markdown on your system. Then, you can run the pod2markdown command that comes with this module to create the markdown version of your file:
$ pod2markdown myperl.pl > README.md
The results:
Your documentation lives, as it should, in your Perl program.
Users can use the perldoc program to print out complete documentation of your program.
You can use the pod2text tool to create your README file.
You can use the pod2markdown tool to create your README.md file.
As a bonus, you can use the Pod::Usage module that comes with Perl to show the POD documentation (or bits and pieces of it) as help text that's displayed when a user runs your program with the -help parameter.
So, one place where your documentation lives, and you're using a couple of helper programs to create the files Github and whatever Perl tools you use need.
If you don't mind using Dist::Zilla you can pretty much do away with maintaining a README entirely. For example Dist::Zilla::Plugin::ReadmeFromPod can create your README file by extracting the Pod from your main module. This means never having to write a README again.
I've never tried it myself, but you could look at something like Dist::Zilla::Plugin::ReadmeMarkdownFromPod to create your README automatically in markdown.
This may not be the exact answer you're looking for, but I think using this sort of a tool can save you a lot of time as it allows you avoid repeating yourself in your documentation.
Another solution if you really want to distribute your module with a Markdown README, that doesn't involve Pod is to :
rename your README file to README.md
update the previous change in the MANIFEST file
I think it can be an interesting solution because more people know Markdown syntax than Pod one. As the aim of the README file is to be read by anyone, Markdown should be considered.
I was just looking for a solution for this problem and decided to use Dist::Zilla::Plugin::ReadmeAnyFromPod as it understands =attr and =method tags from Pod::Weaver.
The only option I could come up with was to have both a README and a
README.md, but I'd prefer not to have to manually keep the two files
in sync.
Then automatically keep them in sync?
I have made a toolchain using this script: http://gist.github.com/403608 (more or less modified to get it to work)
Everything is installed and now when I try to compile using it I get an error when I ./configure it says that my C compiler cannot create exeicutables. I'm thinking that my compiler just doesn't know where to look for all the headers and libs... cause they are not in /usr/ they are in /var/sdk/usr/
is there a way to tell my compiler to always look in /var/sdk/usr/ also?
Most configure scripts use LDFLAGS and CPPFLAGS environment variables to modify directory search paths for includes and libs.
LDFLAGS="-L/other/libs" CPPFLAGS="-I/other/includes" ./configure
You can also look at the compiler documentation as they usually have environment variables they look at as well. For example gcc looks in directories listed LIBRARY_PATH for libs. It will also look directories CPATH for includes.
Go into your target settings (control-click on a target and choose Info). Select the Build tab, then fill in Header Search Paths for headers, Library Search Paths for libraries.
For gcc, use the directory search options
gcc -L/foo/bar/baz
gcc -I/foo/bar/quux
The first one adds the directory /foo/bar/baz to the linker search path (libs will be found here). The second one adds the directory /foo/bar/quux to the front on the list of directories to search for headers. Mixed and multiple -I and -L options can occur in a single invocation. If you use multiple "-I"s, they are searched in left to right order and then the system directories are searched.