How to make docset on Linux? - linux

I use Zeal to lookup API documentation on Linux. It requires files to be in the Apple docset format.
I have C++ code for which I can generate documentation using Doxygen. Doxygen can build a docset, but it requires the docsetutil program, which is not available on Linux.
Is there any other method to create a docset of a C++ codebase on Linux?

"No need for docsetutil if you're generating a Dash-only docset," suggests the developer of Dash. Likewise according to the Dash documentation, you need the following entries in the Doxygen config file to generate the docset (the last 3 are optional):
GENERATE_DOCSET = YES
DISABLE_INDEX = YES
SEARCHENGINE = NO
GENERATE_TREEVIEW = NO

Related

How can I give precise instructions to qmake to build a lib file using MSVC lib.exe, e.g. "lib.exe /DEF:mylib.def /OUT:mylib.lib

I want to know how to give qmake precise platform-specific instructions to build a library file using MSVC tools.
I want to be able to build a .lib from a downloaded third-party library (specifically SQLite 3, direct download includes .dll and .def files). [I'm NOT interested in building from SQLite C source directly.] I know I can build a .lib for MSVC platform basically by "lib.exe /def:sqlite3.def /out:sqlite3.lib" ... but I would like to know how to incorporate this step in the automated (qmake-based) build process rather than doing it manually.
So you're not going to build anything from sources, but rather to add some custom intermediate target to an existing project. It could be done like this:
# paths to our files
SQLITE3LIB = sqlite3.lib
SQLITE3DLL = sqlite3.dll
# an extra target for make
lsql.target = $$SQLITE3LIB
lsql.depends = $$SQLITE3DLL
lsql.commands = $$QMAKE_LIB /out:$$SQLITE3LIB $$SQLITE3DLL
QMAKE_EXTRA_TARGETS += lsql
# add a (makefile-)dependency for our main target
PRE_TARGETDEPS += $$SQLITE3LIB

What is maskgen tool in JavaCard

In JavaCard, can somebody please tell me what is the purpose of the maskgen tool?
What I have heard from my senior colleagues that it is the tool which converts the Java codes into C code for that particular JavaCard platform. But is answer seems to broad and lacking the exact particularity. If the above mentioned purpose is correct then my few questions are
1. How does it convert the java source code into C code ?
2. How can I see the source code of this maskgen tool ?
3. How can I convert my Java card source code using maskgen tool?
Quoted from Java Card 3 Platform Development Kit User Guide:
What id Maskgen tool?
The maskgen tool produces a mask file from a set of Java Card Assembly
files produced by the Converter. The format of the output mask file is
targeted to a specific platform. The plug-ins that produce each
different maskgen output format are called generators. The supported
generators are cref, which supports the Java Card RE, and size, which
reports size statistics for the mask. Other generators that are not
supported in this release include jref, which supports the Java
programming language Java Card RE, and a51, which supports the Keil
A51 assembly language interpreter. Java Card Assembly Syntax Example
provides additional information about the contents of a Java Card
Assembly file.
Where I can find Maskgen tool source?
The maskgen tool is not available or of use outside of a source
release bundle, so [...] if you do not have a source release of the
development kit you would have maskgen tool. If you have a source
release, you can localize locale-specific data associated with the
maskgen tool, see Localizing With The Development Kit.
How to convert Java Card sources using Maskgen tool?
Check Running Maskgen oracle page:
maskgen Example
This example uses a text file (args.txt) to pass command line
arguments to maskgen:
maskgen -o mask.c cref #args.txt
where the contents of the file args.txt is:
first.jca second.jca third.jca
This is equivalent to the command line:
maskgen -o mask.c cref first.jca second.jca third.jca
This command produces an output file mask.c that is compiled with a C
compiler to produce mask.o, which is linked with the Java Card RE
interpreter. Refer to Using the Reference Implementation for more
information about this target platform.
Above ".JCA" (Java Card Assembly) files are generated using Converter tool. Here is its manual.
Some related quoted info from here:
maskgen actually generates a mask.c file which contains VM bytecodes
that are interpreted by the JCVM and the applet is executed. The
mask.c file should be loaded onto the card. This method is used only
for static use of JavaCard.
And
Maskgen takes the CAP file (which is generated by the converter ), and
generates a mask.c file which will be a part of the cref in static
cards. The parameters for memory configuration of your MCU/processor
can be set in maskgen.cfg file.
Anyway, you need a binary release of JCDK to have this tool and its source.

How to generate a .so file

I am writing an extension for the Scratch text editor application on Elementary OS Luna. But the documentation is practically non-existent for extension creation and I have no idea how to proceed after writing my main code for the extension.
I've already written the extension. I cannot use or test it yet as it needs to be "installed". I spent hours looking for docs but they do not exist. I did however, find a comment on the scratch launchpad page that says
Generally you have to generate a pluginname.so file and put it in
lib/scratch/plugins/pluginname with a pluginname.plugin file
Great. This seems like the last part of creating an extension for Scratch. What is a .so file, and how do I generate one? I've already created the other necessary files like the .plugin file and the .vala file.
Yes, I have searched for .so files but all I found were random things about it like using it with C, or C++ headers but obviously that won't work for me, since I'm using Vala?
How do I generate a .so file? What do I generate it from?
I think the The Vala tutorial could be helpful on creating the actual Shared library or Shared Object.
You can use the autotools, cmake or you can compile and link a shared library directly from the command line, quoted from the Vala tutorial:
Compilation and linking using Command Line
Vala is not yet capable of directly creating dynamic or static
libraries. To create a library, proceed with the -c (compile only)
switch and link the object files with your favourite linker, i.e.
libtool or ar.
$ valac -c ...(source files)
$ ar cx ...(object files)
or by compiling the intermediate C code with gcc
$ valac -C ...(source files)
$ gcc -o my-best-library.so --shared -fPIC ...(compiled C code files)...
From the Scratch Wiki
Due to browser security restrictions, Scratch 2.0 cannot interact with
hardware devices directly. Instead, hardware extensions come with a
helper app, a separate application that the user must install and run
on their computer. Scratch communicates with the helper app via HTTP
requests, and the helper app talks to the hardware. In the future,
some extensions may package their helper apps as browser plugins.
Here are the steps for creating and testing a Scratch extension:
Create an extension description file
Create your helper app and start it
Open the Scratch 2 Offline Editor
Import the extension description (shift-click on "File" and select "Import Experimental Extension" from the menu)
The new extension blocks will appear in the More Blocks palette
Test your extension and iterate!
Helper apps can be written in any language that supports server sockets, such as Python, Node.js, Java, C, etc.
Like you I've chased around the wiki but I cannot find an example with source. So all I can do is to address your question generally.
If you look at Build .so file from .c file using gcc command line you'll see how a simple .so can be created. However what code goes into a Scratch extension I don't know. Sorry.
Edit: More googling and I've found a sample from Nathan Dinsmore on GitHub that doesn't use C rather it uses JavaScript, and though it doesn't create a .so extension, it does have what appears to be a full description of creating an extension. He also provides a couple of tutorials.
Edit++ : And here is another sample written in Java.

Building Boost on Linux - library names

I am trying to build an application which depends on Boost. So I downloaded Boost 1_41_0 to my Linux box and followed the instructions found on the Boost site for Unix variants,
http://www.boost.org/doc/libs/1_41_0/more/getting_started/unix-variants.html.
They basically suggest that I run ./bjam install, which I did. The build completed successfully. However, the library names don't seem to match the Boost naming convention described both in the documentation above, and what is specified in the makefile of the application I am trying to build.
I noticed that there are a bunch of options that I can specify to bjam and I tried to play with those, but no matter what happens I can't seem to get it quite right. My understanding is that the libraries should go into the $BOOST_ROOT/lib directory. This is where the libraries show up, but named:
libboost_thread.a
libboost_thread.so
libboost_thread.so.1.41.0
I'd expect them to be named libboost_thread-gcc41-mt-d-1_41_0 or something similar.
I did try ./bjam --build-type=complete --layout=tagged and I see:
libboost_thread.a
libboost_thread-mt.a
libboost_thread-mt-d.a
libboost_thread-mt-d.so
libboost_thread-mt-d.so.1.41.0
libboost_thread-mt-s.a
libboost_thread-mt-sd.a
libboost_thread-mt.so
libboost_thread-mt.so.1.41.0
libboost_thread.so
libboost_thread.so.1.41.0
So, I am not sure if I should just make stage my -L directory? Is there any documentation which describe this in more detail?
The names was changed in 1.40.0 - see in release notes:
Build System
The default naming of libraries in
Unix-like environment now matches
system conventions, and does not
include various decorations.
They probably forgot to update this part in the build documentation.
There are two variables here. First is "install" vs. "stage" (default). "install" copies both libraries and headers into a directory -- /usr/local by default, and you can then remove source tree. "stage" puts libraries to "stage/lib", and you should add "-L /stage/lib -I " flags.
Second is --layout=versioned and --layout=system. It seems like you have discovered what they do already, and indeed, system is default since 1.40. The getting started guide fails to mention this, and I've added an action item to update it. Ideally, you should talk to the authors of the application to use the system naming of boost libraries. If that's not possible, then building with --layout=versioned is the only option.
From the Boost documentation at http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#library-naming, the convention is:
-mt Threading tag: indicates that the library was built with multithreading support enabled. Libraries built without multithreading support can be identified by the absence of -mt.
-d ABI tag: encodes details that affect the library's interoperability with other compiled code. For each such feature, a single letter is added to the tag:
Key Use this library when:
s linking statically to the C++ standard library and compiler runtime support libraries.
g using debug versions of the standard and runtime support libraries.
y using a special debug build of Python.
d building a debug version of your code.
p using the STLPort standard library rather than the default one supplied with your compiler.
n using STLPort's deprecated “native iostreams” feature.
For example, if you build a debug version of your code for use with debug versions of the static runtime library and the STLPort standard library in “native iostreams” mode, the tag would be: -sgdpn. If none of the above apply, the ABI tag is ommitted.

Platform independent resource management [duplicate]

This question already has answers here:
Is there a Linux equivalent of Windows' "resource files"?
(2 answers)
Closed 4 years ago.
I'm looking for a way to embed text files in my binaries (like windows resource system). I need something thats also platform independent (works in windows and linux). I found Qt resource management to be what I need but I'm not keen on my app depending on Qt for this alone. I also found this tool at http://www.taniwha.com/~paul/res/ .. but it is too platform specific.
The xxd utility can be used to create a C source file, containing your binary blobs as an array (with the -i command line option). You can compile that to an object which is linked into your executable.
xxd should be portable to most platforms.
If you're using QT 4.5, you can make sure that program is only dependent on one small piece of QT, such as libqtcore. QResource is a part of libqtcore.
You can simlpy append all kinds of data to your normal binary. Works in both Windows and Linux. You'll have to open your own binary at runtime and read the data from there.
However, I have to agree that embedding data in binaries is a strange idea. It's common practice to include such data as separate files packaged with the application.
That is not such a great idea. On Linux, for example, data is expected to be installed in a subdirectory of "$datadir" which is, by default, defined to be "$prefix/share", where "$prefix" is the installation prefix. On Mac OS X, resources are expected to be installed in $appbundle/Contents/Resources, where $appbundle is the name of the folder ending in ".app". On Windows, installing data in a folder that is a sibling of the executable is not an uncommon practice. You may be better off using the CMake build system, and using its CPack packaging features for installing/bundling in the default, preferred platform-specific manner.
Although bundling your resources into the executable, itself, may seem cool, it is actually a dangerous idea... for example, will the embedded data be allocated in an executable page? What will happen if you attempt to overwrite or modify the data? What if you want to tweak or modify the data at runtime? Things to think about.
This looks very promising: https://github.com/cyrilcode/embed-resource
CMake based and platform-independent.
As I also do not like the idea of converting files into C arrays only to have them converted back to binaries, I created my own resource compiler using LLVM and Clang:
https://github.com/nohajc/resman
I tested it on Windows, Linux and macOS but it can potentially be run on any platform supported by LLVM.
It is used like this:
Create header file, e.g. res_list.h
#pragma once
#include "resman.h"
// Define a global variable for each file
// It will be used to refer to the resource
constexpr resman::Resource<1> gRes1("resource_file1.jpg"); // resource with ID 1
constexpr resman::Resource<2> gRes2("resource_file2.txt"); // resource with ID 2
constexpr resman::Resource<3> gRes3("resource_file3.mp3"); // resource with ID 3
...
Run resource compiler
$ rescomp res_list.h -o res_bundle.o
Link res_bundle.o to your project
Use the resource files
#include "res_list.h"
...
resman::ResourceHandle handle{gRes1};
// ResourceHandle provides convenient interface to do things like:
// iterate over bytes
for (char c : handle) { ... }
// convert bytes to string
std::string str{handle.begin(), handle.end()};
// query size and id
unsigned size = handle.size();
unsigned id = handle.id();
The resource compiler parses res_list.h (using Clang) but instead of generating cpp files, it goes straight to the native object file (or static library) format (using LLVM).

Resources