Guidance building Elixir package for OpenWRT - makefile

I'm looking to compile an Elixir package for OpenWRT, but am new to building Makefiles for OpenWRT.
I'm not sure where to start and plan to start by scaling down the erlang Makefile (https://github.com/openwrt/packages/blob/master/lang/erlang/Makefile) and start with erlang as it's only dependency.
I have looked for a guide on getting started with OpenWRT Makefiles, but have not found one.
Would anyone be willing to guide me through the process?

First, read this manual: http://wiki.openwrt.org/doc/devel/packages
Basically, you will need to create <openwrt-dir>/package/elixir directory and create a Makefile there like this:
include $(TOPDIR)/rules.mk
PKG_NAME:=elixir
PKG_REV:=0e3c06b03149022b980e69872003d401c4788fea
PKG_VERSION:=v1.1.0-rc.0
PKG_RELEASE=1
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=https://github.com/elixir-lang/elixir.git
PKG_SOURCE_VERSION:=$(PKG_REV)
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_REV).tar.gz
PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
PKG_LICENSE:=GPL-2.0
include $(INCLUDE_DIR)/package.mk
define Package/$(PKG_NAME)
SECTION:=lang
CATEGORY:=Languages
TITLE:=Elixir
DEPENDS+= +erlang
endef
define Package/$(PKG_NAME)/install
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/bin/elixir $(1)/usr/bin
# copy other files that are needed on target
endef
$(eval $(call BuildPackage,$(PKG_NAME)))
Then, issue make menuconfig command and select your newly created package.
After that, compile by running make package/elixir/install V=s and look if it compiles (it does on my machine).

Related

GNU make - enforcing target order

Could someone please tell me if there is a way to enforce sequential execution of specific Makefile targets. For example, I have a Makefile that builds Libraries and Executables. Now, Executables depend on Libraries, so they must be built after the Libraries are built and staged. This is what I currently have in a single Makefile:
.PHONY: all
all: all_lib all_bin
.PHONY: all_lib
all_lib: $(dep_lib)
.PHONY: all_bin
all_bin: $(dep_bin)
I have two targets all_lib and all_bin, one builds all libraries and the other builds all binary executables. When I pass -j to make to run parallel jobs, I get build failures, because all targets run in parallel and binaries can't find shared library objects and staged header files.
I tried changing it to this to try and force some dependency order:
.PHONY: all
all: all_bin
.PHONY: all_lib
all_lib: $(dep_lib)
.PHONY: all_bin
all_bin: all_lib $(dep_bin)
But for some reason all targets still run in parallel I still get the same build failures. Any ideas?
Make is entirely built around the concept of dependencies. You are simply not using it that way.
If an executable depends on a library, then you should list that library in the prerequisites list of the executable. I can't give you a relevant example because you don't provide any details about the contents of dep_lib or dep_bin above, but for example:
exe1 : exe1.o liblib1.a liblib2.a
etc. Now, exe1 won't attempt to be linked until after the liblib1.a and liblib2.a targets have been created.

OMNET++ 5.1 opp_makemake

I installed OMNET++ 5.1 on my Ubuntu 16 OS and imported my project into the Eclipse IDE. But I can not compile my project as before. Make is giving me error:
make1: *** No rule to make target 'msgheaders'. Stop.
I have a folder called loggingWindow that has its own custom makefile and is excluded from the source.
But I noticed that the generated makefile is not correct:
The makefile is calling msgheaders and smheaders targets in the logginWindow folder. The loggingWindow is a completely separate application with its own makefile and has no idea about mshheader!
Also make clean does not work!
The clean window stuck without any progress:
As a temporary workaround, I have added phony targets (msgheaders, smheaders) in order to compile my project.
As a workaround you can add these targets to your own Makefile in logginWindow, for example:
msgheaders:
echo Do nothing
smheaders:
make all
# content from your existing Makefile
all:
...

Configure automake to install extra programs

My project is a library and automake is configured to build it and test it. There is also additional target which builds demo application for my library. It's defined in Makefile.am as EXTRA_PROGRAMS. I'd like to be able to install with make install or similar. Is there a way to do it but still keep optionality of this target (i.e. simply defining this target in bin_PROGRAMS will make this target required)?
The usual way to do this sort of thing is to have configure substitute the value into bin_PROGRAMS conditionally. In your Makefile.am this would look like:
bin_PROGRAMS = main-program $(test_program)
EXTRA_PROGRAMS = test-program
Then in configure.in you'd do something like:
if mumble; then
test_program=test-program
fi
AC_SUBST(test_program)

linux/module.h: No such file or directory

