Here is a sample of my Makefile.
define Package/luci-app-myapp
SECTION:=luci
CATEGORY:=LuCI
SUBMENU:=3. Applications
TITLE:=GUI for myapp package
PKGARCH:=all
DEPENDS:=+myapp
endef
What is the exact role of the DEPENDS in this Makefile?
And what elements can be the value of the DEPENDS?
DEPENDS is basically a variable. In openwrt this variable is used to define dependency between the packages.
Detailed use of this variable is documented in openwrt link
Related
As Bitbake builds -dev and -debug for recipes is it possible for defining compilation definitions specific to debug build for a particular recipe. Lets say I have some source code under DEBUG_INFO for some recipe i.e.,
#ifdef DEBUG_INFO
........... do something
#endif /* DEBUG_INFO */
and uses cmake in bitbake environment.
I want this flag be enabled for the debug binaries generated in the .debug folder. Is this possible?
If I use EXTRA_OECMAKE = "-DDEBUG_INFO" it gets enabled to both dev and debug builds.
No, it is not possible. All packages of a recipe are built in one go, they're just the same files but split somehow.
The only difference is with "special flavors" of a recipe (native, nativesdk, target, multilib, toolchain-specific recipes, etc...), in that case, you can have different flags but still, all the packages resulting from the build of this "flavor" will be built with the same flag.
If you want to build another variant of a package where a certain CMake flag is set in the compilation, you can create a variant of the recipe. If the main recipe is named my-app_git.bb you can create another recipe file named my-app-tweak_git.bb and a common base, my-app.inc. In the bb files, include the inc file:
require my-app.inc
Move most of what's now in my-app_git.bb to my_app.inc, e.g. SRC_URI, but define different contents for EXTRA_OECMAKE in the .bb files.
Now you will have to decide which one of my-app and my-app-tweak goes into the image by specifying either my-app or my-app-tweak in an IMAGE_INSTALL definition.
This is not exactly what you asked for, but as has been stated by qschulz, you cannot change the contents of the -dev and -dbg sub-packages.
Also note that dbg and dev can be considered reserved words for variants of the package name, so if you want to use something other than tweak, as in my example, you cannot use any of them.
While adding custom packages, package A is using Makefile variable that needs to be updated (or not) by other package B, however package B is not mandatory for compiling package A. In other words, if configuration selects package B in that case shared Makefile variable be populated and values can be seen by other packages.
Package A
$(variable1)
package B
variable1 := "-Dxyz -Dabc"
I tried with setting empty "variable1" in rules.mk which is not working. Appreciate if anyone can point me existing examples for same.
I want to refer to a DirectX SDK in the BUILD file. The problem is that (as far as I understand) Bazel supports passing environment variables only through --action_env=DXSDK_DIR argument for Bazel and it is meant to be used in actions, which must be defined in a plugin (.bzl file).
Is there any easier way to refer to the environment variable by using it as Make variable (includes = [ "$(DXSDK_DIR)/Include" ]) or do I need to write a plugin?
In principle you need a cc_library rule whose hdrs attribute globs the DirectX headers. For that you need to pretend that the DX SDK is part of your source tree. Bazel offers "repository rules" for that purpose.
1. Create a repository rule for the DirectX SDK
Depending on whether the SDK's location is known or needs to be discovered, you have two options.
a. Fixed SDK location
You can use this approach if you don't need to read any environment variables, run any binaries, or query the registry to find where the SDK is. This is the case if everyone who builds your rules will install the SDK to the same location.
Just add a new_local_repository rule to your WORKSPACE file, point the rule's path at the SDK's directory and write a simple build_file_content for it.
Example:
new_local_repository(
name = "directx_sdk",
path = "c:/program files/directx/sdk/includes",
build_file_contents = """
cc_library(
name = "sdk",
hdrs = glob(["**/*.h"]),
visibility = ["//visibility:public"],
)
""")
This rule creates the #directx_sdk repository with one rule in its root package, #directx_sdk//:sdk.
b. SDK discovery
You need to follow this approach if you need to read environment variables, run binaries, or query the registry to find where the SDK is.
Instead of using a new_local_repository rule, you need to implement your own. More info and examples are here.
Key points:
if your repository rule needs to read environment variables, add them to the list repository_rule(environ), e.g. repository_rule(..., environ = ["DXSDK_DIR"])
if you need to run some binaries that tell you where the SDK is, use repository_ctx.execute. You can use repository_ctx.which to find binaries on the PATH.
if you need to do registry queries, use repository_ctx.execute with reg.exe /query <args>
2. Depend on the SDK's cc_library
In your project, just depend on the SDK's library as if it was an ordinary cc_library:
cc_library(
name = "render",
...
deps = [
...
"#directx_sdk//:sdk",
],
)
I have a project where there's only a handful of logical groupings for generating static libraries. However for convenience I want to have the library's source code to be managed with more granular folders.
Currently the only way I know to do this in CMake without having a library for each folder is to just list files as you would normally in with their relative paths:
add_library(SystemAbstraction STATIC "Some/Path/File.cpp")
However I can see this getting unwieldy as the project grows in size with all the different paths.
I tried to see if I could have a CMakeLists.txt in each folder and just use a variable in the base CMakeLists.txt when adding library dependencies. But it seems that add_subdirectory doesn't also import variables?
For expanding the scope of a variable inside a subdirectory, use the PARENT_SCOPE option of set. For example, you can test that if you have
# CMakeLists.txt
set(SRCS main.c)
add_subdirectory(foo)
message(${SRCS})
in the root directory and
# foo/CMakeLists.txt
set(SRCS ${SRCS} foo.c PARENT_SCOPE)
in a subdirectory then it will print main.c foo.c, i.e., the variable is correctly imported into the base CMakeLists.txt.
An option would be to use the object library feature of CMake. You still can but doesn't need to organise your CMake script into subdirectories:
add_library(lib1 OBJECT <srcs>)
add_library(lib2 OBJECT <srcs>)
...
add_library(mainlib $<TARGET_OBJECTS:lib1> $<TARGET_OBJECTS:lib2>)
You can set different compile flags for each object library:
target_include_directories(lib1 PRIVATE incl-dir-for-lib1)
target_compile_definitions(lib2 PRIVATE def-for-lib2)
You still need to set link libraries on your main library:
target_link_libraries(mainlib PRIVATE deps-of-lib1 deps-of-lib2)
Related documentation: Object Libraries
I am trying to add a package for directfb tutorials. I followed the instructions in http://wiki.openwrt.org/doc/devel/packages.
Currently the package is downloaded successfully to the dl folder and even compiled in the build directory, but when I add the install section to the makefile I get dependency error:
Package directfb_tutorials is missing dependencies for the following libraries:
libdirect-1.4.so.0
libdirectfb-1.4.so.0
libfusion-1.4.so.0
libpthread.so.0
The package Makefile (I put it under package/utils/directfb_tutorials/):
include $(TOPDIR)/rules.mk
PKG_NAME:=DFBTutorials
PKG_VERSION:=0.5.0
PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://www.directfb.org/downloads/Extras/
PKG_MD5SUM:=13e443a64bddd68835b574045d9025e9
PKG_LICENSE:=LGPLv2.1
PKG_LICENSE_FILES:=COPYING
PKG_FIXUP:=autoreconf
PKG_INSTALL:=1
include $(INCLUDE_DIR)/package.mk
define Package/directfb_tutorials
TITLE:=directfb_tutorials
SECTION:=utils
CATEGORY:=Utilities
URL:=http://directfb.org
DEPENDS:=+libdirectfb
endef
define Package/directfb_tutorials/description
DirectFB Tutorials
endef
define Build/Configure
$(call Build/Configure/Default,)
endef
define Package/directfb_tutorials/Build/Compile
$(MAKE) -C $(PKG_BUILD_DIR)
endef
define Package/directfb_tutorials/install
$(INSTALL_DIR) $(1)/bin/dfb_tutorials
$(INSTALL_BIN) $(PKG_BUILD_DIR)/src/image/image $(1)/bin/dfb_tutorials/
$(INSTALL_BIN) $(PKG_BUILD_DIR)/src/simple/simple $(1)/bin/dfb_tutorials/
$(INSTALL_BIN) $(PKG_BUILD_DIR)/src/keybuffer/keybuffer $(1)/bin/dfb_tutorials/
$(INSTALL_BIN) $(PKG_BUILD_DIR)/src/text/text $(1)/bin/dfb_tutorials/
$(INSTALL_BIN) $(PKG_BUILD_DIR)/src/sprite/sprite $(1)/bin/dfb_tutorials/
endef
$(eval $(call BuildPackage,directfb_tutorials))
When adding +libpthread to the DEPENDS section, libpthread.so.0 does not appear in the missing dependencies error message above:
Package directfb_tutorials is missing dependencies for the following libraries:
libdirect-1.4.so.0
libdirectfb-1.4.so.0
libfusion-1.4.so.0
is because I must have used DEPENDS in a wrong manner (DEPENDS= +libdirectfb). How can I tell the correct name of the library for the DEPENDS flag? Is the fact that the library is installed to /usr/lib instead of just /lib (like libpthread) makes a difference?
Thanks in advance,
Tomer
The message about missing libraries comes from check fired from include/package-ipkg.mk. It is the latest stage of package creation. This check is verifying all executable files have all needed libraries available in the system. To enforce that, system requires you to add some entries in "DEPENDS" section. But before - you need of course to know, which one(s) to add.
To find missing library provider, if the case is not obvious (usually it is just a library name), you may search in $STAGING_DIR/pkginfo folder. In my case it is staging_dir/target-mips_mips32_uClibc-0.9.33.2/pkginfo.
Just cd to that folder and run something like:
grep libdirect-1.4.so.0 "*.provides"
You should see one or more results. Use common sense to pick the best one, usually it is a package named similar to the library, but not always. This is a generic way, should be helpful in case you miss the package in DEPENDS and cannot easily guess the correct one(s).
My guess is, that you should modify DEPENDS in your Makefile to contain
this:
DEPENDS:=+libdirect +libdirectfb +libfusion +libpthread
Look at the iftop core package for a syntax example:
https://github.com/openwrt/openwrt/blob/master/package/network/utils/iftop/Makefile#L28
It is the perfect example. The right syntax should be:
DEPENDS:=+libdirectfb +libpthread