I have a C++ application which I'm trying to build with scons which consists of several subprograms.
Each subprogram has its own source files in a subdirectory of the source directory. These source files, e.g. source/prog1/prog1.cpp, are compiled into object files which reside in the object directory, e.e. object/prog1/prog1.o.
This works fine since each source directory has its target directory, and there's no possibility of clashes.
However, what I'm trying to do is link these object files into executables, which would be in the same bin directory. So multiple source files (object/prog1, object/prog2, etc) would all go into the same target directory (bin).
The directory layout looks like this:
application
source
prog1
prog1.cpp
something.cpp
prog2
prog2.cpp
somethingelse.cpp
object
prog1
prog1.o
something.o
prog2
prog2.o
somethingelse.o
bin
??? <- what I'm concerned with
I'm trying to achieve that with the following SConstruct script:
env = Environment()
Export('env')
#common objects
common=env.SConscript("source/common/SConscript_object", variant_dir="object/common", duplicate=0)
Export('common')
#sub-programs
env.SConscript("source/prog1/SConscript_bin", variant_dir="bin", duplicate=0)
env.SConscript("source/prog2/SConscript_bin", variant_dir="bin", duplicate=0)
However, scons is complaining with the following error:
scons: *** 'bin' already has a source directory: 'source/prog1'.
The error goes away if I make it so that each subprogram has its own directory in the bin directory, e.g. variant_dir="bin/prog1".
So, my question is this: how can I link object files from multiple sources into the same variant dir?
In your case I would let SCons build the different binaries in their respective folder, and then use the Install builder to copy the binary files to the bin/ directory.
You would get something like:
env = Environment()
Export('env')
common = env.SConscript("source/common/SConscript_object", variant_dir="object/common", duplicate=0)
Export('common')
prog1 = env.SConscript("source/prog1/SConscript_bin", variant_dir="object/prog1", duplicate=0)
prog2 = env.SConscript("source/prog2/SConscript_bin", variant_dir="object/prog2", duplicate=0)
env.Install('bin', prog1)
env.Install('bin', prog2)
With the SConscript of the subprograms being something like
Import('env')
Import('common')
prog1 = env.Program('prog1', [ env.Glob(*.cpp), common ])
Return('prog1')
I think SCons refuses to build different targets into a unique variant directory because variants are designed to build a given target with different build settings, like debug and release mode.
Related
I have a project directory structure of:
Root
Source
Common
MyFolder
++ My 3 source files and header
When I am building my project it generates 3 to 4 shared libraries. Lib1 compiled using c++98 and others using c++11. Flags are added in CmakeList.txt which is at root.
I need my 3 source files to be compiled for Lib1 and for other Libs as as well. but here what happens is compiler is first compiling my source file for lib using c++11 and then it is trying to use same .o file for Lib1 as well. So for .o file which is generated using c++11 is throwing exception when same is used for c++98 compiled library.
So how do write this in CmakeList.txt such that compiler rather than trying to use same .o file will compile source file again for Lib1(c++98 compiled library)
Is there any flag I can specify so that it won't take precompiled .o file and will compile it again ?
Here flags are not being overridden for different shared libraries but actually same object file by make file is being used for different flags
This is sort of counter to how makefiles and cmake usually work.
Most users consider it really important that make performs an incremental build.
The usual way with makefiles is to do make clean which is supposed to remove any binaries and object files that were created.
However, sometimes I write cmake scripts that use globbing over the source directory to assemble the project. (That means, it says "just grab all *.cpp files in the /src folder and make an executable from them".) A makefile cannot check what files in a directory, so the make build will be broken after I add a new file, and make clean won't fix it -- the whole makefile will need to be regenerated by cmake.
Usually what I do is, I write a simple bash script, named rebuild.sh or something,
#!/bin/bash
rm -rf build
mkdir build
cd build
cmake ..
make -j3
./tests
And I put that in the root of my repository, and add /build to my .gitignore. I call that when I want to do a full rebuild -- it nukes the build directory, so its foolproof. When I want an incremental rebuild, I just type make again in the /build directory.
The rebuild.sh script can also serve a double purpose if you use travis-ci for continuous integration.
Most build system assume the compiled objects remain the same within the same pass. To avoid shooting your foot I would suggest telling the build system they were actually different objects, while still compiled from same source files.
I'm not familiar with cmake but this is how you do with make:
For example you have a a.cpp which you want to compile 2 times for different compiler options:
#include <stdio.h>
int main(int argc, char* argv[]) {
printf ("Hello %d\n", TOKEN);
return 0;
}
And the Makefile would looks like:
SRC := $(wildcard *.cpp)
OBJ_1 := $(patsubst %.cpp,%_1.o,$(SRC))
OBJ_2 := $(patsubst %.cpp,%_2.o,$(SRC))
all: pass1 pass2
pass1: $(OBJ_1)
gcc -o $# $(OBJ_1) -lstdc++
pass2: $(OBJ_2)
gcc -o $# $(OBJ_2) -lstdc++
%_1.o: %.cpp
gcc -DTOKEN=1 -c $< -o $#
%_2.o: %.cpp
gcc -DTOKEN=2 -c $< -o $#
clean:
rm -f $(OBJ_1) $(OBJ_2)
What I do here is generate two different list of object from the same source files, which you can even do the same for dependency(-MMD -MP flags).
I have a CMakeLists.txt file in which I added:
set(CMAKE_CXX_FLAGS "-fprofile-arcs -ftest-coverage -pthread -std=c++11 -O0 ${CMAKE_CXX_FLAGS}")
It is generating the report files in:
project_root/build/CMakeFiles/project.dir/
BUT the files it generates have extentions .cpp.gcno, .cpp.gcda and .cpp.o.
Also, they are not in the same folder as the src files, which are at:
project_root/src/
When I move the report files to the src/ folder and execute
$ gcov main.cpp
main.gcno:cannot open notes file
But I get that error message. So I change the .cpp.gcno, .cpp.cdna and cpp.o to .gcno, .gcda and .o and finally I get the following:
gcov main.cpp
Lines executed:86.67% of 15
Creating 'main.cpp.gcov'
I have over 50 files and can't do this manually for each one.
I need to be able to run gcov once for all files and generate report for all files. I don't care where the files are generated.
It is generating the report files in: project_root/build/CMakeFiles/project.dir/
This is directory where all additional files are built for 'project' executable.
BUT the files it generates have extentions '.cpp.gcno', '.cpp.gcda' and '.cpp.o'
This is because CMake creates .cpp.o object file from .cpp source (you may see that running make VERBOSE=1. In accordance to -fprofile-arcs option's description, data file has suffix .cpp.gcno.
Also, they are not in the same folder as the src files
Data files are created in the same directory with object file.
Actually, created files are still work, if you call
gcov main.cpp.gcno
from the directory with .gcno files.
Apparently the standard CMake behavior to add an extension to give .cpp.o can be changed to replace an extension to give .o by using:
set(CMAKE_CXX_OUTPUT_EXTENSION_REPLACE ON)
I'm using Makefiles for a Python project. There are some Python configuration variables that I need to include in every Makefile, and the Makefiles may reside in various subdirectories within the project's root (though not more than one level deep).
In the root of the project, I created a Makefile.inc with, for example, the following contents:
define PYSCRIPT
from lib.custommodule import VAR1
print(VAR1)
endef
VAR1 := $(shell python -c '$(PYSCRIPT)')
'custommodule' lives inside a Python lib directory root of the project, and all Makefiles at the top-level that include Makefile.inc execute without errors.
In 'subdirectory/Makefile', I have:
include ../Makefile.inc
echo $(VAR1)
When I cd subdirectory && make, I receive the error:
ImportError: No module named custommodule
I've tried prepending the Python path in 'Makefile.inc' (in the define PYSCRIPT block) to include the parent directory, thinking that 'subdirectory/Makefile' was executing '../Makefile.inc' in it's own path versus its parent path, but that didn't work either.
Am I missing something that's preventing this from working? Or is there a better way of achieving what I'm attempting to?
What about a Makefile.inc with:
ROOTDIR ?= .
define PYSCRIPT
from lib.custommodule import VAR1
print(VAR1)
endef
export PYSCRIPT
VAR1 := $(shell PYTHONPATH=$(ROOTDIR) python -c "$$PYSCRIPT")
and a subdirectory/Makefile with:
ROOTDIR = ..
include $(ROOTDIR)/Makefile.inc
all:
echo $(VAR1)
Not tested.
I have a R package that I'm working on that contains code written in C and C++ under the src folder. Currently, the package compiles and works on Rstudio as it follows the default directory structure. As the project builds, I want to be able to organize my code under src, within subfolders. Following directions from "Writing R extensions" - Compiling under sub-directories, I have made a folder called 'test'(/src/test) which now contains all my files(*.c, *.cpp, *.h) and modified my Makevars like so -
SOURCES_C = $(wildcard test/*.c)
SOURCES_CPP = $(wildcard test/*.cpp)
PKG_CPPFLAGS= -I${R_HOME}/include -I.
PKG_LIBS = -L${R_HOME}/lib
CXX_STD = CXX11
OBJECTS =$(SOURCES_CPP:.cpp=.o) $(SOURCES_C:.c=.o)
all : $(SHLIB)
#PKG_CFLAGS= -Wall
clean : rm -f *.o
I want to be able to compile the program in this state, where the C/C++ files are under subfolders inside src. Using the aforementioned Makevars -> the separate object files are being built from the test folder with the correct flags and compiler, for all C/CPP files. However, there are some discrepancies with the build command for the shared object. This is the log when compiling the files under src/test which fails with an undefined symbol error.
gcc -std=gnu99 -shared -L/usr/local/lib64 -o BioCro.so test/BBox.o test/Climate.o test/Compound.o test/Grid.o test/LeafOptics.o test/Maths.o test/Normal.o test/Point3D.o test/Ray.o test/Triangle.o test/Vector3D.o test/runFastTracer.o test/Assigncropcent.o test/AuxBioCro.o test/AuxCropGro.o test/AuxMaizeGro.o test/AuxcaneGro.o test/Auxcropcent.o test/AuxwillowGro.o test/BioCro.o test/CalculateBiogeochem.o test/Calculate_Soil_Layer_Temperature.o test/CanA.o test/CanAC_3D.o test/Century.o test/Copy_CropCent_To_DayCent_Structure.o test/Copy_SoilWater_BioCro_To_CropCent.o test/CropGro.o test/CropGro_c.o test/Filling_BioCro_SoilStructure.o test/assignManagement.o test/c3CanA.o test/c3EvapoTrans.o test/c3photo.o test/c4photo.o test/caneGro.o test/createNULLc3tree.o test/cropcent.o test/dailywillow.o test/denitrify.o test/diffusiv.o test/eC4photo.o test/getIdirIdiff.o test/getsoilprop.o test/leachdly.o test/maizeGro.o test/methane.o test/microclimate_for_3Dcanopy.o test/nitrify.o test/nox_pulse.o test/pi_funcs.o test/printcropcentoutput.o test/test_mainC.o test/tgmodel.o test/tracegas.o test/update_3Dcanopy_structure.o test/wfps.o test/willowCent.o test/willowGro.o -L/usr/local/R-3.1.0/lib64/R/lib -L/usr/local/R-3.1.0/lib64/R/lib -lR
installing to /home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/
** R
** data
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/libs/BioCro.so':
/home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/libs/BioCro.so:
undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE
Error: loading failed
Compared with the successful log which builds successfully!
g++ -shared -L/usr/local/lib64 -o BioCro.so Assigncropcent.o AuxBioCro.o AuxCropGro.o AuxMaizeGro.o AuxcaneGro.o Auxcropcent.o AuxwillowGro.o BBox.o BioCro.o CalculateBiogeochem.o Calculate_Soil_Layer_Temperature.o CanA.o CanAC_3D.o Century.o Climate.o Compound.o Copy_CropCent_To_DayCent_Structure.o Copy_SoilWater_BioCro_To_CropCent.o CropGro.o CropGro_c.o Filling_BioCro_SoilStructure.o Grid.o LeafOptics.o Maths.o Normal.o Point3D.o Ray.o Triangle.o Vector3D.o assignManagement.o c3CanA.o c3EvapoTrans.o c3photo.o c4photo.o caneGro.o createNULLc3tree.o cropcent.o dailywillow.o denitrify.o diffusiv.o eC4photo.o getIdirIdiff.o getsoilprop.o leachdly.o maizeGro.o methane.o microclimate_for_3Dcanopy.o nitrify.o nox_pulse.o pi_funcs.o printcropcentoutput.o runFastTracer.o test_mainC.o tgmodel.o tracegas.o update_3Dcanopy_structure.o wfps.o willowCent.o willowGro.o -L/usr/local/R-3.1.0/lib64/R/lib -lR
installing to /home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/libs
1) The shared object compiles using g++ under default conditions, whereas under subdirectory conditions the compiler used is gcc. Can I change that behaviour via Makevars?
2) Further research allowed me to find that the undefined symbol error is a linking error fixed by the -L/-l flag. However, the -L flag is the same for both build commands. Is there any other library I am failing to link which is linked by default?
I ran into the same issue. Looking at the example of the RSiena package mentioned as an example in "Writing R Extensions" section 1.2.1.3 I noticed that that package still has some .cpp files not in a subdirectory. So I added a dummy.cpp file in src/ with the following contents:
void dummy (void)
{
}
After this g++ was correctly used for the linking step and the .so file was created as expected.
In my case it turns out that I don't need to change the Makevars files as I first mentioned in my answer. Even without the change below (so only having the dummy.cpp file present in src/) linking is done correctly.
I'll leave it in in case it may help someone else with a (slightly) different setup.
And add the corresponding .o file in the list of $(OBJECTS) variable in the Makevars file:
OBJECTS = $(SOURCES:.cpp=.o) dummy.o
I have a directory /src containing all of my source files, and /bin to store all binary after running make command. The directory is something like below:
/BuildDirectory
- - /src
- - /bin
- - configure
- - Makefile.am
- - configure.ac
- - ...
Now in Makefile.am, I have to specified:
bin_PROGRAMS = bin/x bin/y bin/z bin/k ...
bin_x_SOURCES = src/x.cpp
bin_y_SOURCES = src/y.cpp
bin_z_SOURCES = src/z.cpp
Is there any variable that can help to get rid of all "bin/" and "src/" ?
For example I just specify:
$BIN = bin
$SRC = src
And they will look for the correct files in correct folders and compile it to the correct places.
Thanks
You could take advantage of remote building. Place this makefile in the bin dir:
VPATH = ../src
bin_PROGRAMS = x y z k ...
x_SOURCES = x.cpp
y_SOURCES = y.cpp
z_SOURCES = z.cpp
Now replace the current Makefile.am with this one:
SUBDIRS = bin
Now tweak your configure.ac to also generate bin/Makefile
AC_CONFIG_FILES([Makefile
bin/Makefile])
and you should be set for life.
Not to my knowledge. If you're looking to separate your compiled files from your source files, remember that you can build outside of the tree:
$ cd foo-1.2.3
$ mkdir build
$ cd build
$ ../configure
$ make
$ make install
If this is what you're looking to do, you can make the Makefile.am simpler by creating binaries without a directory prefix (and still referencing things in src/ by hand).
If what you're trying to do is what I think you're trying to do, you're trying to achieve something like:
SRCDIR = src
BINDIR = bin
bin_PROGRAMS = $(BINDIR)/x $(BINDIR)/y $(BINDIR)/z
bin_x_SOURCES = $(SRCDIR)/x.cpp
bin_y_SOURCES = $(SRCDIR)/y.cpp
bin_z_SOURCES = $(SRCDIR)/z.cpp
I've tested this a few times in various forms, and it won't compile the code as it would with your example; I somehow convinced it that it was compiling C at one stage:
gmake[1]: *** No rule to make target `bin/x.c', needed by `x.o'. Stop.
I'm thus fairly certain that it's not possible. Sorry.