i'm a beginner and i'm trying out some basics of kernel programming in linux. Today morning i've opened the module.h file in VIM, and closed without saving any changes as well. After that i'm not able to compile any of my codes. I'm getting the following error message
[root#localhost helloworld]# cc helloworld.c
helloworld.c:1:25: error: linux/module.h: No such file or directory
[root#localhost helloworld]#
Here is a sample code which was running successfully till the last day.
#include<linux/module.h>
#include<linux/kernel.h>
int init_module(void)
{
printk("HELLO WORLD");
return 0;
}
void cleanup_module(void)
{
printk("GOODBYE");
}
I searched for the module.h file like the following and it do exist
[root#localhost usr]# find . -name module.h
./src/kernels/2.6.18-194.el5-i686/include/asm-x86_64/module.h
./src/kernels/2.6.18-194.el5-i686/include/asm-i386/module.h
./src/kernels/2.6.18-194.el5-i686/include/linux/module.h
./include/sepol/policydb/module.h
./include/sepol/module.h
./include/kde/kunittest/module.h
[root#localhost usr]#
Please help me out.
I'm using CentOS in virtual box.
You're trying to compile your module with plain gcc with none of the
surrounding kbuild framework. You might have gotten something to work in the
past with this approach, but it is painful horrible awful to try to maintain
a module using anything other than pure-kbuild Makefile approaches. I've
wasted too much of my life fighting against kbuild and I don't want the same to
happen with you -- embrace kbuild and let it help you build your module. Please
read Documentation/kbuild/modules.txt before writing another line of code.
What you need to do is create a Makefile for your module. Its contents should
look like this:
ifneq ($(KERNELRELEASE),)
# kbuild part of makefile
obj-m := modulename.o
else
# normal makefile
KDIR ?= /lib/modules/`uname -r`/build
default:
$(MAKE) -C $(KDIR) M=$$PWD
endif
I know it's a lot more complicated than most Makefiles you're used to seeing,
but it serves a dual-purpose. If you just run make in your directory, it'll
re-invoke make to use the kbuild mechanism from the currently-running kernel
(assumed to at least have a symlink from /lib/modules/.../build to the
correct location).
The re-invoked make command ($(MAKE)) will properly build your module and
save you more time than you can ever appreciate. (Really.)
Keep Documentation/kbuild/modules.txt by your side while making this work.
Note: Documentation/kbuild/modules.txt may be available at your linux system at /usr/share/linux-headers-$(uname -r)/Documentation/kbuild/modules.txt
Install the package kernel-devel:
yum install kernel-devel
After that, you should have:
/usr/src/kernels/$kernelversion/include/linux/module.h
You can then pass something like:
-I/usr/src/kernels/$(uname -r)/include
to the compiler
You may need a Makefile to compile your module.I have tried out on my personal computer(Ubuntu 10.04.4),I meet the same problem when I use gcc -c hello.c,but using a Makefile, everything will be OK.The kernel vesion is 2.6.32-54-generic

multi package makefile example for go

I'm trying to setup a multi package go project something like
./main.go
./subpackage1/sub1_1.go
./subpackage1/sub1_2.go
./subpackage2/sub2_1.go
./subpackage2/sub2_2.go
where main.go imports both subpackage1 and subpackage2. And subpackage2 imports subpackage1.
Ive been looking around for go makefile examples but I can't find anything that supports this kind of set-up. Any idea?
Install godag then run:
gd -o myapp
It will automatically build a Directed Acyclic Graph (DAG) of all the dependencies in your src/ directory, then compile and link each package in the proper order.
Much easier than manually maintaining a Makefile, especially since $(GOROOT)/src/Make.* has changed in recent versions of Go (there is no longer a Make.$(GOARCH)). Also useful:
gd clean removes object files.
gd -test runs your automated tests (see testing package).
gd -dot=myapp.dot generates a graph of your package imports you can visualize using GraphViz.
Something like this should work
# Makefile
include $(GOROOT)/src/Make.$(GOARCH)
all:main
main:main.$O
$(LD) -Lsubpackage1/_obj -Lsubpackage2/_obj -o $# $^
%.$O:%.go subpackage1 subpackage2
$(GC) -Isubpackage1/_obj -Isubpackage2/_obj -o $# $^
subpackage1:
$(MAKE) -C subpackage1
subpackage2:
$(MAKE) -C subpackage2
.PHONY:subpackage1 subpackage2
# subpackage1/Makefile
TARG=subpackage1
GOFILES=sub1_1.go sub1_2.go
include $(GOROOT)/src/Make.$(GOARCH)
include $(GOROOT)/src/Make.pkg
# subpackage2/Makefile
TARG=subpackage2
GOFILES=sub2_1.go sub2_2.go
include $(GOROOT)/src/Make.$(GOARCH)
include $(GOROOT)/src/Make.pkg
GC+=-I../subpackage1/_obj
LD+=-L../subpackage1/_obj
sub2_1.$O sub2_2.$O:subpackage1
subpackage1:
$(MAKE) -C ../subpackage1
.PHONY:subpackage1
If you don't install the subpackages you need to explicitly set the include path. The supplied makefile Make.pkg is mainly to build packages, which is why it's only included in the subpackage makefile.
hello world with a Makefile and a test (Googles Groupes : golang-nuts)
Check out https://github.com/banthar/Go-SDL which is an actively maintained multi-package go project using Makefiles.
I notice some of these the answers use the obsolete Make.$(GOARCH) include. So hopefully the above link will be stabler than trying to stay on top of Google's changing API in an answer here.

Resources