A question regarding "sentinels" in included make files.
I've inherited a project with a hierarchy of gmake projects, which uses make recursively. Due to the structure of the project, some files are included multiple times (once for each use of recursive gmake). These files are nothing fancy. Just variable definitions with some very basic if-logic. No recipes or dependencies. No nested includes.
The multiple-inclusion creates maintenance headaches. E.g. One can't use += in these files. I'd like to block multiple inclusions.
Putting a sentinel in the included files is the obvious solution, e.g.
ifeq ($(FOO_INCLUDED),)
FOO_INCLUDED=yes
else
# everything else
endif
But .... adding such a sentinel makes some recipes disappear in some sub-projects. E.g. a "build" target might disappear, while the "clean" target for the same sub-project doesn't. Make reports no egregious errors - it does attempt to run things. It just reports a missing target.
So the question is ... what could cause recipes being lost?
Restructuring to avoid the multiple includes is unfortunately not an option. Each sub-project is supposed to be buildable from either it's own folder (cd sub-project ; gmake build), or from the root folder (cd proj-root ; gmake subproject_build)
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 am working on a boot project. In my boot root directory there is a makefile that contains among other things, the following code which confuse me:
.DEFAULT_GOAL = all
.PHONY: all
all: xboot
xboot: $(TOP_DIR)/boot
#echo "Building Boot" $(TOP_DIR)
$(MAKE) -C $(TOP_DIR)/boot/src
Now, the problem is, that any time when this makefile is executed by calling make, the xboot receipt is always running. It seems that this xboot target acts like a phony target. From GNU Documentation regarding phony targets:
Phoniness is not inherited: the prerequisites of a phony target are
not themselves phony, unless explicitly declared to be so.
Means that xboot target is not a phony one, but it's receipt is always running. I could not find anywhere an explanation for that.
Project facts-
directory $(TOP_DIR)/boot contains sources and headers under $(TOP_DIR)/boot/src and $(TOP_DIR)/boot/include, directory $(TOP_DIR)/boot does not get touched at the build (it is not get updated)
Trying to understand the behavior I played around-
I tried touching $(TOP_DIR)/boot, and/or tried touching and creating file xboot file anywhere in the project, but behavior remains the same.
GNU Make 4.1
Built for x86_64-pc-linux-gnu
make is not always handling folder dependencies the way you expect.
Should use a file dependency inside $(TOP_DIR)/boot like $(TOP_DIR)/boot/.exists or, even better, all your source files with a $(wildcard ...) function.
Like:
xcode: $(widcard $(TOP_DIR)/boot/src/*.c $(TOP_DIR)/boot/src/*.h)
This will cause a rebuild only on code change.
In my current setting, I have some .mk that are automatically generated, over which I have no control. One of the rules defined in these files is clean.
The part of the code I am working on uses include to access variables from those .mk files. However, I'd like to have another rule clean to remove the files generated in the folder I am working on.
If I create a rule named clean, I get the warning
warning: overriding commands for target
Is there a way to "extend" clean, i.e., o make it run both the clean defined in those .mk files and my own clean?
Of course, I could create another rule other_clean and call the old clean. Or also I could do something like:
other_clean:
make clean
rm *.o
But I'd like to know if there is any functionality in make that allows me to "inherit" the recipe defined elsewhere into my own clean. I saw there are these things called double-colon rules, but I can't use them because the files I am including are automatically generated.
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.
Is there a way to exclude certain packages or source files when compiling in buildr? There isn't an exclude on the compile task as it looks in the src directory. We are building for multiple environments and for one of the environments we need to exclude a few source files otherwise it won't compile.
Any ideas?
thanks
compile.sources only contains the source directories and there is no way to tell buildr to exclude subdirectories directly from that. However, before compilation, buildr lists all the files in these directories to pass them on to the compiler (you can see this with buildr --trace compile). You could monkey-patch Buildr::Compiler::Base::files_from_sources to exclude some stuff, but that seems way too intrusive.
I would turn the problem upside down: instead of putting all the code in a single source directory, put environment-specific stuff in its own directory like so:
src/main/java
src/other-env/java
Most if not all IDEs support multiple source directories, so that should not be a problem.
Then define buildr projects for each of the environments by adding the appropriate source directory to the compilation path using compile.from (same for resources). If src/main/java compiles on its own, you could also separate that into its own project and have the others depend on it, thus avoiding having to recompile it over and over.
To make the build script simpler, think about making the various environments proper sub-projects.