I would like to use Doxygen for documenting my Arduino code. For this I need the *.ino-files in my project to be treated like *.c-files and be parsed with the C code parser in Doxygen. I think there was a setting somwhere for this mapping but I can't find it anymore.
My settings so far:
FILE_PATTERNS = [...] *.ino
Oh, I think I already found the option. It is located under "Project" in doxywizard, "EXTENSION_MAPPING". These are the options that seem to be working for me now:
FILE_PATTERNS = [...] *.ino
EXTENSION_MAPPING = ino=c
And the tag that gets me every time: A #file-tag has to be added to the top of the file, otherwise it is ignored by Doxygen. Like so:
/**#file sketch_1.ino */
Related
I have modified an nginx module in a way that it depends on a library.... let's call the library that I need libx.
I have modified auto/os/linux in such a way that I am able to detect if libx is present... by adding something like:
+ngx_feature="libx"
+ngx_feature_name="NGX_HAVE_LIBX"
+ngx_feature_run=no
+ngx_feature_incs="#include <libx.h>"
+ngx_feature_path=
+ngx_feature_libs=-lx
+ngx_feature_test="libx_init();"
+. auto/feature
Then, in the module code I do #ifs checking for NGX_HAVE_LIBX... something like:
#if (NGX_HAVE_LIBX)
libx_init();
#endif
And it works like a charm.... when I run auto/configure I get that the library is detected with something like:
checking for libx... found
and it compiles BUT at link time it's not including -lx as part of the flags sent to cc/ld when building the final objs/nginx binary. I would have expected that after the feature be detected in auto/os/linux it would automagically be added to the linking phase when creating the Makefile... but apparently that's not the case so I know I am missing something... what additional step do I need to do to pull it off?
This is on nginx 1.19.2 (well, master branch from nginx mirror).
I think I got it.
I needed to add something like this:
+ngx_feature="libx"
+ngx_feature_name="NGX_HAVE_LIBX"
+ngx_feature_run=no
+ngx_feature_incs="#include <libx.h>"
+ngx_feature_path=
+ngx_feature_libs=-lx
+ngx_feature_test="libx_init();"
+. auto/feature
if [ $ngx_found = yes ]; then
CORE_LIBS="$CORE_LIBS -lx"
NGX_LIBDL="-lx"
fi
I am trying to generate documentation for my code using QDoc. qtdoc command is already in my environment variable path. But when I try to run the command in the root directory of the project (qdocconf file also resides in project root),
qdoc projectname.qdocconf
I get the following error
qt.qdoc: "qdoc can't run; no project set in qdocconf file"
Here is my projectname.qdocconf file.
headers.fileextensions = "*.h *.hpp"
sources.fileextensions = "*.cpp *.qml *.qdoc"
outputdir = Documentation/Code
headerdirs += Code
sourcedirs += . \
Code
exampledirs = .
imagedirs += ./Images/icons \
./Images/logos
I have commented on my class functions as described in the documentation using the format
/*!
* \fn void inlineFunction()
*
* Some info here...
*/
Can you point me what am I doing wrong?
Also, can I create the documentation using QtCreator instead of running the command in terminal?
Well somehow I figured out that you need to add the following line in your .qdocconf file
project = YourProjectName
which is not present in the minimum qdocconf file presented in https://doc.qt.io/qt-5/qdoc-minimum-qdocconf.html. Even though the above issue was resolved, a lot of other issues were encountered such as:
While compiling, qt.qdoc: No include paths passed to qdoc; guessing reasonable include paths. For this you have to manually include all the source paths. Read: https://bugreports.qt.io/browse/QTBUG-67289
Some comment tags, e.g. \return, \param, present in QtCreator are not recognized by QDoc
Option 2
Alternatively, look for Doxygen which is much easier to use and generate documents with a simple to use GUI. It also recognizes all the comment tags in QtCreator.
Update:
Doxygen plugins for Qt Creator doesn't work anymore as the support has expired. Use Doxygen GUI directly.
We are using custom kernel, so I override variables defined in linux-imx_xxx.bb:
KERNEL_SRC_pn-linux-imx = "our_url"
SRCBRANCH_pn-linux-imx = "our_branch"
SRCREV_pn-linux-imx = "${AUTOREV}"
It works. But many patch files added in linux-imx_xxx.bb and out custom kernel have patched.
So I want to just remove patch files in local.conf, and not touch any .bb files defined in official meta-fsl-* layers.
SRC_URI_remove_pn-linux-imx = " file://*.patch"
But this doesn't work. So is there a way to do this in local.conf?
BTW I know the .bbappend should works, but again, I don't want change any meta-fsl-* layers.
You can't use a wildcard because _remove is literal string removal. Spell out the files you want to remove, and you'll be fine.
However if you're using a custom kernel then just write a new recipe for it, no point taking linux-imx and editing it from local.conf.
We are moving into Scala/SBT from a Java/Gradle stack. Our gradle builds were leveraging a task called processResources and some Ant filter thing named ReplaceTokens to dynamically replace tokens in a checked-in .properties file without actually changing the .properties file (just changing the output). The gradle task looks like:
processResources {
def whoami = System.getProperty( 'user.name' );
def hostname = InetAddress.getLocalHost().getHostName()
def buildTimestamp = new Date().format('yyyy-MM-dd HH:mm:ss z')
filter ReplaceTokens, tokens: [
"buildsig.version" : project.version,
"buildsig.classifier" : project.classifier,
"buildsig.timestamp" : buildTimestamp,
"buildsig.user" : whoami,
"buildsig.system" : hostname,
"buildsig.tag" : buildTag
]
}
This task locates all the template files in the src/main/resources directory, performs the requisite substitutions and outputs the results at build/resources/main. In other words it transforms src/main/resources/buildsig.properties from...
buildsig.version=#buildsig.version#
buildsig.classifier=#buildsig.classifier#
buildsig.timestamp=#buildsig.timestamp#
buildsig.user=#buildsig.user#
buildsig.system=#buildsig.system#
buildsig.tag=#buildsig.tag#
...to build/resources/main/buildsig.properties...
buildsig.version=1.6.5
buildsig.classifier=RELEASE
buildsig.timestamp=2013-05-06 09:46:52 PDT
buildsig.user=jenkins
buildsig.system=bobk-mbp.local
buildsig.tag=dev
Which, ultimately, finds its way into the WAR file at WEB-INF/classes/buildsig.properties. This works like a champ to record build specific information in a Properties file which gets loaded from the classpath at runtime.
What do I do in SBT to get something like this done? I'm new to Scala / SBT so please forgive me if this seems a stupid question. At the end of the day what I need is a means of pulling some information from the environment on which I build and placing that information into a properties file that is classpath loadable at runtime. Any insights you can give to help me get this done are greatly appreciated.
The sbt-buildinfo is a good option. The README shows an example of how to define custom mappings and mappings that should run on each compile. In addition to the straightforward addition of normal settings like version shown there, you want a section like this:
buildInfoKeys ++= Seq[BuildInfoKey](
"hostname" -> java.net.InetAddress.getLocalHost().getHostName(),
"whoami" -> System.getProperty("user.name"),
BuildInfoKey.action("buildTimestamp") {
java.text.DateFormat.getDateTimeInstance.format(new java.util.Date())
}
)
Would the following be what you're looking for:
sbt-editsource: An SBT plugin for editing files
sbt-editsource is a text substitution plugin for SBT 0.11.x and
greater. In a way, it’s a poor man’s sed(1), for SBT. It provides the
ability to apply line-by-line substitutions to a source text file,
producing an edited output file. It supports two kinds of edits:
Variable substitution, where ${var} is replaced by a value. sed-like
regular expression substitution.
This is from Community Plugins.
This is really a newbie question - but basically, how do I enable a template for certain filetypes.
Basically, I just want the template to insert a header of sorts, that is with some functions that I find useful, and libraries loaded etc.
I interpret
:help template
the way that I should place this in my vimrc
au BufNewFile,BufRead ~/.vim/skeleton.R
Running a R script then shows that something could happen, but apparently does not:
--- Auto-Commands ---
This may be because a template consists of commands (and there are no such in skeleton.R) - and in this case I just want it to insert a text header (which skelton.R consist of).
Sorry if this question is mind boggeling stupid ;-/
The command that you've suggested is not going to work: what this will do is run no Vim command whenever you open ~/.vim/skeleton.R
A crude way of achieving what you want would be to use:
:au BufNewFile *.R r ~/.vim/skeleton.R
This will read (:r) your file whenever a new *.R file is created. You want to avoid having BufRead in the autocmd, or it will read the skeleton file into your working file every time you open the file!
There are many plugins that add a lot more control to this process. Being the author and therefore completely biased, I'd recommend this one, but there are plenty of others listed here.
Shameless plug:
They all work in a relatively similar way, but to explain my script:
You install the plugin as described on the linked page and then create some templates in ~/.vim/templates. These templates should have the same extension as the 'target' file, so if it's a template for .R files, call it something like skeleton.R. In your .vimrc, add something like this:
let g:file_template_default = {}
let g:file_template_default['R'] = 'skeleton'
Then create your new .R file (with a filename, so save it if it's new) and enter:
:LoadFileTemplate
You can also skip the .vimrc editing and just do:
:LoadFileTemplate skeleton
See the website for more details.
Assume that your skeletons are in your ~/.vim/templates/ directory, you can put this
snippet in your vimrc file.
augroup templates
au!
" read in templates files
autocmd BufNewFile *.* silent! execute '0r ~/.vim/templates/skeleton.'.expand("<afile>:e")
augroup END
Some explanation,
BufNewFile . = each time we edit a new file
silent! execute = execute silently, no error messages if failed
0r = read file and insert content at top (0) in the new file
expand(":e") = get extension of current filename
see also http://vim.wikia.com/wiki/Use_eval_to_create_dynamic_templates
*fixed missing dot in file path
Create a templates subdirectory in your ~/.vim folder
$ mkdir -p ~/.vim/templates
Create a new file in subdirectory called R.skeleton and put in the header and/or other stuff you want to automagically load upon creating a new ".R " file.
$ vim ~/.vim/templates/R.skeleton
Then, add the following to your ~/.vimrc file, which may have been suggested in a way by "guest"
autocmd BufNewFile * silent! 0r $HOME/.vim/templates/%:e.skeleton
Have a look at my github repository for some more details and other options.
It's just a trick I used to use .
It's cheap but If you ain't know nothing about vim and it's commands it's easy to handle.
make a directory like this :
~/.vim/templates/barney.cpp
and as you konw barney.cpp should be your template code .
then add a function like ForUncleBarney() to end of your .vimrc file located in ~/.vimrc
it should be like
function ForBarneyStinson()
:read ~/.vim/templates/barney.cpp
endfunction
then just use this command in vim
:call ForBarneyStinson()
then you see your template
as an example I already have two templates for .cpp files
:call ForBarney()
:call ACM()
sorry said too much,
Coding's awesome ! :)
Also take a look at https://github.com/aperezdc/vim-template.git.
I use it and have contributed some patches to it and would argue its relatively full featured.
What about using the snipmate plugin? See here
There exist many template-file expanders -- you'll also find there explanations on how to implement a rudimentary template-file expander.
For my part, I'm maintaining the fork of muTemplate. For a simple start, just drop a {ft}.template file into {rtp}/template/. If you want to use any (viml) variable or expression, just do. You can even put vim code (and now even functions) into the template-file if you wish. Several smart decisions are already implemented for C++ and vim files.