I have a project supported in Travis-CI. I want to generate the documentation using Doxygen but Im not sure how to make it. I already have a Doxyfile in the root of the Github project. How can I do it?
Thanks in advance for your help.
I don't know whether or not you are on a commercial plan for Travis-CI or are using it for free for a OSS project. In the later case be aware of their new pricing policy.
You didn't mention the OS for which you want to run doxygen, for some distributions an installation package is available.
To run doxygen you have to install doxygen (or build it on Travis, but this would be a bit of an overkill). After installing it you should be able to run doxygen right out of the box.
Related
I am a programming starter to try github for the first time.
https://github.com/froala/design-blocks
I completed the clone as described in the main link.
I have also completed the npm installation as described in the text and have successfully run it.
But if i simply want to use source code, do i not need to install the module using npm?
Why do I install the module using npm?..
How do I use the packages I installed using npm?
Even if I did a search on Google, there was no post for beginners like me.
I really appreciate your advice.
We're currently using the Resharper command-line tool 2016.3 on our CI build server to inspect code for issues at build time. It's working pretty well but I still have an issue and I can't find any proper documentation on that : how do I install and configure an extension using the command line. For example, I want to add the Cyclomatic complexity extension to my analysis. Documentation said to use the -x switch with the name of the extension (PowerToys.CyclomaticComplexity). The code inspection runs but the complexity warning aren't included in my result file, probably because the extension isn't installed on my build server which make sense. I don't have VS installed on my build machine (and I would prefer not to have to) so how can I install the extension "manually" ?
Thanks
The command line tools in 2016.3 don't currently fully support loading extensions. This comment in the issue tracker has some steps that might be able to support - basically put the .nupkg of the extension in the product folder. YMMV.
Although I've been using github for a while, but every now and then this problem pops up. From a github project, how do I know which filed/folders are actually what I need?(Generally, I don't need those files that are only used by developers)
Take this project (https://github.com/mupchrch/split-diff) for example, I am trying to install this plugin into my Atom editor so I can compare two files, but I find very little is said about how and which files are to be installed/copied, and to where. This "lack" of information happens to many many github projects I stumbled with. Some indicates npm install xxx which I am OK with, some says nothing at all, like the above example. So I conclude I must have missed some very important information regarding how to use github package, something that goes without saying.
Can anyone help me or give me any hint?
I noticed that here is a package.json file, which must indicate this package can be installed by npm. But I need more specific instructions:
Do I need to download all the files and folders? To where? And where do I launch npm install? Or as far as I know, Atom editor has its own install command (apm is it?), where do I run this apm?
I followed the instructions in GStreamer Plugin Writer's Guide (1.7.1.1):
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html
in order to build a new gstreamer plugin. Basically I ran make_element and then edited Makefile.am as described. Amazingly make and make install worked and I ended up with:
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.la
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.so
As I understand it, gst-inspect should find this plugin automatically. The guide says that /usr/local/lib/gstreamer-1.0 needs to be added to GST_PLUGIN_PATH in order for plugins in this directory to be found. Another document states that this directory is searched automatically. I tried with and without the environment variable, but no luck.
Now I should say that I have just started to use gstreamer and I am suffering from total information overload. I have read so many documents, yet I don't even know whether I am building a gstreamer1.0 or a gstreamer0.10 plugin (I think the guide is for gstreamer1.0, since the guide's version is 1.7.1.1 but can't be sure).
Can anybody give me a clue here ?
There are many possible reasons that can cause this issue.
First, check if your plugin is blacklisted by command gst-inspect-1.0 -b.
If your plugin show up here, that means it is really blacklisted.
In that case, delete directory ~/.cache/ and then run gst-inpect-1.0 again.
This will force GStreamer to re-scan plugins list. If the reason of blacklist is not solved yet, gst-inpect will probably print out the reason here for you.
Another possible reason (but unlikely happens) is setting GST_REGISTRY_UPDATE as no, which will force GStreamer NOT to rescan the plugin directory, thus not found new plugin
P/s: The guide is for GStreamer 1.0
If you've tried removing your plugin from the blacklist and it still doesn't show up, try this:
export GST_PLUGIN_PATH=/usr/local/lib/gstreamer-1.0
/usr/local/lib/gstreamer-1.0 is the default directory used by make in case of plugins. If you have defined a different directory, use it.
Then run gst-inspect-1.0 and you'll find the newly compiled and installed plugin.
You'll be required to perform the export every time in the shell whether you either create a static pipeline with gst-launch-1.0 or run code of your own. I couldn't find any alternative to make it permanent other than making entry of this in .bashrc file. If you have one, please suggest via comments.
If you run ./configure --help in the gst-plugin directory you will see the following:
By default, make install' will install all the files in
/usr/local/bin', /usr/local/lib' etc. You can specify
an installation prefix other than/usr/local' using --prefix',
for instance--prefix=$HOME'.
If you do after the original installation:sudo updatedb && locate libgst[NAME_OF_YOUR_PLUGIN].so you should see where the library holding your plugin is located (in my case it is under /usr/local/lib/gstreamer-1.0/ as described by the configure help above).
Now on my machine, the GStreamer "official" plugins are installed under: /usr/lib/i386-linux-gnu/gstreamer-1.0/ . This is where the new created plugin library should be stored.
To store the plugin at the right place, run configure with the following parameter:
./configure --libdir=/usr/lib/i386-linux-gnu followed by make && sudo make install
It is important to override with --libdir and NOT --prefix! The usage of --prefix will stick a /lib that we don't want to have under /usr/lib/i386-linux-gnu.The plugin will not be found by gst-inspect-1.0 if /lib is added to the path.
Extra note :
Even if the plugin is at the proper location, you may still see GStreamer blacklisting it when you run gst-inspect-1.0. One of the cause of the blacklisting could be the shared library/ies required by your plugin not installed or not found on your platform. The ldd command can help figuring out the dependencies your plugin may have. Just run ldd [YOUR_GSTREAMER_LIBRARY].so
I'm learning cmake using the tutorial.
Would it be fine to build up a library similar to the tutorial for distribution on github? In other words, distribute the library as a part of an example program repo? A user would clone the repo,cmake, then make to see that the library works. Then later copy the library folder to his own project and use the repo's CMakeList.txt as a starting point for his use of the library?
Cmake is a great tool and I want to use it in a way that's easy for other people to use my libraries when I make them.
Here's an example of what I'm looking to do.
Based on voting for my comment I propose using already existed project.
You may find these interesting:
http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html
http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html
Of course, most of it applies to CMake 2.8.12 and .11.