PRE_TARGETDEPS fails when using parallel builds - c++

I'm using a custom ressource management (in replacement to qrc) and I'm trying to integrate it to QtCreaor.
I have a Python script that generates a source file to be compiled. I use QMAKE_EXTRA_TARGETS/PRE_TARGETDEPS to tell QMake that this script must be executed before files are compiled. So I do, in my pro file:
CONFIG += ordered
generated_file.target = my_custom_target
generated_file.commands = echo "Generating..." && d:/dev/vobs_ext_2015/tools_ext/python/Python34_light/python.exe $$PWD/pyc_res_generator.py -o $$PWD/generated/generated.cpp && echo "Generated!"
generated_file.depends = FORCE
QMAKE_EXTRA_TARGETS += generated_file
PRE_TARGETDEPS += my_custom_target
SOURCES += generated/generated.cpp
#DEPENDPATH = ./generated
With pyc_res_generator.py simply being:
#! /usr/bin/env python
# -*- coding: utf8 *-*
import argparse
parser = argparse.ArgumentParser(description="", formatter_class=argparse.RawTextHelpFormatter)
parser.add_argument("-o", type=str, help="Output file name")
args = parser.parse_args()
with open(args.o, 'w') as output_file:
output_file.write( "// This is valid C++!" )
To test this, I write some invalid C++ in generated.cpp (like fjkfkfk). When I compile (target is Android), I see in the log:
echo Generating... && python.exe pyc_res_generator.py -o generated/generated.cpp && echo Generated!
Generating...
B:\Android\android-ndk-r11b/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-g++ -c -Wno-psabi -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -DANDROID -Wa,--noexecstack -fno-builtin-memmove -std=c++11 -g -g -marm -O0 -fno-omit-frame-pointer -Wall -Wno-psabi -W -D_REENTRANT -fPIC -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I..\TestQt -I. -IB:\QtCreator5_6_1\5.6\android_armv7\include -IB:\QtCreator5_6_1\5.6\android_armv7\include\QtWidgets -IB:\QtCreator5_6_1\5.6\android_armv7\include\QtGui -IB:\QtCreator5_6_1\5.6\android_armv7\include\QtCore -I. -isystem B:\Android\android-ndk-r11b\sources\cxx-stl\gnu-libstdc++\4.9\include -isystem B:\Android\android-ndk-r11b\sources\cxx-stl\gnu-libstdc++\4.9\libs\armeabi-v7a\include -isystem B:\Android\android-ndk-r11b\platforms\android-9\arch-arm\usr\include -IB:\QtCreator5_6_1\5.6\android_armv7\mkspecs\android-g++ -o main.obj ..\TestQt\main.cpp
B:\Android\android-ndk-r11b/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-g++ -c -Wno-psabi -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -DANDROID -Wa,--noexecstack -fno-builtin-memmove -std=c++11 -g -g -marm -O0 -fno-omit-frame-pointer -Wall -Wno-psabi -W -D_REENTRANT -fPIC -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I..\TestQt -I. -IB:\QtCreator5_6_1\5.6\android_armv7\include -IB:\QtCreator5_6_1\5.6\android_armv7\include\QtWidgets -IB:\QtCreator5_6_1\5.6\android_armv7\include\QtGui -IB:\QtCreator5_6_1\5.6\android_armv7\include\QtCore -I. -isystem B:\Android\android-ndk-r11b\sources\cxx-stl\gnu-libstdc++\4.9\include -isystem B:\Android\android-ndk-r11b\sources\cxx-stl\gnu-libstdc++\4.9\libs\armeabi-v7a\include -isystem B:\Android\android-ndk-r11b\platforms\android-9\arch-arm\usr\include -IB:\QtCreator5_6_1\5.6\android_armv7\mkspecs\android-g++ -o dialog.obj ..\TestQt\dialog.cpp
B:\Android\android-ndk-r11b/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-g++ -c -Wno-psabi -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -DANDROID -Wa,--noexecstack -fno-builtin-memmove -std=c++11 -g -g -marm -O0 -fno-omit-frame-pointer -Wall -Wno-psabi -W -D_REENTRANT -fPIC -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I..\TestQt -I. -IB:\QtCreator5_6_1\5.6\android_armv7\include -IB:\QtCreator5_6_1\5.6\android_armv7\include\QtWidgets -IB:\QtCreator5_6_1\5.6\android_armv7\include\QtGui -IB:\QtCreator5_6_1\5.6\android_armv7\include\QtCore -I. -isystem B:\Android\android-ndk-r11b\sources\cxx-stl\gnu-libstdc++\4.9\include -isystem B:\Android\android-ndk-r11b\sources\cxx-stl\gnu-libstdc++\4.9\libs\armeabi-v7a\include -isystem B:\Android\android-ndk-r11b\platforms\android-9\arch-arm\usr\include -IB:\QtCreator5_6_1\5.6\android_armv7\mkspecs\android-g++ -o generated.obj ..\TestQt\generated\generated.cpp
B:\QtCreator5_6_1\5.6\android_armv7\bin\moc.exe -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -IB:/QtCreator5_6_1/5.6/android_armv7/mkspecs/android-g++ -IC:/Users/jp225611/Documents/TestQt -IB:/QtCreator5_6_1/5.6/android_armv7/include -IB:/QtCreator5_6_1/5.6/android_armv7/include/QtWidgets -IB:/QtCreator5_6_1/5.6/android_armv7/include/QtGui -IB:/QtCreator5_6_1/5.6/android_armv7/include/QtCore -I. -IB:\Android\android-ndk-r11b/sources/cxx-stl/gnu-libstdc++/4.9/include -IB:\Android\android-ndk-r11b/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include -IB:\Android\android-ndk-r11b/platforms/android-9/arch-arm//usr/include ..\TestQt\dialog.h -o moc_dialog.cpp
..\TestQt\generated\generated.cpp:1:1: error: 'fjkfkfk' does not name a type
// This is valid C++!
^
makefile:670: recipe for target 'generated.obj' failed
mingw32-make: *** [generated.obj] Error 1
mingw32-make: *** Waiting for unfinished jobs....
Generated!
13:59:08: Le processus "B:\QtCreator5_6_1\Tools\mingw492_32\bin\mingw32-make.exe" s'est terminé avec le code 2.
Erreur lors de la compilation/déploiement du projet TestQt (kit : android_armeabi-v7a)
When executing step "Make"
13:59:08: Temps écoulé : 00:03.
And I see that generated\generated.cpp was correctly generated by pyc_res_generator.py (it now contains // This is valid C++!)...but apparently too lately as the compiler saw fjkfkfk...
As you can see, the output reports:
Generating...
B:\Android\android-ndk-r11b/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-g++ .... ..\TestQt\generated\generated.cpp
Generated...
While one would expect:
Generating...
Generated...
B:\Android\android-ndk-r11b/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-g++ .... ..\TestQt\generated\generated.cpp
This only occurs when parallel builds are enabled (I set MAKEFLAGS environment variable to '-j8`)
It looks like my custom command generated_file is started before generated\generated.cpp is compiled, but the system does not wait for it to end before actually compiling generated\generated.cpp.
Am I doing something wrong?

PRE_TARGETDEPS (custom targets) is not the good approach here as generated_file.target must match exactly the Makefile target name which may be vary on different options:
shadow build enabled or not
host platform (using slashs or backslash as a folder separator)
probably targetted compiler/platform
However, custom compiler apparently works much better. That's how moccing files is done. A custom compiler can generate a new file to be compiled (and then the system waits for the file to be generated before compiling it, even when performing parallel builds).
# Set fuiles to be generated in a variable
TO_GENERATE = $$PWD/generated/generated.cpp
# Specify custom command output file:
custom_generator.output = $$PWD/generated/generated.cpp
# Specify custom command:
custom_generator.commands = 'echo "Generating..." && python $$PWD/pyc_res_generator.py -o $$PWD/generated/generated.cpp && echo "Generated..."'
# dependency:
custom_generator.depends = FORCE
# link to input file variable
custom_generator.input = TO_GENERATE
# link to variable to store generated file to
custom_generator.variable_out = SOURCES
# add to qmake:
QMAKE_EXTRA_COMPILERS += custom_generator
Then, you don't even need to specify SOURCES += $$PWD/generated/generated.cpp. And also, $$PWD/generated/generated.cpp gets deleted upon clean!
This works perfectly as expected!

You need to set the name of the target to the name of the file that it generates. Here's a full project file that works for me (qmake 3.1, Qt 5.10.1):
# Filename relative to the *build* directory.
generated_file.target = generated/generated.cpp
generated_file.commands = 'echo "Generating..." && mkdir -p generated && echo "int main() {}" > generated/generated.cpp'
generated_file.depends = FORCE
QMAKE_EXTRA_TARGETS += generated_file
# Filename relative to the *source* directory.
SOURCES += $$OUT_PWD/generated/generated.cpp
The reason is that generated_file.target becomes the name of the target in the Makefile, so when generated.cpp is needed, your custom rule will be executed to create the file.
You can also remove it from PRE_TARGETDEPS, because you're already adding the generated file to SOURCES instead, which creates the proper dependency.
Note that this approach generates the file in the build directory, not the source directory. This is why you need to specify $$OUT_PWD when adding it to SOURCES: by default, qmake seems to assume that SOURCES are relative to the source directory.
If you want to generate it in the source directory instead, you might think that you just prefix $$PWD everywhere, but then qmake sometimes uses absolute paths and sometimes relative, and everything fails. You can probably work around that with $$absolute_path($$PWD) but I haven't tried.
Relevant sections from the generated Makefile (comments are mine):
# How to create generated/generated.cpp.
# Depending on FORCE to make it always stale (fails if you create a file named FORCE :)).
generated/generated.cpp: FORCE
echo "Generating..." && mkdir -p generated && echo "int main() {}" > generated/generated.cpp
# generated.o depends on generated/generated.cpp.
# Note that it's not in the same directory; we don't care.
generated.o: generated/generated.cpp
$(CXX) -c $(CXXFLAGS) $(INCPATH) -o generated.o generated/generated.cpp
# The final executable depends on the compiled generated.o.
OBJECTS = generated.o
$(TARGET): $(OBJECTS)
$(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)
The qmake documentation is pretty vague about this, only stating that target should be "The name of the custom build target.". However, the example shows that they're setting it to the name of the output file. (As a bonus, it also shows how to not repeat that name in the commands.)

An alternative relies on the TEMPLATE=subdirs, to honour libname.depends in a parallel build environment. You would need two .pro files in each application folder. And one in the shared library folder. Any other folders in your development area that use TEMPLATE=subdirs need to be made compatible.
eg TestApp using LibLarry.
Folder TestApp has
bld.pro and TestApp.pro.
TestApp.pro:
#This is a TEMPLATE=subdirs, which gmake will interpret;
# making sure the build dependencies are respected
TEMPLATE = subdirs
SUBDIRS += bld mylib
bld.file = bld.pro
bld.depends = mylib # force library to be built first.
mylib.file = $${PATH_TO_LIB_LARRY}/liblarry.pro
bld.pro:
TARGET=TestApp
SOURCES+=TestApp.cpp
PRE_TARGETDEPS+=$${PATH_TO_LIB_LARRY}/liblarry.a
#boilerplate...
QT -= gui
CONFIG = ...
include ($${PATH_TO_LIB_LARRY}/liblarry.pri) # contains include file info
CONFIG += link_prl # allow lib larry to specify its position in the linker input command.
Folder LibLarry has
LibLarry.pro
containing
LibLarry.pro:
TARGET=larry
TEMPLATE=lib
CONFIG+=staticlib
CONFIG+=create_prl # export information, so apps can link correctly
SOURCES+=my_shared_function.cpp
include (liblarry.pri)
liblarry.pri:
HEADERS += $$PWD/my_shared_function.h
INCLUDEPATH += $$PWD

Related

Make: How to write makefile with both hpp and cpp file mixture project

I am trying to make a makefile for my project which makes out of a Main.cpp file which includes some *.hpp/h files (calling it L.hpp,D.h,UC.hpp). The header files(mainly the hpp) contain both implementation and declaration. In addition, Main.cpp and L.hpp uses a class object C. Below is a diagram of its relationship.
After which I proceed to write a makefile for it (as below). The common variables eg CXX are left out (as it is written in an environment script and I just source the file before running the makefile). The additional variables ($(MISC), $(ADD_INC), $(LIB_LOC) $(LDLIBS)) are various includes, libraries, compilation settings that main.cpp and L.hpp requires
###
### Library file
###
LDLIBS = -lxml2 -ldl -lgstpbutils-1.0 -lgstsdp-1.0 -lgstapp-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lpthread -lstdc++ -lnsl -lm
LIB_PKG = -L${SDKTARGETSYSROOT}/usr/lib/pkgconfig
LIB_GST = -L${SDKTARGETSYSROOT}/usr/lib/gstreamer
LIB_PRJ = -L${SDKTARGETSYSROOT}/usr/lib
LIB_LOC = $(LIB_PKG) $(LIB_GST) $(LIB_PRJ)
###
### Header file dependency list
###
# include for gstreamer
INC_GST = -I$(SDKTARGETSYSROOT)/usr/include/gstreamer-1.0/
# include for glib
INC_GLIB = -I$(SDKTARGETSYSROOT)/usr/include/glib-2.0
INC_GLIB_CONFIG = -I$(SDKTARGETSYSROOT)/usr/lib/glib-2.0/include
ADD_INC = $(INC_GST) $(INC_GLIB) $(INC_GLIB_CONFIG)
MISC = -std=c++11 -c -fpermissive -fmessage-length=0 $(shell pkg-config --cflags)
# partial makefile
#
# Define the Target name and main object list
#
FINAL_TARGET = VS2
OBJ = ../Main.cpp C.o
#
# Build Rules
#
all: $(FINAL_TARGET)
C.o: ../C.cpp ../C.h
$(CXX) $(CXXFLAGS) $(MISC) -c $< -o $# $(LDFLAGS) $(LIB_LOC) $(LDLIBS)
$(FINAL_TARGET): $(OBJ)
$(CXX) $(CXXFLAGS) $(ADD_INC) $(MISC) -o $(FINAL_TARGET) $(OBJ) $(LDFLAGS) $(LIB_LOC) $(LDLIBS)
clean:
rm -rf $(FINAL_TARGET) *.o
The compilation, apart from getting C.o: linker input file unused because linking not done as a warning completed without any other problem. However, the end product of the VS2 seem not to be running properly when transplanted to the environment and run. I have used file VS2 and found that VS2 is actually a relocatable files (seem like linking not done)
So I have the following question:
Am I writing the makefile correctly? by only compiling for main.cpp and C.cpp
How should i include hpp file? Have read the Write makefile for .cpp and .hpp c++. Can't say I fully understand the author but it seem to call for putting in lines as
L.o: ../L.hpp
OBJ = ../Main.cpp C.o L.o
Need your advice
==================================================================
EDIT For more information
Basically I just source the file below before I make using the makefile above
# Check for LD_LIBRARY_PATH being set, which can break SDK and generally is a bad practice
# http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80
# http://xahlee.info/UnixResource_dir/_/ldpath.html
# Only disable this check if you are absolutely know what you are doing!
if [ ! -z "$LD_LIBRARY_PATH" ]; then
echo "Your environment is misconfigured, you probably need to 'unset LD_LIBRARY_PATH'"
echo "but please check why this was set in the first place and that it's safe to unset."
echo "The SDK will not operate correctly in most cases when LD_LIBRARY_PATH is set."
echo "For more references see:"
echo " http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80"
echo " http://xahlee.info/UnixResource_dir/_/ldpath.html"
return 1
fi
export SDKTARGETSYSROOT=/opt/wayland/sysroots/cortexa53-crypto-poky-linux
export PATH=/opt/wayland/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/wayland/sysroots/x86_64-pokysdk-linux/usr/sbin:/opt/wayland/sysroots/x86_64-pokysdk-linux/bin:/opt/wayland/sysroots/x86_64-pokysdk-linux/sbin:/opt/wayland/sysroots/x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/opt/wayland/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/opt/wayland/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux-musl:$PATH
export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
export PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig
export CONFIG_SITE=/opt/wayland/site-config-cortexa53-crypto-poky-linux
export OECORE_NATIVE_SYSROOT="/opt/wayland/sysroots/x86_64-pokysdk-linux"
export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"
export OECORE_ACLOCAL_OPTS="-I /opt/wayland/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
export OECORE_BASELIB="lib"
export OECORE_TARGET_ARCH="aarch64"
export OECORE_TARGET_OS="linux"
unset command_not_found_handle
export CC="aarch64-poky-linux-gcc -mcpu=cortex-a53 -march=armv8-a+crc+crypto -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=$SDKTARGETSYSROOT"
export CXX="aarch64-poky-linux-g++ -mcpu=cortex-a53 -march=armv8-a+crc+crypto -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=$SDKTARGETSYSROOT"
export CPP="aarch64-poky-linux-gcc -E -mcpu=cortex-a53 -march=armv8-a+crc+crypto -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=$SDKTARGETSYSROOT"
export AS="aarch64-poky-linux-as "
export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT"
export GDB=aarch64-poky-linux-gdb
export STRIP=aarch64-poky-linux-strip
export RANLIB=aarch64-poky-linux-ranlib
export OBJCOPY=aarch64-poky-linux-objcopy
export OBJDUMP=aarch64-poky-linux-objdump
export READELF=aarch64-poky-linux-readelf
export AR=aarch64-poky-linux-ar
export NM=aarch64-poky-linux-nm
export M4=m4
export TARGET_PREFIX=aarch64-poky-linux-
export CONFIGURE_FLAGS="--target=aarch64-poky-linux --host=aarch64-poky-linux --build=x86_64-linux --with-libtool-sysroot=$SDKTARGETSYSROOT"
export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now"
export CPPFLAGS=""
export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
export OECORE_DISTRO_VERSION="3.3.0"
export OECORE_SDK_VERSION="3.3.0"
export ARCH=arm64
export CROSS_COMPILE=aarch64-poky-linux-
# Append environment subscripts
if [ -d "$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then
for envfile in $OECORE_TARGET_SYSROOT/environment-setup.d/*.sh; do
. $envfile
done
fi
if [ -d "$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then
for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do
. $envfile
done
fi
=================================================================
Edit for #n. 1.8e9-where's-my-share m. [CORRECTED]
After make, I have noticed this message as part of output on terminal
C.o: linker input file unused because linking not done
And copying VS2 to the environment, I execute the file VS2
root#z-mx8mm:/usr/local# ./VS2
-sh: ./VS2: cannot execute binary file: Exec format error
root#z-mx8mmt:/usr/local#
At first I have thought of maybe that the file permission is not set properly
root#z-mx8mmt:/usr/local# chmod +x VS2
But the above error still remains. Then I use file command
root#z-mx8mmt:/usr/local# file VS2
VS2: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), with debug_info, not stripped
That's how i derive the conclusion
Exhibit A:
$(FINAL_TARGET): $(OBJ)
$(CXX) $(CXXFLAGS) $(ADD_INC) $(MISC) ....
Exhibit B:
MISC = -std=c++11 -c ...
-c produces an object file, not an executable. You don't need any of these MISC flags when linking.

Error while compiling a project which includes CPLEX tool

I am working on the project which has to include the CPLEX tool at some point.
More in detail, I have the following classes implemented
(i.e. the corresponding files): Random.cpp, Instance.cpp, Timer.cpp. Solution.cpp which are included into Hybrid_ea.cpp which also have to include cplex library.
Finally, the project has been executed by running Algorithm.cpp (the main() function defined here).
I want to run the project on Linux platform, creating Makefile which looks like:
TARGET = Algorithm
CXXFLAGS = -ansi -O3
GENOBJS = Random.o
#CPLOBJS = Timer.o Random.o Instance.o Hybrid_ea.o
GREOBJS = Timer.o Random.o Instance.o Solution.o Hybrid_ea.o
SYSTEM = x86-64_linux
LIBFORMAT = static_pic
CPLEXDIR = /home/root/Desktop/projects/software/cplex-12.5/cplex
CONCERTDIR = /home/root/Desktop/projects/software/cplex-12.5/concert
CCC = g++
CCOPT = -m64 -O -fPIC -fexceptions -DNDEBUG -DIL_STD -std=c++11 -fpermissive -w
CPLEXBINDIR = $(CPLEXDIR)/bin/$(BINDIST)
CPLEXLIBDIR = $(CPLEXDIR)/lib/$(SYSTEM)/$(LIBFORMAT)
CONCERTLIBDIR = $(CONCERTDIR)/lib/$(SYSTEM)/$(LIBFORMAT)
CCLNFLAGS = -L$(CPLEXLIBDIR) -lilocplex -lcplex -L$(CONCERTLIBDIR) -lconcert -lm -pthread
CLNFLAGS = -L$(CPLEXLIBDIR) -lcplex -lm -pthread
CONCERTINCDIR = $(CONCERTDIR)/include
CPLEXINCDIR = $(CPLEXDIR)/include
CCFLAGS = $(CCOPT) -I$(CPLEXINCDIR) -I$(CONCERTINCDIR)
all: ${TARGET}
Algorithm: Algorithm.o $(GREOBJS)
$(CCC) $(CCFLAGS) Algorithm.o $(GREOBJS) -o Algorithm $(CCLNFLAGS)
Algorithm.o: Algorithm.cpp
$(CCC) -c $(CCFLAGS) Algorithm.cpp -o Algorithm.o
clean:
#rm -f *~ *.o ${TARGET} core
The linking process is somehow wrong. I checked, my CPLEX version is the right one since the others, simpler projects can be executed;
The full output given when trying to compile the project:
g++ -c -m64 -O -fPIC -fexceptions -DNDEBUG -DIL_STD -std=c++11 -fpermissive -w -I/home/root/Desktop/projects/LCAPS_software/cplex-12.5/cplex/include -I/home/root/Desktop/projects/LCAPS_software/cplex-12.5/concert/include Algorithm.cpp -o Algorithm.o
g++ -ansi -O3 -c -o Timer.o Timer.cc
g++ -ansi -O3 -c -o Random.o Random.cc
g++ -ansi -O3 -c -o Instance.o Instance.cpp
g++ -ansi -O3 -c -o Solution.o Solution.cpp
g++ -ansi -O3 -c -o hybrid_ea.o hybrid_ea.cpp
In file included from hybrid_ea.cpp:22:0:
hybrid_ea.h:39:10: fatal error: ilcplex/ilocplex.h: No such file or directory
#include <ilcplex/ilocplex.h>
^~~~~~~~~~~~~~~~~~~~
compilation terminated.
<builtin>: recipe for target 'hybrid_ea.o' failed
make: *** [hybrid_ea.o] Error 1
Any help would be appreciated.
Only the file Algorithm.cpp is compiled with appropriate options for finding the CPLEX include files:
-I/home/root/Desktop/projects/LCAPS_software/cplex-12.5/cplex/include
-I/home/root/Desktop/projects/LCAPS_software/cplex-12.5/concert/include
As hybrid_ea.h also tries to include some CPLEX header files, the compilation of hybrid_ea.cpp should also have the options above.
If the makefile that you posted in your question is complete, then I suspect that the issue is the following: you didn't define a specific command to compile any .cc or .cpp file, except for Algorithm.cpp. Therefore, all other files are compiled using a default command g++ -ansi -O3 -c -o [file].o [file].cpp. And this default command doesn't have the include directives for the location of the CPLEX libraries.
As explained in ftp://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_10.html, these files are compiled using make's implicit rules. The implicit rule for C++ files is to use $(CXX) -c $(CPPFLAGS) $(CXXFLAGS). Notice how this rule uses CPPFLAGS and CXXFLAGS rather than the variable CCFLAGS that you defined at the end of your makefile to include the proper include directives.
So changing the end of your makefile to the following should work:
CPPFLAGS = $(CCOPT) -I$(CPLEXINCDIR) -I$(CONCERTINCDIR)
all: ${TARGET}
Algorithm: Algorithm.o $(GREOBJS)
$(CCC) $(CCFLAGS) Algorithm.o $(GREOBJS) -o Algorithm $(CCLNFLAGS)
clean:
#rm -f *~ *.o ${TARGET} core
Once you define the variable CPPFLAGS, it will be used automatically to compile any .cpp file that you have in your project.

Getting Eclipse to read includes from makefile

I have a makefile which compiles my code just fine when running make.
If a create a makefile project in eclipse and import my already existing makefile it is possible to build the project.
But Eclipse does not resolve names, as it cannot find my include files. Is there a way where Eclipse automatically can read include paths from the makefile?
My makefile looks like this
# Put your stlink folder here so make burn will work.
STLINK=~/Programs/stlink
# Put your source files here (or *.c, etc)
SRCS=main.c system_stm32f4xx.c ../src/*.c
# Binaries will be generated with this name (.elf, .bin, .hex, etc)
PROJ_NAME=blinky
# Put your STM32F4 library code directory here
STM_COMMON=../STM32F4-Discovery_FW_V1.1.0
# Normally you shouldn't need to change anything below this line!
#######################################################################################
CC=arm-none-eabi-gcc
OBJCOPY=arm-none-eabi-objcopy
CFLAGS = -g -O2 -Wall -Tstm32_flash.ld
CFLAGS += -mlittle-endian -mthumb -mcpu=cortex-m4 -mthumb-interwork
CFLAGS += -mfloat-abi=hard -mfpu=fpv4-sp-d16
CFLAGS += -I.
# Include files from STM libraries
CFLAGS += -I$(STM_COMMON)/Utilities/STM32F4-Discovery
CFLAGS += -I$(STM_COMMON)/Libraries/CMSIS/Include -I$(STM_COMMON)/Libraries/CMSIS/ST/STM32F4xx/Include
CFLAGS += -I$(STM_COMMON)/Libraries/STM32F4xx_StdPeriph_Driver/inc
CFLAGS += -I ../include/
# add startup file to build
SRCS += $(STM_COMMON)/Libraries/CMSIS/ST/STM32F4xx/Source/Templates/TrueSTUDIO/startup_stm32f4xx.s
OBJS = $(SRCS:.c=.o)
.PHONY: proj
all: proj
proj: $(PROJ_NAME).elf
$(PROJ_NAME).elf: $(SRCS)
$(CC) $(CFLAGS) $^ -o $#
$(OBJCOPY) -O ihex $(PROJ_NAME).elf $(PROJ_NAME).hex
$(OBJCOPY) -O binary $(PROJ_NAME).elf $(PROJ_NAME).bin
clean:
rm -f *.o $(PROJ_NAME).elf $(PROJ_NAME).hex $(PROJ_NAME).bin
# Flash the STM32F4
burn: proj
$(STLINK)/st-flash write $(PROJ_NAME).bin 0x8000000

qmake with Jenkins

I am trying to make Jenkins do the compile and build for me whenever I push commit to Git. I have a helloworld app created in Qt Creator. It does compile and build in Qt Creator, it does show on my phone, but it doesn't want to compile and build with Jenkins.
I am using the same shell commands which QtC used:
qmake helloworld.pro -r -spec android-g++;
make;
The console output is:
+ qmake helloworld.pro -r -spec android-g++
+ make
/home/ndk/toolchains/arm-linux-androideabi-4.9-/prebuilt/bin/arm-linux-androideabi-g++ -c -pipe -std=c++11 -O2 -Os -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -mthumb -Wall -Wno-psabi -W -I/usr/share/qt4/mkspecs/android-g++ -I. -I. -I/home/ndk/sources/cxx-stl/gnu-libstdc++//include -I/home/ndk/sources/cxx-stl/gnu-libstdc++//libs//include -I/home/ndk/platforms//arch-arm//usr/include -o main.o main.cpp
In file included from main.cpp:1:0:
mainwindow.h:4:23: fatal error: QMainWindow: No such file or directory
#include <QMainWindow>
^
compilation terminated.
Makefile:187: recipe for target 'main.o' failed
make: *** [main.o] Error 1
My helloworld.pro:
QT += core gui
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = helloworld
TEMPLATE = app
SOURCES += main.cpp\
mainwindow.cpp
HEADERS += mainwindow.h
FORMS += mainwindow.ui
CONFIG += mobility
MOBILITY =
main.cpp
#include "mainwindow.h"
#include <QMainWindow>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
EDIT/UPDATE:
So far, I have tried to specify the full path to qmake, to be sure that I use Qt's qmake.
/home/qt/5.7/android_armv7/bin/qmake helloworld.pro -r -spec android-g++;
make;
The output is:
/home/qt/5.7/android_armv7/bin/uic mainwindow.ui -o ui_mainwindow.h
/home/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ -c -Wno-psabi -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -DANDROID -Wa,--noexecstack -fno-builtin-memmove -std=c++11 -O2 -Os -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -mthumb -Wall -Wno-psabi -W -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../qt/5.7/android_armv7/include -I../../qt/5.7/android_armv7/include/QtWidgets -I../../qt/5.7/android_armv7/include/QtGui -I../../qt/5.7/android_armv7/include/QtCore -I. -I. -I../../ndk/sources/cxx-stl/gnu-libstdc++/4.9/include -I../../ndk/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include -I../../ndk/platforms/android-9/arch-arm/usr/include -I../../qt/5.7/android_armv7/mkspecs/android-g++ -o main.o main.cpp
/home/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ -c -Wno-psabi -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -DANDROID -Wa,--noexecstack -fno-builtin-memmove -std=c++11 -O2 -Os -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -mthumb -Wall -Wno-psabi -W -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../qt/5.7/android_armv7/include -I../../qt/5.7/android_armv7/include/QtWidgets -I../../qt/5.7/android_armv7/include/QtGui -I../../qt/5.7/android_armv7/include/QtCore -I. -I. -I../../ndk/sources/cxx-stl/gnu-libstdc++/4.9/include -I../../ndk/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include -I../../ndk/platforms/android-9/arch-arm/usr/include -I../../qt/5.7/android_armv7/mkspecs/android-g++ -o mainwindow.o mainwindow.cpp
mainwindow.cpp:3:25: fatal error: QtGui/QAction: No such file or directory
#include <QtGui/QAction>
^
compilation terminated.
Makefile:1780: recipe for target 'mainwindow.o' failed
make: *** [mainwindow.o] Error 1
Most likely your jenkins setup uses the wrong qmake. There's a 1:1 mapping between a Qt installation and its qmake. So, your install of Qt for android will have its own qmake that you must refer to by full path! Qt Creator sets up the path so that this happens automatically, Jenkins doesn't - and it shouldn't anyway.
When building for any particular Qt version, you only need to invoke its qmake explicitly. From then onwards, as long as the proper compiler is in the path, things will happen as they should and you don't ever need to refer to that Qt version manually again. The makefiles will all refer to Qt libraries, headers and tools from that Qt install.
You also don't need the -spec argument. Each Qt installation is compiled for a particular mkspec, so qmake itself knows exactly what the spec is. I have no idea why QtCreator gives that argument, it doesn't make much sense.
The only Qt header path that's in your commandline is the one for the mkspec. I would blame the server's Qt installation for this.
Ensure Qt for Android is properly installed on the server, and that it is its qmake you are calling.

"'omp.h' file not found" when compiling using Clang

I'm trying to set up an OpenMP project using Clang (3.7.0) on my laptop running Linux Mint.
Now I've read that OpenMP is not supported right away so I followed the tutorial https://clang-omp.github.io/ to integrate OpenMP into Clang.
I've cloned the source code, set the environment variables and set the -fopenmp flag to my project, but I still get the error:
fatal error: 'omp.h' file not found
when building.
My guess is that I have set the environment variables wrong. Is there a way to check if I have put them in the right place? I have just copied them in the .bashrc file.
When I run locate omp.h I get:
/usr/include/re_comp.h
/usr/include/linux/ppp-comp.h
/usr/include/linux/seccomp.h
/usr/include/net/ppp-comp.h
/usr/include/openssl/comp.h
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/omp.h
/usr/lib/perl/5.18.2/CORE/regcomp.h
/usr/src/linux-headers-3.13.0-24/arch/arm/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/microblaze/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/mips/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/powerpc/include/uapi/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/s390/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/sh/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/sparc/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/x86/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/include/linux/ppp-comp.h
/usr/src/linux-headers-3.13.0-24/include/linux/seccomp.h
/usr/src/linux-headers-3.13.0-24/include/net/ipcomp.h
/usr/src/linux-headers-3.13.0-24/include/uapi/linux/ppp-comp.h
/usr/src/linux-headers-3.13.0-24/include/uapi/linux/seccomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/seccomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/crypto/pcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/inet/ipcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/inet6/ipcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/isdn/ppp/bsdcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/ppp/bsdcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/xfrm/ipcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/linux/ppp-comp.h
/usr/src/linux-headers-3.13.0-24-generic/include/linux/seccomp.h
Here is my makefile:
# Requires the following project directory structure:
# /bin
# /obj
# /src
# Use 'make remove' to clean up the whole project
# Name of target file
TARGET = main
CXX = clang++
CFLAGS = -std=c++11 \
-Weverything -Wall -Wextra -Wold-style-cast -Wpointer-arith -Wcast-qual \
-Wno-missing-braces -Wempty-body -Wno-error=uninitialized \
-Wno-error=deprecated-declarations -Wno-c++98-compat \
-pedantic-errors -pedantic \
-Os -fopenmp
LINKER = clang++ -o
LFLAGS = -Wall -Weverything -pedantic
SRCDIR = src
OBJDIR = obj
BINDIR = bin
SOURCES := $(wildcard $(SRCDIR)/*.cpp)
INCLUDES := $(wildcard $(SRCDIR)/*.h)
OBJECTS := $(SOURCES:$(SRCDIR)/%.cpp=$(OBJDIR)/%.o)
RM = rm -f
$(BINDIR)/$(TARGET): $(OBJECTS)
#$(LINKER) $# $(LFLAGS) $(OBJECTS)
#echo "Linking complete!"
$(OBJECTS): $(OBJDIR)/%.o : $(SRCDIR)/%.cpp
#$(CXX) $(CFLAGS) -c $< -o $#
#echo "Compiled "$<" successfully!"
.PHONEY: prepare
prepare:
mkdir -p bin
mkdir -p obj
.PHONEY: clean
clean:
#$(RM) $(OBJECTS)
#echo "Cleanup complete!"
#$(RM) tmp_file-*
#echo "Temporary files removed!"
.PHONEY: remove
remove: clean
#$(RM) $(BINDIR)/$(TARGET)
#echo "Executable removed!"
.PHONEY: run
run:
./bin/$(TARGET)
OpenMP is well supported in Clang 3.7, but you might need to enable it see here.
OpenMP 3.1 is fully supported, but disabled by default. To enable it,
please use the -fopenmp=libomp command line option.
Also see Status of supported OpenMP constructs for more precision.
So you don't have to clone the clang-omp project any more.
What build system do you use for your project and what errors do you get when you compile?
If you use Makefile: do not forget to add the -fopenmp flag.
If you use CMake: you should also look for right OpenMP flags with the FindOpenMP module and add them accordingly.
If you still get the include error, then your omp.h header file may not be in the Clang default search path. So you should try to include the one that comes with GCC and add -I/usr/lib/gcc/x86_64-linux-gnu/4.8/include/.
So in your case you should add this line:
CFLAGS = -std=c+11 [etc...]
CFLAGS += -I/usr/lib/gcc/x86_64-linux-gnu/4.8/include/
LINKER = [etc...]
'omp.h' is a C header that comes with the "Mint" libgcc-[version]-dev (RPM-based OSes have this header in a different package, e.g. libgomp-*).
Example libgcc-4.8-dev: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/omp.h
Solution: Install the version for your default GCC: gcc --version
libgcc-dev
In case the context is a build of Clang from source - one solution is to:
Ensure the openmp subproject is built by adding it to LLVM_ENABLE_PROJECTS at CMake invocation
Build that subproject with cmake --build . --target omp
Copy the generated omp.h from build/projects/openmp/runtime/src/omp.h to build/lib/clang/10.0.0/include, which is in the newly-built Clang's default search path.
I previously used the "add GCC's path to omp.h to every build command" approach, but I found this easier.