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.
Related
I'm having some trouble using the pp command to create standalone executables on a Linux machine. It seems that every tutorial says a different thing and I'm a bit confused. I'd like your help regarding two issues:
1. I'm trying to include a module created by me (.pm file), but not sure how to do so and keep getting error messages. Should I use the -M option? or should it be -B? And once the module is included, how do I call it from the script? the usual way (i.e. "use module" and then "module::sub")?
2. I want to include some text files too. So far, I've tried -a and -l options, but not sure if they actually work. Which one should I use? Also, how do I open these files? For instance, if I pack the file tmp.txt, what should the open command look like?
Thank you very much!
Adding modules with the -M option and use the module as usual.
Adding your text file with the -a option, from pp's manual:
By default, files are placed under / inside the package with their original names.
so you should be able to read these text files with:
my $content = PAR::read_file('your_file.txt');
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 am trying to link against the libconfig++ library using cmake. I installed the library
using apt-get so I am assuming it will have a .cmake file so I can use find_package. Problem is I don't know what package name to use. I tried libconfig, config, config++ as the package name to no avail.
As a general question, how does one find out which package is associated with a library.
I know that find_package looks into CMAKE_MODULE_PATH to see if there is a .cmake script. How to I find out what is the value of CMAKE_MODULE_PATH on my system. It's not an environment variable. I am running ubuntu 12.04.
Any help is appreciated.
To use find_package you need to have corresponding Find or Config cmake file. But library may not to provide it, seems with your library is such a case. You can use find_library for finding libraries and find_path to find include directories. With these commands you can even write FindXXX.cmake yourself.
CMAKE_MODULE_PATH is not an environment variable, it is CMake's one. This variable is intended for you to set, if you have additional directories with modules, by default it's empty. This is used in the "Module" mode. In this mode CMake searches FindXXX.cmake in the CMAKE_MODULE_PATH (your modules) or in modules shipped with CMake and if it's found, it then used to find library and it's headers.
If that module wasn't found, it then switches into "Config" mode. On Unix it searches for ConfigXXX.cmake in the following directories:
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/
<prefix>/(lib/<arch>|lib|share)/<name>*/
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/
This files is shipped with the library, so there is no need to find anything, they contain all information, where library and includes located, etc.
About naming scheme, there is no standard one. You can look at Standard CMake modules. Modules found in internet for your library named FindLibConfig.cmake
For your case, library ships without corresponding cmake file, so you should write it your self (or find already written) and add directory with that file to CMAKE_MODULE_PATH.
I suggest you to read how find_package command works and how to write FindXXX.cmake files.
I've created a deployment project which works rather well and now I want to add it to source control repository for others to use.
The main problem I'm facing is that the .prj file which deploytool creates contains absolute paths which will not work on other computers. So far I've tried the following:
Create the stand alone exe using just mcc without deploytool. This works great but I could find a way to create the final _pkg.exe which contains everything. mcc doesn't seem to be able to create this file and there doesn't seem to be any other tool which does. Is this really the case?
Edit the .prj file to include relative paths instead of absolute paths. This only works partially because the .prj file contains a section called MATLABPath which is always replaced with the current setpath of matlab. anyone which uses this file will have to check it out since it is being changed when used.
Find a way to generate the .prj file. the mcc documentation say: Project files created using either mcc or deploytool are eligible to use this option. suggesting there is a way to create a .prj file using mcc but I wasn't able to find how this can be done.
Is there a solution to this situation?
We ran into the same thing with Matlab Builder JA. Not only are the paths absolute, Matlab also adds other toolboxes that it finds on the path, which is irritating, as the build machine doesn't have licenses for a lot of them.
So what we do is:
Edit the prj file by hand to get rid of the absolute paths
Check it into source control and build with mcc
NEVER EVER check in the prj file after it has been touched by deploytool (do all changes by hand in an editor)
Our revision control lets you modify files without an explicit checkout, so using deploytool is not a problem. But why would you want to?
Not sure what the final packager does, but if it just bundles the MCR with the compiled binary, I would just write a replacement.
I personally use Visual Studio 2005 project to maintain my deployment projects and then convert the VCPROJ to PRJ on the fly using build command step
http://younsi.blogspot.com/2011/11/matlab-relative-path-issue-in-prj.html
Here's the mcc option documentation.
What I've found most useful is creating a standalone exe using mcc:
mcc -C -m <function.m> -a <fig> -a <dll> -a <etc> -d <outputPath>
The -C option tells mcc to generate the ctf file (which is the archive of all the compiled MATLAB stuff) as a separate file. I've had trouble on some target computers using a single exe with everything compiled in.
The -m option tells mcc to make an exe.
The -a options tell mcc to include the specified file in the package. For instance, if your script uses two fig files and a data file, you need a -a for each to make sure they get put in the output package.
To tell mcc to use a project file (I've never done this myself):
mcc -F <projectfile>
Also, if you're using R2009a on Windows, there's a known bug that requires some manifest manipulation.
I was trying to install Taglist in VIM and I did not understand this step:
If the exuberant ctags utility is not
present in your PATH, then set the
Tlist_Ctags_Cmd variable to point to the location of the exuberant ctags
utility (not to the directory) in the .vimrc file.
What does it mean? If anybody uses this plugin, could you please help me congfigure it?
I downloaded the ctags and set my variable to
:let Tlist_Ctags_Cmd='C:\Program Files\Vim\ctags-5.7\ctags.exe'
But Im still getting "cannot generate tags" error.
ctags is a separate program you will need to install on your system.
http://ctags.sourceforge.net/
you'll want to look for install instructions for your specific operating system.
Once thats installed you can set that variable as specified if its not in your PATH
There is what seems to be thorough installation information here.
http://vim-taglist.sourceforge.net/faq.html
If you've installed ctags and you're still getting the Taglist: Failed to generate tags error like I was, make sure to use this format in your vimrc:
let Tlist_Ctags_Cmd = '"C:\Program Files\ctags58\ctags.exe"'
Note the double quotes inside the single quotes. I believe this is necessary when there are spaces in your string, and it's what made things work for me.