When compiling a linux kernel, one of the first step is to generate the .config file which in my case I'm getting from the currently installed kernel. So it generates this files with a lot of KEY=VALUES like:
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_STACKTRACE_SUPPORT=y
# etc...
I can just copy/paste one of those keys in google and I'll probably find (in some random site) a detailed explanation for what it is used for. So my question is, is there an official place where I can rely to know about those configs? I searched on kernel.org/doc and didn't found so I decided to ask here. Thanks in advance.
The documentation can be access through the make menuconfig, each entry is documented (a paragraph describes the option).
But you can only see the options that are available to your architecture, and also if you disable a feature it may hide some related option.
If you want to see all options, the best thing it is to open the Kconfig files.
You can go here: https://github.com/torvalds/linux/ and search for Kconfig files (There are at this moment 1021 Kconfig files)
But clearly if you do not know where to search, for example if you are looking for CONFIG_INSTRUCTION_DECODER, from the kernel source tree run: grep INSTRUCTION_DECODER $(find -name Kconfig)
But INSTRUCTION_DECODER is not really a good example since there is no associated help section with that option...
Related
I feel like I have done my level best to search for an answer for this but, admittedly, maybe I am not using the correct search keys.
I am building a Linux kernel using Yocto and I can see that adding lines IMAGE_INSTALL_append to local.conf, followed my the additional images that you want to include is the way that you include things like connman, dropbear, etc. That's fine.
What I want to do is include an image of the application that I have written. Let's call it HelloWorld.exe and I would like it to be tucked into it's own directory (MyHello) along with a sub-directory and the sub-directory also contains some files that are necessary for the operation of HelloWorld.
I'm sure that there are different ways of doing this but I just need one. I need to know:
Where do I position my HelloWorld.exe and its attendant files and subdirectories on my Ubuntu system where they will be picked up during the build and included in the image?
How do I alter local.conf to ensure that the final image will include my application and its support files and directories where I need it to be on the target?
Thank you. Mark
I believe it gets a bit complicated in Yocto:
You need to create your own layer. Let's say meta-hello. This folder needs to in the same place as all your other meta layers and also where your poky directory is.
You need to enable that layer in your bblayers.conf file. For that you can use bitbake-layers add-layer /path/to/meta-hello
Now within your meta-hello create a recipe in a folder recipes-hello/hello
your hello.bb file is within the above mentioned folder and your can decide to use either automake, makefile or compile it accordingly using the Dev Manual Here
Once that is done, in your BUILD dir perform bitbake hello and this will compile and provide errors if any. Resolve them and once it compiles successfully, add IMAGE_INSTALL_append = " hello" in the local.conf file.
This is one way of doing it. Another one is a bit complex using the ADT Yocto Workflow
Sorry to say there is no easier way around this as Yocto does have a steep learning and development curve.
Practical Example
You can look at this blog post by Boundary Devices which creates a simple daemonize automake example. You can find it on GitHub too.
devtools workflow
Youtube Video by Tim Orling from Intel on devtools workflow
packing external binaries
For this case use Binaries Installation in Mega Manual
When I run cmake with some projects such as caffe or gflags, it writes some information at the system level. Specifically, on a linux system, it generates some directories such as $HOME/.cmake/Caffe and $HOME/.cmake/gflags
My problem is that this information is hereafter used for any project I compile. As a consequence, the programs referenced in $HOME/.cmake are (partially) found, even if I do not want it (as far as I am concerned, I define external variables to control with external programs cmake is allowed to consider for a given compilation).
y current solution is to delete the directory $HOME/.cmake when needed (i.e before compiling my new program). I consider to add a rm -rf $HOME/.cmake in .bashrc but this not fully satisfactory (nor sophisticated!). Could anyone propose a better solution ?
NB: the expression "system cache" in the question is probably wrong. I would be grateful to get a better term. Thank you for any feedback on this (actually, if I knew the correct expression, I may have already found the solution on the web...)
Edit:
Once you know the "system cache" is actually the User Package Registry the answer is easy. See below...
The directory $HOME/.cmake is the User Package Registry. To avoid find_package() to search in this directory, use option NO_CMAKE_PACKAGE_REGISTRY. See point 6 of its documentation:
https://cmake.org/cmake/help/v3.0/command/find_package.html
I saw that there is a lua plugin for eclipse and there is a docpage on the awesome main page api_doc and all the .lua files in /usr/share/awesome/lib.
So I thought it must be possible to create a Library or Execution Environment so that one has tabcompletion and docview.
So I tried making my own Execution Environment:
wrote the standard .rockspec file
downloaded the documentation made an ofline version of it and put it in docs/ folder
ziped the files and folders in /usr/share/awesome/lib
ziped all up
tried it out ... and it failed.
When I try to view a documentaion for a .lua file I get "Note: This element has no attached documentation."
Questions: Am I totaly wrong in my doing (because I have the feeling I am)? Is there any way to edit the rc.lua with tabcompletion and docview?
Koneki will probably take a while to setup, but it's definitly worth it. Going for the".doclua"(by using version 1.2) would certainly make it, but I doubt that using a script to generate the information you need, would work out on the long run.
Most likely, you'll probably pass a bit of time to define what kind of object you're dealing with every time you come across one. The right to do, would be to actually take the time to see if the object/module/inner type inherit from an another object, so can actually have more completion feature as you keep using autocomplete to go from one object to another by pressing "dot"+ctrl_space.
In an ideal world, one person could probably make it right and share to other, so they can enjoy a full featured autocomplete editor.
Found solution for eclipse.
First off the idea of setting up an Execution environment was the wrong one.
So the whole thing about downloading the doc although.
For more information on that visit eclipse Wiki for LUA Development Tool.
The right thing to do is to add a source folder which contains the /usr/share/awesome/lib directory.
The bad news is that my comment from above was totally right, which means one has to configure each .lib file in /usr/share/awesome/lib to meet the requirements of the Documentation Language described here.
Than editing the rc.lua (which one can add to the project in eclipse) works with tabcompletion and doc view.
Since the Documentation Language used in the lib files is similar to the one used by "LUA Development Tool" one has not to change many things. Maybe there are even scripts for that.
Where do I write a manual entry when creating a deb package? Is there any formatting rule/best practice to respect?
I'm very new to deb package creation. Following some tutorials, I just created a package that installs/executes nicely, so now I'd like to write some documentation so that man myFancyPackage returns something instead of no manual entry for myFancyPackage.
Unfortunately none of the tutorials I found speak about manual creation.
There are lots of methods to build a Debian package, but the current "best practice" is to use the tools provided by Debhelper. In the case of man pages, there is a tool named dh_installman (read its manpage) that is called automatically by dh. If you used dh_make or similar to create a template for your package, then a dh invocation will be in your debian/rules file.
dh_installman works by reading the file debian/manpages, or debian/nameofyourpackage.manpages. This file has a list of paths pointing to the man pages of your package. The paths are relative to the root of your package. Here you have an example of a real package. Then, this program will properly install your man pages in the right directory.
So, to sum up, you only have to create the debian/package.manpages and fill it with the paths to your man pages. These paths have to be relative to the root of your package. If you, the packager, are writing the man pages, then they have to be placed in the Debian/ directory.
Man pages were traditionally composed in a typesetting language called roff using a macro package called an (so the command line was roff -man, sic) but few people write raw roff anymore.
There are various SGML and XML documentation formats which have the capability to generate man page sources, though in this day and age, Markdown is probably gaining ground as the de facto standard for new documentation. The top Google hit for me is https://github.com/remarkjs/remark-man though I would definitely also suggest you look at pandoc.
# NAME
Markdown - popular text markup language
# SYNOPSIS
man markdown
# DESCRIPTION
This is a popular lightweight syntax
to generate styled text from an
editor-friendly text source.
It is used on [Stack Overflow][1],
[Github][2], and increasingly on
blogging and authoring platforms.
[1]: https://stackoverflow.com/
[2]: https://github.com/
I'll also mention POD format, which has a long history in the Perl community, and many features in common with popular, more recent lightweight formats. Unless you have other reasons to like it, I would not choose it for new documentation, but it used to be moderately popular even far outside the Perl world back when it was one of the only options with a simple human-readable source format, obvious semantics, and a versatile and well-maintained toolchain and support ecosystem. Some would probably say it still is.
=head1 NAME
Pod::Example - Example POD document
=head1 SYNOPSIS
pod2man thisdoc.pod >thisdoc.1
=head1 DESCRIPTION
Lightweight syntax for subheads,
hyperlinks, indented lists,
and not much else.
Natively supported in Perl source files
to facilitate a crude form of
literate programming.
I'm trying to write a configure.ac file such that the resulting configure script searches for a library directory containing a given static library e.g. libsomething.a. How can I do this? At the moment I have it check just one location with:
AC_CHECK_FILE([/usr/local/lib/libsomething.a],[AC_SUBST(libsomething,"-L/usr/local/lib -lsomething")],[AC_SUBST(libcfitsio,'')])
But I want it to try and find it automatically. And if the library isn't in one of the default locations, I'd like configure to say that the library wasn't found and that a custom location can be specified with --use-something=path as is usually done. So I also need to then check if --use-something=path is provided. I'm pretty new at creating configure files, and the M4 documentation isn't very easy to follow, so would appreciate any help.
Thanks!
It's not the job of configure to search where libraries are installed. it should only make sure they are available to the linker. If the user installed them in a different location, he knows how to call ./configure CPPFLAGS=-I/the/location/include LDFLAGS=-L/the/location/lib so that the tools will find the library (this is explained in the --help output of configure and in the standard INSTALL file).
Also --with-package and --enable-package macros are not supposed to be used to specify paths, contrary to what many third-party macros will do. The GNU Coding Standards explicitly prohibit this usage:
Do not use a --with option to
specify the file name to use to find
certain files. That is outside the scope
of what --with options are for.
CPPFLAGS and LDFLAGS are already here to address the problem, so why redevelop and maintain another mechanism?
The best way to figure this out is to look at other autoconf macros that do something similar. Autoconf macros are an amalgam of Bourne shell script and M4 code, so they can literally solve any computable problem.
Here's a link to a macro I wrote for MySQL++ that does this: mysql++.m4.