I am autotoolizing a library project, and this project has some example programs. I want the example programs to be distributed in the dist, but not installed.
Currently the demo programs are organized like thus:
src/*.cpp (library source)
include/*.h (library headers)
demos/demo.cpp (example program)
demos/RunDemo (script to run demo)
It is important that RunDemo be runnable after building the software, without requiring the "install" step.
So far I have been able to build the "demo" exectuable using a noinst_PROGRAMS target. However, after make in a VPATH build, the following is available:
build/src/.libs/libxxx.so (etc..)
build/demos/demo
As you can see, the RunDemo script needed to execute "demo" is not copied to the $(builddir). I have tried a few things, e.g., adding RunDemo to dist_noinst_SCRIPTS, as well as adding my own copy targets and trying to hook all.. no matter what I try, I always get the output,
$ make RunDemo
make: Nothing to be done for `../../../projects/demo/RunDemo'.
I seem to be unable to create a target in the builddir that says "if this file is not in the builddir, copy it from the srcdir."
Is this possible with automake?
You can make files accessible in the build tree after the ./configure step using the AC_CONFIG_LINKS macro (provided with autoconf) in your configure.ac script. It will create a symbolic link if possible, otherwise it will copy the file.
In your case it would look like
AC_CONFIG_LINKS([demos/RunDemo:demos/RunDemo])
From the autoconf manual:
Macro: AC_CONFIG_LINKS (dest:source..., [cmds], [init-cmds])
Make AC_OUTPUT link each of the existing files source to the
corresponding link name dest. Makes a symbolic link if possible,
otherwise a hard link if possible, otherwise a copy. The dest and
source names should be relative to the top level source or build
directory
Using dist_noinst_SCRIPTS is still necessary for the file to be distributed.
Related
I have a mono-repository ("monorepo") that contains the C++ source code for my application, as well as a tree of OE/Yocto files and directories that form the bitbake recipes required to build my final image.
I wish to build and install my application into the image, but as far as I can tell, the Yocto philosophy is that source code is "fetched" (e.g. via git), from an external place, before it is built. But in my case the source code resides in the same repository. It doesn't seem to make sense to me that the entire repository is downloaded again, by bitbake, just to fetch the source for this application, so I'm looking for a better way.
I'm familiar with the idea of putting all the source in the files/ subdirectory, alongside the recipe itself. The issue I have with that is that I don't want to keep the source in the Yocto layer's recipe tree. It can be built with the SDK, for example, or even with other completely unrelated toolchains, so it should not be buried within a Yocto layer. It has its own life, outside Yocto.
I'm also familiar with the EXTERNALSRC directive, that can be used to "point" to the source code with a relative path from the build directory. For example:
EXTERNALSRC = "${TOPDIR}/../../src/myproject"
However, this is frequently not recommended as a "production" mechanism due to path issues, and it also disables devtool:
ERROR: externalsrc is currently enabled for the myproject recipe. This prevents the normal do_patch task from working. You will need to disable this first.
So I'm looking for a recommendation on how to handle compiling an application that resides in the same repository as the recipe, without putting it in files/.
EDIT: I tried something along these lines:
SRC_URI = "file://${TOPDIR}/../../src/myproject/main.c \
file://${TOPDIR}/../../src/myproject/Makefile \
"
This did not compile, but with devtool modify myproject I was able to see that it has in fact copied the source into the build directory. The problem is that it's replicated the entire directory structure from the root all the way up to the original source directory, so my source is now sitting in a location like this:
/home/david/monorepo/yocto/build/workspace/sources/myproject/home/david/monorepo/src/myproject
do_compile will need to determine and set that working directory before it will compile.
This means that the path will change depending on the user and the location of where they've checked out the monorepo. This almost works, but doesn't seem usable as-is. Is there a way to modify where bitbake's "file" fetcher puts the source when given an absolute path?
EDIT 2:
I may have found a way that works with bitbake and devtool:
FILESEXTRAPATHS_prepend := "${TOPDIR}/../../src/myproject:"
SRC_URI = "file://main.c \
file://Makefile \
"
This seems to set up the devtool directory in a much saner way (no replication of the directory tree, just symlinks to the files in oe-local-files/* directory), and the bitbake recipe also builds and installs correctly.
Is this the right way to do it?
EDIT 3: Perhaps not, as FILESEXTRAPATHS is only intended to be modified by .bbappend recipes, not base .bb recipes - any comment on that?
Best practices dictate that you accomplish this by using FILESEXTRAPATHS from within a .bbappend file [source].
EDIT 4: PierreOlivier suggests using a relative symlink in the files/ directory to the application's source directory, so that SRC_URI can find the source as if it was actually present in files/. From what I can tell with my own experiments, this does seem to work, and devtool works with this also.
Are there any implications of this approach that I should be aware of?
I've compiled PGO-instrumented build from A/src and collected the profile. Now I want to apply this profile when building from B/src. Is this possible? GCC complains about the lack of profile since absolute paths are different, but otherwise the code is exactly the same.
See the docs on -fprofile-prefix-path:
-fprofile-prefix-path=path
This option can be used in combination with profile-generate=profile_dir and profile-use=profile_dir to inform GCC where is the base directory of built source tree. By default profile_dir will contain files with mangled absolute paths of all object files in the built project. This is not desirable when directory used to build the instrumented binary differs from the directory used to build the binary optimized with profile feedback because the profile data will not be found during the optimized build. In such setups -fprofile-prefix-path=path with path pointing to the base directory of the build can be used to strip the irrelevant part of the path and keep all file names relative to the main build directory.
So when building from A/, set the prefix path to A/, and likewise for B/.
I want to build a file with GNU make on a machine which I have write permission only to the tmp directory.
When I try to build I get a permission error because MAKE is trying to put the object file in the build directory which I have no write permissions for.
is it possible to provide make a specific directory where to put the object files ?
Thanks,
Itay
is it possible to provide make a specific directory where to put the object files ?
If the makefile does not allow specifying a build directory you can copy (or symlink if possible) the sources into the destination directory and build there.
Autoconf-based projects normally allow this kind of usage.
It depends on where your make rules are coming from.
Usually, rules are written to be location independent: they are written such that whether the make command will work regardless of where the source files are. This is true for the built-in rules, but also for the rules in most Makefiles, if you got any.
In that case, all you need to do is copy or move everything into /tmp and run make there.
However, if you generated your Makefiles with a tool (e.g. a ./configure script, as used by GNU autoconf), the generation process may have introduced absolute paths, so you may need to redo the generation step(s) after copying everything to /tmp.
I am getting familiar myself to LLVM, and my goal is to implement a back-end for my custom processor.
Before I jump into my back-end implementation, I first try to learn how a build procedure works, so I first copy lib/Target/MSP430 to lib/Target/myproc, and build llvm targeting "myproc" (even though it actually is a back-end for MSP430, I did this just to learn how I can add a new target to LLVM).
When I configure/make llvm, I got the following error message.
...
/bin/cp: cannot stat `/mydir/build/lib/Target/myproc/Debug+Asserts/MSP430GenRegisterInfo.inc.tmp': No such file or directory
...
I checked /lib/Target/myproc, and saw there was only one file, Makefile, copied from /lib/Target/myproc.
Here is what I have done before I configure and make.
In my LLVM source directory, copy lib/Target/MSP430 to lib/Target/myproc.
Modify configure and projects/sample/configure to add "myproc".
Go to lib/Target/myproc and change "MSP430" to "myproc" in MSP430.td, LLVMBuild.txt, and Makefile (I also modify the files in subdirectories).
As the LLVM compile works for other targets on my machine, I believe it's not the problem of machine of tools that I am using, but the problem of my modification.
Am I missing something? Are there any further modifications that I am supposed to make?
There's a decent tutorial for writing backends here:
http://llvm.org/docs/WritingAnLLVMBackend.html
There's also this tutorial from a dev meeting:
http://llvm.org/devmtg/2012-04-12/Slides/Workshops/Anton_Korobeynikov.pdf
*GenRegisterInfo.inc comes from running tblgen on the target .td file. The .inc output file name depends on what the .td files are named in the myproc/ target directory.
It would be helpful to see more of your make log but my guess is that you're getting a tblgen error when processing .td files in myproc/. That tblgen error is the real problem you need to diagnose and address.
The following script is used to build a specific kernel module.
make modules M=net/sctp
After a second thinking, I've figured out that some of the options were not opened, which is
CONFIG_SCTP_DBG_OBJCNT=y
However, the file that the option control was still not compiled after a "make module" command. Do I need to make the whole kernel to let the option take effects?
All configuration options will be converted into macros and will be written to the file include/generated/autoconf.h once you did make command to build the kernel.
After this when you change any of the configuration option you again need to run the make command which generates required files to include this new configuration options. But if you just use the command "make M=/net/sctp modules" after you change your configuration it will not affect in the make. Instead of building whole kernel what you can do is, just run the "make modules" command which generates the required files and builds your module with the options that you selected. This is the best way which also resolves if there are any dependencies on your newly configured option.
But in your case, if you know that objcnt.c doesn't depend on any other things you can change the make file of the sctp to include your file.
vim net/sctp/Makefile
sctp-y += objcnt.o
Then you can run the "make M=net/sctp modules"
According to https://www.kernel.org/doc/Documentation/kbuild/modules.txt:
To build external modules, you must have a prebuilt kernel available
that contains the configuration and header files used in the build.
[..] use the make target modules_prepare. This will
make sure the kernel contains the information required. The target
exists solely as a simple way to prepare a kernel source tree for
building external modules.
vim .config
make modules_prepare
Answer any kconfig prompts as changes to .config may enable new options that were not manually configured previously.
make M=net/sctp