say I have the Makefile
p5: p5.py
. ${SRCDIR}/$^
%.py: clean
spark-submit ${SRCDIR}/$# ${SPARK_OPTS}
How can I have p5 run without calling the default rule for *.py files?
If the default rule your are mentioning is the %.py: rule, then you can simply add an empty rule for p5.py:
p5: p5.py
. ${SRCDIR}/$^
p5.py:;
%.py: clean
spark-submit ${SRCDIR}/$# ${SPARK_OPTS}
Related
I apologize in advance for my lack of experience with m4sh.
I have a configure.ac file containing the following lines:
AC_INIT([libhelloworld], [2.5])
...
AC_OUTPUT([
Makefile
src/helloworld-${PACKAGE_VERSION}.pc
src/Makefile
])
The reason behind the argument of AC_OUTPUT() is that I would like to avoid to copy and paste the new version of my program in multiple places on every update. Therefore I decided to exploit the PACKAGE_VERSION macro, automatically defined when invoking AC_INIT() at the beginning of configure.ac.
The line src/helloworld-${PACKAGE_VERSION}.pc then correctly expands into src/helloworld-2.5.pc and everything seems to be working fine. However I have a couple of questions.
I use ${PACKAGE_VERSION} as a shell variable, but PACKAGE_VERSION itself is a m4 macro. Can I trust that this will always work? Will it always be defined as such when AC_OUTPUT() is invoked?
Are there other ways of obtaining the value of PACKAGE_VERSION within configure.ac? For example, if instead of configure.ac I were inside Makefile.am I would not use the curly brackets, but the command evaluation syntax instead, as in $(PACKAGE_VERSION). What is the proper correct way of doing what I want within configure.ac?
The documentation for AC_INIT states that PACKAGE_VERSION is an "output variable", meaning when you call AC_INIT, something like this gets executed:
AC_SUBST([PACKAGE_VERSION], [2.5])
This allows the configuration of input files such as Makefile.in (generated from Makefile.am) to rely on #PACKAGE_VERSION# inside those files being replaced by 2.5.
There's nothing wrong with your approach if it works, but you might consider using AS_VAR_SET([hello_version], [AC_PACKAGE_VERSION]) to set the hello_version shell variable and src/helloworld-${hello_version}.pc in Autoconf input. This way, even if Autoconf no longer exposes a PACKAGE_VERSION shell variable in some future release, your code won't break because you'll be relying upon your own hello_version variable.
As an aside, it's a bit irregular to use helloworld-2.5.pc when the helloworld version is 1.0 or greater (i.e. the API is stable). It's common to see helloworld.pc, except then there's the problem of what happens when you release 3.0 and replace the installed 2.x version of helloworld.pc with the 3.0 version: assuming you're using semantic versioning, 3.0 is incompatible with 2.x, and any code relying on something like pkg-config --libs helloworld will break.
You might then consider using helloworld-2.pc instead and when you release 3.0, you'd instead have helloworld-3.pc to avoid users of your library linking the incorrect/incompatible library (and also allowing users the option of moving to the new version at their own pace); one can also apply this idea in Automake for a version-specific header directory:
## SOURCE PATH => INSTALL PATH
## include/hello.h => $(includedir)/helloworld-2/hello.h
helloincludedir = #includedir#/helloworld-#hello_major#
helloinclude_HEADERS = include/hello.h
Autoconf also allows you to specify an output file's inputs, so an output file src/helloworld-${hello_major}.pc in the build directory could be generated from src/helloworld.pc.in in the source directory without you needing to update the src/helloworld.pc.in filename when moving from 2.x to 3.0; this could also be used with AC_INIT if you're OK with macros, allowing you to control the version info in one central location:
m4_define([hello_version_major], [2]) dnl
m4_define([hello_version_minor], [5]) dnl
m4_define([hello_version], [hello_version_major[.]hello_version_minor]) dnl
AC_PREREQ([2.69])
AC_INIT([libhelloworld], [hello_version])
AS_VAR_SET([hello_major], [hello_version_major])
AS_VAR_SET([hello_minor], [hello_version_minor])
# For automake and configuration of pkg-config file
AC_SUBST([hello_major])
AC_SUBST([hello_minor])
AC_SUBST([hello_version])
...
AC_CONFIG_FILES([
Makefile
src/Makefile
src/helloworld-]hello_version_major[.pc:src/helloworld.pc.in
])
AC_OUTPUT
I realize it looks surprisingly more complicated than one might expect, but that's Autoconf for you. Note that I had to use some odd quoting in AC_CONFIG_FILES to make use of the macro. Using
src/helloworld-${hello_major}.pc:src/helloworld.pc.in
instead of the macro resulted in a crippled config.status file being generated in Autoconf 2.69 (try config.status with no arguments, then config.status src/helloworld-2.pc to see the issue); I haven't tested any other versions. I've reported the bug, but the macro works until the next release.
I am working to build an own "embeeded linux" with yocto. It is based on the SAMA5D3x-MB + SAMA5D3x-CM(RONETIX) with the SAMA5D35. I have two questions:
1.) changing the device tree
I build an image based on: MACHINE ??= "sama5d3xek"
After the generating process I found two device tree files for the 5D35 in the deploy dir:
zImage--4.1+git0+19291d7be4-r0-sama5d35ek-.dtb
zImage--4.1+git0+19291d7be4-r0-sama5d35ek-revc-.dtb
Because the mainboard is revD I am using zImage--4.1+git0+19291d7be4-r0-sama5d35ek-.dtb.
In this file only can0 and i2c1 are defined.
I like to use can1 and i2c0 as well. For that I think I need to create a own dts file and include it into the kernel build process.
So far I put the dts file at my meta-test recipe. Ideas how to copy/patch it into the kernel?
2.) changing the kernel config
I checked the kernel with
bitbake virtual/kernel -c menuconfig
because I am not using the SAMA5D2 etc. and only the console I deactivated these kernel configs. I saved the new ".config" to "my.config" into the my-recipe dir. I have a similar question like in 1 - How to patch/copy it into the kernel?
I am new to yocto and to kernel hacking. Any idea how to do it?
If you're on a recent Yocto project release, you can make use of recipetool to do most of the legwork on this. You have two options, you can use the existing recipetool commands and a small amount of manual work, or you can use the recipetool plugin in meta-mentor that provides a few kernel-specific commands to do this for you.
Layer setup
First, you'll want to have a layer to store your changes. If you've already created a layer, you can use that, otherwise we can create one and add it to our configuration:
$ yocto-layer create local 1
$ bitbake-layers add-layer meta-local
Option one: Using the recipetool plugin from meta-mentor
Setup
First, clone meta-mentor:
$ git clone https://github.com/MentorEmbedded/meta-mentor
Next, either add meta-mel to your configuration:
$ bitbake-layers add-layer path/to/meta-mentor/meta-mel
Or copy meta-mentor/meta-mel/lib into your own layer:
$ cp -a path/to/meta-mentor/meta-mel/lib meta-local/
Device tree
$ recipetool kernel_add_dts meta-local /path/to/your.dts
Kernel configuration
$ recipetool kernel_add_fragments meta-local /path/to/your.cfg
Or:
$ recipetool kernel_set_defconfig meta-local /path/to/the/defconfig
Option two: Manual
In the below section, clearly in your case, your-machine-name should be sama5d3xek. The '-m your-machine-name' passed to the recipetool commands below makes the changes in the recipe specific to your machine, rather than affecting any machine which uses that recipe. If you know that recipe is only used for your machine, then you could drop that, but it's safest to keep it, as some BSP layers use the same kernel recipe for multiple machines. For example, linux-yocto is used for many.
Device tree
Then, assuming you have a .dts handy you want to use:
$ recipetool appendsrcfile -wm your-machine-name path/to/meta-local virtual/kernel /path/to/your.dts 'arch/${ARCH}/boot/dts/your.dts'
This will create a .bbappend in meta-local and add the .dts to SRC_URI, placing it in the appropriate path in the kernel source tree. The next step is to edit the append it created and add the .dtb for your .dts to the KERNEL_DEVICETREE variable, i.e.:
KERNEL_DEVICETREE += "your.dtb"
If the kernel recipe includes recipes-kernel/linux/linux-dtb.inc, any .dtb files in KERNEL_DEVICETREE will be created from their .dts files by using the kernel's buildsystem. Some kernels do not include linux-dtb.inc, in which case you can do so yourself in the append:
require recipes-kernel/linux/linux-dtb.inc
Kernel configuration
The kernel configuration is slightly more complex, just because how the configuration is done varies slightly between kernel recipes. Some kernel recipes support configuration fragments (which are just a text file with part of a defconfig/.config), whereas others you'd have to override the configuration entirely. The 'linux-yocto' recipe can handle and use fragments, as can a few others.
To see what kernel recipe you're using (the top filename will be the one used):
$ bitbake -e virtual/kernel | grep '^FILE='
If you want to use configuration fragments, you can either manually create a fragment, or generate one:
$ bitbake -c menuconfig virtual/kernel
$ bitbake -c diffconfig virtual/kernel
The 'diffconfig' task will create a fragment with your changes from the menuconfig and print the path to it.
Then you can add it to the kernel (though again, only certain recipes will use it):
$ recipetool appendsrcfile -wWm your-machine-name meta-local virtual/kernel /path/to/your.cfg
To override the entire config, most recipes will obey and use a 'defconfig' source file, so:
$ recipetool appendsrcfile -Wm your-machine-name meta-local virtual/kernel /path/to/the/defconfig
Note: The defconfig is not generated automatic. Replace defconfig with the result of menuconfig('.config').
The devtool can be very handy if you want to generate patches for the linux-yocto kernel. Other kernel might not support devtool.
## create kernel source patch
devtool modify virtual/kernel
# make some changes
cd ~/poky_sdk/workspace/sources/linux-yocto
vi init/calibrate.c
# test before patch
bitbake -C compile virtual/kernel
# create patch
git add .
git commit -m 'some fix'
devtool update-recipe -a ~/meta-mylayer/ linux-yocto
# clean the source
rm -rf workspace/sources/linux-yocto/
see devtool for details
Related to this question, for educational purposes I tried to add a device tree to an x86 architecture (kernel 5.2.20). To enable the device tree compiler, the following additions to the configuration were needed :
CONFIG_COMPILE_TEST=y
CONFIG_OF=y
CONFIG_OF_ALL_DTBS=y
Furthermore, to enable device tree support at runtime, this was additionally needed :
CONFIG_OF_UNITTEST=y
A convenient place to check if your kernel configs are merged without problems is file
kernel-source/.kernel-meta/cfg/merge_config_build.log
I am trying to port a new module into my project. The module has its own make file. I have no background or experience with the make build system, so I decided to use the following command:
make -f Makefile -f ../newmodule/tbt/makefile
But I get the following errors:
../newmodule/tbt/makefile:14: make/macros.mk: No such file or
directory
../newmodule/tbt/makefile:66: *** target file `all' has both : and :: entries. Stop.
Please correct me if I am wrong; it is my understanding that my first error is because I issued make from my main project, and I need to somehow configure it to look into the directory of ../newmodule/tbt/make to find macros.mk. Would anyone be able to suggest an effective way of addressing this issue? What is the best way to include the contents of ../newmodule/tbt/make folder?
My 2nd error seems to be exactly what make complains about, which is having : and :: in the two make files for the target "all". I can not follow the 2nd make file very closely, but there is not much to the lines that have this target. I am thinking of changing it to My_all, and configure this new variable as the default target of the new module. I am not even sure if my terminology is correct. "all" is called the default target for make right? I have reviewed most of the make file document, but it is 5 am, and I do not recall some things.
I came across this error during compilation of some package under OpenWrt. The problem was in the VERSION declaration in the Makefile.
So, check if you have declared anything with unnecessary spaces or comments after some variable.
Removing the comment or space after variables should work.
Try running two separate make -f myMakefile commands, one from each module directory so that the relative paths work out properly as you have already observed that you current directory when executing make may be part of the problem.
I'm trying to create a libxerces package for OpenWrt. Following the instructions from this site http://wiki.openwrt.org/doc/devel/packages, I created a folder called libxerces-c inside the packages directory and a simple Makefile to have the package listed on make menuconfig, but it's not happening.
The Makefile is defined as the following:
#
# Copyright (C) 2006-2013 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
#
include $(TOPDIR)/rules.mk
# Name and release number of this package
PKG_NAME:=xerces-c
PKG_VERSION:=3.1.1
PKG_RELEASE:=1
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://apache.mirror.pop-sc.rnp.br/apache//xerces/c/3/sources/
PKG_CAT:=zcat
include $(INCLUDE_DIR)/package.mk
# Specify package information for this program.
# The variables defined here should be self explanatory.
define Package/libxerces
SECTION:=libs
CATEGORY:=Libraries
TITLE:=Validating XML parser written in a portable subset of C++.
URL:=http://xerces.apache.org/
endef
define Package/libxerces/description
Xerces-C++ is a validating XML parser written in a portable subset of
C++. Xerces-C++ makes it easy to give your application the ability
to read and write XML data. A shared library is provided for parsing,
generating, manipulating, and validating XML documents. Xerces-C++ is
faithful to the XML 1.0 recommendation and associated standards (DOM
1.0, DOM 2.0, SAX 1.0, SAX 2.0, Namespaces, XML Schema Part 1 and
Part 2). It also provides experimental implementations of XML 1.1
and DOM Level 3.0. The parser provides high performance, modularity,
and scalability.
endef
CONFIGURE_ARGS+= --host=mips-openwrt-linux
define Build/Configure
$(call Build/Configure/Default)
endef
define Build/Compile
$(call Build/Compile/Default)
endef
define Package/libxerces/install
endef
$(eval $(call BuildPackage,libxerces))
I already tried to execute the install script
./scripts/feeds install libxerces-c
But nothing happened. I still can't see the package after executing make menuconfig.
You need to
add the feed with the package to your feeds.conf.default or create a feeds.conf
then ./scripts/feeds update -a (update all feeds... you could just set the feed's name instead of using -a)
then ./scripts/feeds install foobar
[...]
... You obviously called install on libxerces-c while your package is called libxerces?
Probably you are not still searching for it but here is the answer.
For your package to appear in the menuconfig TUI you need to add the following
option to you Makefile inside the define Package clause:
MENU:1
Thus this part of your Makefile will look like:
define Package/libxerces
SECTION:=libs
CATEGORY:=Libraries
TITLE:=Validating XML parser written in a portable subset of C++.
URL:=http://xerces.apache.org/
endef
can you do a make menuconfig, and see if any error message about your package 'libxerces' is shown. My setup for custom packages is something like:
mkdir package/custom
mkdir package/custom/
ln -s /path/to/package/libxerces/ package/custom/
If your makefile is correct, then Libraries->libxerces should appear in menuconfig, if not an error message should be printed on make/make menuconfig. You will be able to do make package/libxerces/compile etc. also. Note: your package name is libxerces not libxerces-c.
I have made some trivial modifications to a Linux USB Wi-Fi card driver to insert some logging (printk statements). I am loosely following a guide on how to recompile/load the module, which states that I need to execute make in order to build the .ko file. There is an existing Makefile in the working directory (/usr/src/linux/drivers/net/wireless/rtl818x/rtl8187/), which reads:
rtl8187-objs := dev.o rtl8225.o leds.o rfkill.o
obj-$(CONFIG_RTL8187) += rtl8187.o
ccflags-y += -Idrivers/net/wireless/rtl818x
When I execute make inside this directory, I get:
make: *** No targets. Stop.
According to this, this means "that some makefile was found, but it didn't contain any default goal and none was given on the command line. GNU make has nothing to do in these situations."
So my question is, what does this mean in the context of what I am trying to do, and how do I go about generating the .ko file which I am purported to need for the next step?
You must run make from the top directory of the Linux source (/usr/src/linux/). Be sure that your driver is included in your /usr/src/linux/.config file. So, build the kernel with your driver.
If you don't want to rebuild the entire kernel, read more :)
If you want to re-build all modules inside the directory:
make M=drivers/net/wireless/rtl818x/rtl8187/
If you want to re-build a single module inside the directory:
make M=drivers/net/wireless/rtl818x/ CONFIG_RTL8187=m
The *CONFIG_RTL8187* name can be found in drivers/net/wireless/rtl818x/Kconfig (CONFIG_ + RTL8187)
It should works also this:
make drivers/net/wireless/rtl818x/rtl8187/rtl8187.ko