I have a building process that creates a header file. In the second stage, several source files are generated from that header file. Then these source files are built into a binary. If anyone is interested these sources are generated with gSOAP utilities (wsdl2h, soapcpp2).
I have made Makefile.am, etc to build these sources, but there are problems when I want to use parallel execution.
Makefile.am would look something like this in a very simplified form
## generate header file
service.h : service.wsdl
wsdl2h -o $# service.wsdl
## list of generated source files
generated_files = source1.cpp source2.cpp source3.cpp
## generate source files
$(generated_files) : service.h
soapcpp2 $^
## build binary
binary: $(generated_files)
gcc -o $# $^
The rules say that service.h will be generated if service.wsdl changes. If service.h changes, soapcpp2 will generate source?.cpp files with one command execution.
Everything works fine until I try to build in parallel (for instance make -j4). The problematic line is the last one which generates many soruce files. If running in parrallel all these files are generated many times, while other make processes already try to compile them.
I followed instructions to disable parallel https://www.gnu.org/software/make/manual/html_node/Parallel-Disable.html, but with no success. If I try
.NOTPARALLEL: $(generated_files)
or
.NOTPARALLEL: service.h
The parallel execution just does not work any more. I also tried with .WAIT, and got no rule to make target .WAIT.
First, the .WAIT special target was introduced in GNU make 4.4. Since you are getting a no rule to make target error for it, it's clear you're using an older version which doesn't support it. It's usually a good idea to include the version of whatever tool you're using when asking for help.
The best thing to do is not disable parallelism but instead tell make that a single invocation of the recipe will generate all the files. If you have GNU make 4.3, then you can use a "grouped target" rule, like this:
## generate source files
$(generated_files) &: service.h
soapcpp2 $^
the &: here tells make that instead of building each target with a different invocation of the recipe, which is the default, a single invocation of the recipe builds all the targets.
If you don't have GNU make 4.3 then you'll need to play a trick to get the same behavior, something like this:
## generate source files
.sentinel : service.h
soapcpp2 $^
#touch $#
$(generated_files) : .sentinel ;
## build binary
binary: $(generated_files)
gcc -o $# $^
This has all the generated files depend on a single file .sentinel (you can name it whatever you want), which is the one make knows is generated by the recipe that also creates all the other source files. This isn't perfect but it will work for simple situations.
Related
To learn the processes behind compilation of Ada programs (without resorting to using gpr), I've decided to compile one of my projects manually. To compile a program, I run the following command on each .adb file therein (not manually, however):
$ gcc -c src/<file>.adb -o obj/<file>.o
That compiles all the files and puts them in the obj directory.
Or rather, it would. There is a slight problem with this. I have an archive (static library) that I've generated from another project, called libapples.a, containing package Apples. The Apples package is used by the files you see me compiling above.
Since libapples.a doesn't have source files anymore (given its archive format), it's not viable (not even possible) to provide the sources of that library to the command above using -I switches; on the other hand, if I don't have the sources included, the command above comes back to me saying:
<file>.adb:<y>:<x>: file "apples.ads" not found
gnatmake: "src/<file>.adb" compilation error
I've attempted to include the library in the compilation process by using flags -L and l (which I believe is how you'd do it in C; feel free to correct me if I'm wrong). In another attempt I placed the archive right in the source directory.
How does one go about including a library in the compilation process?
apples.ads is somewhat like a header in C and you definitely need it for your file to compile. You should use -I to point gcc to the directory where apples.ads is located in.
Be aware that compiling an Ada source not only yields an object file, but also an Ada Library Information (.ali) file. You'll need that for the next step. You should not use the -o flag because it may lead to your .o and .ali files having different names.
On the other hand, since you only want to produce an object file, you should use -c to tell gcc to only compile. In other languages like C, gcc compiles and links by default; in Ada, the process is more complex.
After compilation, you need to call gnatbind on the .ali file of your main program. This generates a package that will take care of proper initialization of everything. To do that, gnatbind needs the .ali file of the Apples package! You can specify the .ali search directory with -aO.
Finally, gnatlink called on the main .ali file will link everything together. It figures out itself which object files and libraries it needs. It will append the necessary options to the linker, including the reference to libapples.a. It also compiles the package generated by gnatlink.
I don't know exactly what gnatlink will do under the hood; you could probably compile the package generated by gnatbind manually and then call the linker if you can figure out the proper arguments.
I am trying to generate an annotated file with Frama-C E-ACSL plugin. I created the following files:
Insert.c: contains all the structures to create a linked list.
AxiomTest.c: includes the main function where the asserts it must fulfil are indicated. All functions and structures are determined in terms of Insert.c file
When compiling/instrumenting a program the manual specifies the following terminal command:
$ e-acsl-gcc.sh -c <files> -O <output>
For a successful compilation Insert.c and AxiomTest.c must be linked but I cannot find any flag for that.
Any help? Or is there any other way to do it right?
e-acsl-gcc.sh does compile and link files with option -c, despite looking like it only compiles (the -c here is unrelated to GCC's -c option, which does only compilation, without linking).
If you want to give extra flags to the linker, man e-acsl-gcc.sh (or e-acsl-gcc.sh -h) will indicate option -l:
-l pass additional options to the linker
So I am trying to set up a way to easily develop OpenCL programs which turned out to be the hardest part of learning this language so far. I include CL/cl.h in my source files but I keep getting compiler errors that the headers don't exist. When I change the include to only be cl.h it works but every program I have seen so far uses CL/cl.h so I am assuming it is some sort of macro to allow either file. Any ideas how I can get around this or possible fixes?
This is my makefile
PROJ=ocl_intro
CC=mingw32-g++
CFLAGS=-std=c99 -Wall
LIB=-lOpenCL
ifdef INTELOCLSDKROOT
INC_DIRS="$(INTELOCLSDKROOT)include\CL"
LIB_DIRS="$(INTELOCLSDKROOT)lib\x86
endif
$(PROJ): $(PROJ).cpp
$(CC) $(CFLAGS) -o $# $^ -I$(INC_DIRS) -L$(LIB_DIRS) $(LIB)
.PHONY: clean
clean:
rm $(PROJ).exe
Change:
INC_DIRS="$(INTELOCLSDKROOT)include\CL"
To:
INC_DIRS="$(INTELOCLSDKROOT)include"
You are looking for "CL/cl.h", obviously it's not going to find a folder called "CL" inside "include\CL", since you're already giving the "CL" folder as a search path. As is now, you're essentially asking the compiler to find "\include\CL\CL\cl.h", clearly the compiler will fail since this file does not exist.
You are meant to simply provide the path to the "include" folder - conventions will do the rest.
I'm working on some bare-metal embedded code that runs on ARM, and thus has to deal with the whole ARM vs. THUMB mode distinction. The current build system uses static pattern rules to determine whether to compile files in ARM or THUMB mode.
$(ACOBJS) : %.o : %.c
#echo
$(CC) -c $(CFLAGS) $(AOPT) -I . $(IINCDIR) $< -o $#
$(TCOBJS) : %.o : %.c
#echo
$(CC) -c $(CFLAGS) $(TOPT) -I . $(IINCDIR) $< -o $#
Where ACOBJS is a list of output objects that should be in ARM mode and the same for TCOBJS and Thumb mode. These lists are created from the list of sources in the usual manner of
ACOBJS = $(ACSRC:.c=.o)
TCOBJS = $(TCSRC:.c=.o)
Currently this results in the object files from the build being strewn about the source tree, which I don't particularly desire. I've been trying to set this up for out of tree builds but haven't been able to get this to work. I don't necessarily need to get full out of tree builds working, but I would like to at least be able to use an output directory under which all the intermediate files end up going. What is the best strategy to achieve this under these constraints?
One option I'm considering is using either automake or the whole autotools toolchain to build a makefile. This would seem to support creating the type of makefile I want, but seems like overkill. It also seems like there would be an inherent impedance mismatch between autotools, which is designed for portable builds, and bare-metal embedded systems, where things like host tuple are dictated by the target micro.
This is a bit old but I was just trying to do the same thing this was the first google hit. I thought it was worth sharing another approach since neither answer is convenient if you're not using autotools and want to be able to build in any directory with a single command and later just blow away that directory.
Here's an example of a Makefile that refers to files relative to the directory containing the Makefile.
MAKEFILE_DIR := $(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))
MFD := $(MAKEFILE_DIR)
CXX=g++
CXXFLAGS=-std=c++14 -Wall -Wextra -pedantic -c
test: test.o adjacency_pointers_graph.o
$(CXX) $^ -o $#
%.o: $(MFD)/%.cpp $(MFD)/adjacency_pointers_graph.h
$(CXX) $(CXXFLAGS) $< -o $#
Then to do an sort of source build:
mkdir build
cd build
make -f ../Makefile
Considering/assuming you don't care about portability and are using GNU make, you can use the VPATH feature:
Create the directory where you want to do your build.
Create a 'Makefile' in that directory with (approximately) the following contents:
path_to_source = ..
VPATH = $(path_to_source)
include $(path_to_source)/Makefile
Change the path_to_source variable to point to the root of your source tree.
Additionally you probably need to tweak your original Makefile to make sure that it supports the out of source build. For example, you can't reference to prerequisites from your build rules and instead must use $^ and $<. (See GNU make - Writing Recipes with Directory Search) You might also need to modify the vpath-makefile. For example: adding CFLAGS+=-I$(path_to_source) might be useful.
Also note that if a file is in both your source and build directory, make will use the file in your build directory.
On automake
If you use automake, you're pretty much using the entire autotools. automake cannot work without autoconf.
The Makefiles generated by automake support out-of-source builds and cross-compilation, so you should be able to create subdirectories arm/ and thumb/ and run ../configure --host=arm-host-prefix in arm/ and run ../configure --host=thumb-host-prefix in thumb/. (I don't know the actual host tuples that you'd use for each compiler.)
Using GNU make
Since you're using GNUMake, you could do something like this:
ACOBJS := $(addprefix arm/,$(ACSRC:.c=.o))
TCOBJS := $(addprefix thumb/,$(TCSRC:.c=.o))
Use something like this answer to ensure that the arm/ and thumb/ directories (and any subdirectories) exist.
I'm using a Makefile to build an embedded project. I've inherited the project from numerous previous developers who haven't been using Make to its full potential, and I'd like to be able to specify the project version in the makefile using defines on the build command. However, there's already a build rule that builds all the object (.o) files. Is there any way to override that build rule for a specific object file so that I can add -D flags to the compiler ?
Another reason I'd like to be able to specify the project version in the makefile is so that I can have it generate artifacts with the build version in the names of the resulting files produced by the build process.
Yes, you can override a pattern rule (which is what I bet your .o rule is), just by having a specific rule (and the order of the rules doesn't matter):
%.o:
do_generic_things
x.o:
do_specific_things -Dproject_version
Yes, you can put a build version in a file name. There's more than one way to do it-- the best is probably to put it in the target name:
%$(B_VERSION).o: %.c
$(CC) -c -DBUILD_VERSION=$(B_VERSION) -Whatever $< -o $#
If you are using GNU make and you only want to change compiler options, you can use target-specific variables, like so:
x.o: CFLAGS += -DEXTRA_SYMBOL_FOR_X
This also works recursively, i.e. the target-specific value for x.o also is in effect for all targets which x.o depends on, meaning that if you build multiple executables in your makefile, you can set a target-specific variable on the executable itself, which will be in effect for all the object files:
foo: CFLAGS += -DEXTRA_SYMBOL_FOR_FOO_APP