Building precompiled header with GN - c++

I'm trying to write a GN file that generates .gch files. I've gone through the GN documentation here
I just don't understand how to implement this, i am novice when it comes to GN. So let me explain what i'm trying to achieve.
I want GN to create the following pair of compiler commands:
my-clang -x c++-header pch/hello_world.h -o pch/hello_world.h.gch
my-clang -include pch/hello_world.h -o hello.out -c hello_world.cpp
I expected to be able to create a source set in my GN file like this:
source_set("source_set0") {
precompiled_source = "//pch/hello_world.h"
precompiled_header = "../pch/hello_world.h"
cflags = [
"-include$precompiled_header"
]
sources = [
"//hello_world.cpp",
]
}
This however does not actually generate the pre-compiled header.
I expect I need to have another source_set or equivalent to specifically compile the header file, however my understanding is that the .gch suffix is required for the compiler to recognise the file as a pre-compiled header.
So i figured that i'd need to convince GN to create the specific output file based on the target
hello_world.h file output hello_world.h.gch
hello_world.cpp output hello_world.o
Ideally i'd like to be able to modify my tool specification:
tool("cxx") {{
command = "\"{cxx_exe}\" ... -c {{{{source}}}} -o {{{{output}}}}"
outputs = [
"{{{{source_out_dir}}}}/{{{{target_output_name}}}}.{{{{source_name_part}}}}.o",
**SOME CONDITION**
"{{{{source_out_dir}}}}/{{{{target_output_name}}}}.{{{{source_name_part}}}}.h.gch",
]
}}
However my reading of Tool Variables indicates that the above functionality is only available for linker_tools.
It seems as well that GN needs some convincing to associate cxx tool with .h files.
Has anyone got any experience with this or able to point me in the right direction.
TL;DR
I want to compiler header files with GN to generated .gch file
I want to use the gch in later step of compile
Following the documentation didn't help, am i misunderstanding
How to convince GN to compiler .h files
Is there i need to make sure that the compilation of the header file happens first
Thanks for your time
p.s.
cpp file contents:
int main (void){
const char* greeting = "Hello world";
print_greeting(greeting);
}
.h file contents
#pragma once
#include <iostream>
void print_greeting(const char* greeting){
std::printf("%s", greeting);
}

I got to the bottom of this, I modified the tool:
tool("cxx") {{
command = "\"{cxx_exe}\" ... -c {{{{source}}}} -o {{{{output}}}}"
precompiler_header_type = "gcc"
outputs = [
"{{{{source_out_dir}}}}/{{{{target_output_name}}}}.{{{{source_name_part}}}}.o",
**SOME CONDITION**
"{{{{source_out_dir}}}}/{{{{target_output_name}}}}.{{{{source_name_part}}}}.h.gch",
]
}}
Then update my gn file:
config("precompiled_header"){
precompiled_header="../pch/hello_world.h"
precompiled_source="//pch/hello_world.h"
}
source_set("source_set1") {
public_configs = [
":precompiled_header"
]
sources = [
"//hello_world.cpp",
]
}
In hindsight this is actually what the documentation said to do. The command lines that are created by GN now look like this
ninja.exe -t commands
"my-clang++.exe" ... -O2 -g -x c++-header -c ../pch/hello_world.h -o obj/pch/source_set1.hello_world.h-cc.gch
"my-clang++.exe" ... -O2 -g -include obj/pch/source_set1.hello_world.h-cc -c ../hello_world.cpp -o obj/source_set1.hello_world.o
Hope this helps someone in the future

Related

How can I compile three files together? [duplicate]

I've just inherited some C++ code that was written poorly with one cpp file which contained the main and a bunch of other functions. There are also .h files that contain classes and their function definitions.
Until now the program was compiled using the command g++ main.cpp. Now that I've separated the classes to .h and .cpp files do I need to use a makefile or can I still use the g++ main.cpp command?
list all the other cpp files after main.cpp.
ie
g++ main.cpp other.cpp etc.cpp
and so on.
Or you can compile them all individually. You then link all the resulting ".o" files together.
To compile separately without linking you need to add -c option:
g++ -c myclass.cpp
g++ -c main.cpp
g++ myclass.o main.o
./a.out
Now that I've separated the classes to .h and .cpp files do I need to use a makefile or can I still use the "g++ main.cpp" command?
Compiling several files at once is a poor choice if you are going to put that into the Makefile.
Normally in a Makefile (for GNU/Make), it should suffice to write that:
# "all" is the name of the default target, running "make" without params would use it
all: executable1
# for C++, replace CC (c compiler) with CXX (c++ compiler) which is used as default linker
CC=$(CXX)
# tell which files should be used, .cpp -> .o make would do automatically
executable1: file1.o file2.o
That way make would be properly recompiling only what needs to be recompiled. One can also add few tweaks to generate the header file dependencies - so that make would also properly rebuild what's need to be rebuilt due to the header file changes.
.h files will nothing to do with compiling ... you only care about cpp files... so type g++ filename1.cpp filename2.cpp main.cpp -o myprogram
means you are compiling each cpp files and then linked them together into myprgram.
then run your program ./myprogram
I know this question has been asked years ago but still wanted to share how I usually compile multiple c++ files.
Let's say you have 5 cpp files, all you have to do is use the * instead of typing each cpp files name E.g g++ -c *.cpp -o myprogram.
This will generate "myprogram"
run the program ./myprogram
that's all!!
The reason I'm using * is that what if you have 30 cpp files would you type all of them? or just use the * sign and save time :)
p.s Use this method only if you don't care about makefile.
You can still use g++ directly if you want:
g++ f1.cpp f2.cpp main.cpp
where f1.cpp and f2.cpp are the files with the functions in them. For details of how to use make to do the build, see the excellent GNU make documentation.
As rebenvp said I used:
g++ *.cpp -o output
And then do this for output:
./output
But a better solution is to use make file. Read here to know more about make files.
Also make sure that you have added the required .h files in the .cpp files.
You can use several g++ commands and then link, but the easiest is to use a traditional Makefile or some other build system: like Scons (which are often easier to set up than Makefiles).
If you want to use #include <myheader.hpp> inside your cpp files you can use:
g++ *.cpp -I. -o out
I used to use a custom Makefile that compiled all the files in current directory, but I had to copy it in every directory I needed it, everytime.
So I created my own tool - Universal Compiler which made the process much easier when compile many files.
You can do that using a single command assuming all the needed .cpp and .h files are in the same folder.
g++ *.cpp *.h -Wall && ./a.out
It will compile and execute at the same time.
when using compiler in the command line, you should take of the following:
you need not compile a header file, since header file gets substituted in the script where include directive is used.
you will require to compile and link the implementation and the script file.
for example let cow.h be header file and cow.cpp be implementation file and cow.cc(c++ files can have extension .cpp, .cc, .cxx, .C, .CPP, .cp) be script file.
Since gcc compiler notation for c++ file is g++, we can compile and link the files using
$g++ -g -Wall cow.cpp cow.cc -o cow.out
options '-g' and '-Wall' are for debugging info and getting warning for errors. Here cow.out is the name of the executable binary file that we can execute to run the program. it is always good to name your executable file otherwise name will be automatically given which might be confusing at times.
you can also do the same by using makefiles, makefiles will detect, compile and link automatically the specified files.
There are great resources for compilation using command line
enter link description here
~/In_ProjectDirectory $ g++ coordin_main.cpp coordin_func.cpp coordin.h
~/In_ProjectDirectory $ ./a.out
... Worked!!
Using Linux Mint with Geany IDE
When I saved each file to the same directory, one file was not saved correctly within the directory; the coordin.h file. So, rechecked and it was saved there as coordin.h, and not incorrectly as -> coordin.h.gch. The little stuff.
Arg!!

Trying to compile simple project that uses TRI DDS using cygwin gcc

I am trying to take the TRI DDS example code. It is all setup to build with MSVS2012 and comes with MSVS2012 proj/solution files.
However I want to try to build this using Cygwin and g++/gcc. I have got so far and then hit issues.
My cpp/h files are taken from their example - the user code is basic c++ but the generated files / RTI DDS files I think are causing an issue.
The basic source files are:
Hello.cpp
HelloPublisher.cpp/h
HelloSubscriber.cpp/h
HelloWorld.idl
RTI-DDS generator uses HelloWorld.idl to generate further files (.cxx/h files). I am not expecting to change any of the RTI-DDS files and the code within the 4 source files are fairly vanilla, so I can compile them if I hack out all the calls to RTI-DDS.
The area I want to focus on is the makefile / environment. Here are the pertinent parts of my makefile (note the linker parts are not complete because I have not got that far yet - the compile still fails):
note NDDSHOME = c:\Program Files\rti_connext_dds-5.3.0 as an env var.
# Setup minimal "un-polluted" paths to try to avoid any conflicts
makePaths=/usr/local/bin:/usr/bin:$(NDDSHOME)/bin
export PATH := $(makePaths)
#Include Paths
INCLUDES = -I. -I"$(NDDSHOME)/include" -I"$(NDDSHOME)/include/ndds" -I"$(NDDSHOME)/include/ndds/hpp"
#Compiler / options:
DEFINES = -DRTI_WIN32 -DRTI_STATIC -DWIN32 -D_WIN32_WINNT=_WIN32_WINNT_WIN7
CC = g++
CC_FLAGS = -std=c++11 -Wall -Wextra -lWS2_32
EXEC = run
# C++ files
SOURCES = $(wildcard *.cpp)
OBJECTS = $(SOURCES.cpp=.o)
# Main Target
$(EXEC): $(OBJECTS)
# Don't do linking yet - compile not working!
%.o: %.cpp
$(CC) $< -o $# -c $(DEFINES) $(CC_FLAGS) $(INCLUDES)
I know the INCLUDES paths are working because I get different errors when they are not (can't find...)
But the error I get at the moment is:
/usr/include/w32api/winsock2.h:1004:68: error: conflicting declaration of c function 'int gethostname(char*, int)'
:
:
/usr/include/sys/unistd.h:268:6 note: previous declration 'int gethostname(char *, size_t)'
note I have to copy this by hand from my other PC... so I have abbreviated the complete message.
I thought I was close to solving this by looking at other questions with similar errors, but I can't quite make the connection to fix this. I have tried adding other defines to specify the windows version, but that did not fix it. I know there is a linker option that we need to use for things like mingw that is what the -lws2_32 flag is set for - but I have not got to the linker stage yet :(
I guess either the unistd.h or the winsock2.h should not really both be included, but I can't quite figure out what define (or other) I need to add...
Any ideas?

Scons - build order of Fortran files

Building modules in Fortran needs to be done in a specific order, e.g. if a file A.f needs module defined in B.f, then B.f needs to be compiled first. How can I impose such build order in Scons? If I provide it with a list of source files, it arranges them alphabetically (so A.f is compiled before B.f). I read about Requires() and Depends() functions, but wasn't able to get them to work for me.
I would be happy with just listing source files in order I need them compiled (so disabling reshuffling them in alphabetical order), but any other method would be welcomed as well.
As per Kyle's request, here's my Sconscript and a build log:
# Main program building script
Import('env')
PROGRAM = 'main.exe'
SRC_PREFIX = './src/'
SRC = [ 'array_1D_module.f',
'array_2D_module.f',
'array_3D_module.f',
'thomas_algorithm_module.f',
'histogram_module.f',
'histogram_computer_module.f',
'density_parameters_module.f',
'diffusion3D_aos_z_sub_solver_module.f',
'diffusion3D_aos_y_sub_solver_module.f',
'diffusion3D_aos_x_sub_solver_module.f',
'diffusion3D_aos_solver_module.f',
'nonlinear_diffusion_utilities_module.f',
'nonlinear_diffusion_parameters_module.f',
'derivative_magnitude_computer_module.f',
'nonlinear_diffusion_module.f',
'main_module.f',
'main.f' ]
# Attach prefix to each source file
for i in range( len(SRC) ) :
SRC[i] = SRC_PREFIX + SRC[i]
env.Program(target = PROGRAM, source = SRC)
This produced:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
ifort -o src/array_1D_module.o -c src/array_1D_module.f
ifort -o src/array_2D_module.o -c src/array_2D_module.f
ifort -o src/array_3D_module.o -c src/array_3D_module.f
ifort -o src/density_parameters_module.o -c src/density_parameters_module.f
ifort -o src/derivative_magnitude_computer_module.o -c src/derivative_magnitude_computer_module.f
ifort -o src/diffusion3D_aos_solver_module.o -c src/diffusion3D_aos_solver_module.f
src/diffusion3D_aos_solver_module.f(7): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [DIFFUSION3D_AOS_Z_SUB_SOLVER_MODULE]
use diffusion3D_aos_z_sub_solver_module, only :
------------^
So density_parameters_module.f was compiled before thomas_algorithm_module.f, even though it comes after it in my list.
Is your program (as suggested) using modules? There's a couple of gotchas there:
FORTRANMODDIR needs defining: See http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=82725 for a discussion on that.
I found that having source files containing a mixture of module definitions and source code caused a certain amount of confusion.

Why the success of SCons build depends on variant_dir name?

I am bored to death with such behavior. So in SConstruct file we have the last string like this one:
import compilers, os
env = Environment(ENV = os.environ, TOOLS = ['default'])
def set_compiler(compiler_name):
env.Replace(FORTRAN = compiler_name)
env.Replace(F77 = compiler_name)
env.Replace(F90 = compiler_name)
env.Replace(F95 = compiler_name)
def set_flags(flags):
env.Replace(FORTRANFLAGS = flags)
env.Replace(F77FLAGS = flags)
env.Replace(F90FLAGS = flags)
env.Replace(F95FLAGS = flags)
mod_dir_prefix = {
"gfortran": "-J ",
"ifort": "-???",
"pgfortran": "-module "
}
flags = {
("gfortran", "debug"): "-O0 -g -Wall -Wextra -pedantic -fimplicit-none -fbounds-check -fbacktrace",
("gfortran", "release"): "-O3",
("pgfortran", "debug"): "-O0 -g -C -traceback",
("pgfortran", "release"): "-O4"
}
if not GetOption('clean'):
print "\nAvailable Fortran compilers:\n"
for k, v in compilers.compilers_dict().iteritems():
print "%10s : %s" % (k, v)
compiler = raw_input("\nChoose compiler: ")
set_compiler(compiler)
debug_or_release = raw_input("\nDebug or release: ")
set_flags(flags[(compiler, debug_or_release)])
env.Replace(FORTRANMODDIRPREFIX = mod_dir_prefix[compiler])
env.Replace(LINK = compiler)
env.Replace(LINKCOM = "$LINK -o $TARGET $LINKFLAGS $SOURCES $_LIBDIRFLAGS $_LIBFLAGS $_FRAMEWORKPATH $_FRAMEWORKS $FRAMEWORKSFLAGS")
env.Replace(LINKFLAGS = "")
env.Replace(FORTRANMODDIR = '#Mod')
Export('env')
SConscript('Sources/SConscript', variant_dir='Build', duplicate=0)
compilers.py is my own module to find some Fortran compilers which are available.
In Sources folder we have a couple of Fortran source files.
Sources\SConscript
Import('env')
env.Program('app', Glob('*.f90'))
Scons supports Fortran and everything works fine.
gfortran -o Temp\kinds.o -c -O3 -JMod Sources\kinds.f90
gfortran -o Temp\math.o -c -O3 -JMod Sources\math.f90
gfortran -o Temp\sorts.o -c -O3 -JMod Sources\sorts.f90
gfortran -o Temp\utils.o -c -O3 -JMod Sources\utils.f90
gfortran -o Temp\main.o -c -O3 -JMod Sources\main.f90
gfortran -o Temp\app.exe Temp\kinds.o Temp\main.o Temp\math.o Temp\sorts.o Temp\utils.o
scons: done building targets.
After renaming variant_dir name to let say #Bin or #Build we get error message:
gfortran -o Bin\kinds.o -c -O3 -JMod Sources\kinds.f90
gfortran -o Bin\main.o -c -O3 -JMod Sources\main.f90
Sources\main.f90:3.11:
USE sorts
1
Fatal Error: Can't open module file 'sorts.mod' for reading at (1): No such file or directory
Of course the order of compilation matters. But why it depends on variant_dir name? Seems like a bug, but maybe I'm doing something wrong.
P.S. This behavior doesn't depend on duplicate variable value.
P.P.S. Tested with SCons 2.0.1 on Windows with Python 2.7 and Mac OS X with Python 2.5.1.
This is a reply to an old thread, but I had virtually the same problem and needed to dig around for a solution.
Firstly, your build order is probably off because the dependency scanner for Fortran does not work properly. Try running
scons [your_arguments] -n --tree=all | less
which won't actually compile anything but show you the commands and in the end will print the dependency tree as Scons sees it.
A possible solution:
Try adding the line (I added your source for context):
env.Replace(FORTRANMODDIR = '#Mod')
env.Replace(FORTRANPATH = '.' ]
Export('env')
As far as I understand, paths are relative to the "virtual" location of the SConscript file (i.e. the src directory or the variant build directory), this should add the directory containing the source files to the scanner's search path.
In my version of scons (2.3.0), I cannot use the duplicate=0 argument, since it automatically inserts the original source directory into the module path, causing the command line to look like -module build/ -module src/ (ifort) and essentially overriding my preference not to clutter the source directory. This might be a bug, though.

Using G++ to compile multiple .cpp and .h files

I've just inherited some C++ code that was written poorly with one cpp file which contained the main and a bunch of other functions. There are also .h files that contain classes and their function definitions.
Until now the program was compiled using the command g++ main.cpp. Now that I've separated the classes to .h and .cpp files do I need to use a makefile or can I still use the g++ main.cpp command?
list all the other cpp files after main.cpp.
ie
g++ main.cpp other.cpp etc.cpp
and so on.
Or you can compile them all individually. You then link all the resulting ".o" files together.
To compile separately without linking you need to add -c option:
g++ -c myclass.cpp
g++ -c main.cpp
g++ myclass.o main.o
./a.out
Now that I've separated the classes to .h and .cpp files do I need to use a makefile or can I still use the "g++ main.cpp" command?
Compiling several files at once is a poor choice if you are going to put that into the Makefile.
Normally in a Makefile (for GNU/Make), it should suffice to write that:
# "all" is the name of the default target, running "make" without params would use it
all: executable1
# for C++, replace CC (c compiler) with CXX (c++ compiler) which is used as default linker
CC=$(CXX)
# tell which files should be used, .cpp -> .o make would do automatically
executable1: file1.o file2.o
That way make would be properly recompiling only what needs to be recompiled. One can also add few tweaks to generate the header file dependencies - so that make would also properly rebuild what's need to be rebuilt due to the header file changes.
.h files will nothing to do with compiling ... you only care about cpp files... so type g++ filename1.cpp filename2.cpp main.cpp -o myprogram
means you are compiling each cpp files and then linked them together into myprgram.
then run your program ./myprogram
I know this question has been asked years ago but still wanted to share how I usually compile multiple c++ files.
Let's say you have 5 cpp files, all you have to do is use the * instead of typing each cpp files name E.g g++ -c *.cpp -o myprogram.
This will generate "myprogram"
run the program ./myprogram
that's all!!
The reason I'm using * is that what if you have 30 cpp files would you type all of them? or just use the * sign and save time :)
p.s Use this method only if you don't care about makefile.
You can still use g++ directly if you want:
g++ f1.cpp f2.cpp main.cpp
where f1.cpp and f2.cpp are the files with the functions in them. For details of how to use make to do the build, see the excellent GNU make documentation.
As rebenvp said I used:
g++ *.cpp -o output
And then do this for output:
./output
But a better solution is to use make file. Read here to know more about make files.
Also make sure that you have added the required .h files in the .cpp files.
You can use several g++ commands and then link, but the easiest is to use a traditional Makefile or some other build system: like Scons (which are often easier to set up than Makefiles).
If you want to use #include <myheader.hpp> inside your cpp files you can use:
g++ *.cpp -I. -o out
I used to use a custom Makefile that compiled all the files in current directory, but I had to copy it in every directory I needed it, everytime.
So I created my own tool - Universal Compiler which made the process much easier when compile many files.
You can do that using a single command assuming all the needed .cpp and .h files are in the same folder.
g++ *.cpp *.h -Wall && ./a.out
It will compile and execute at the same time.
when using compiler in the command line, you should take of the following:
you need not compile a header file, since header file gets substituted in the script where include directive is used.
you will require to compile and link the implementation and the script file.
for example let cow.h be header file and cow.cpp be implementation file and cow.cc(c++ files can have extension .cpp, .cc, .cxx, .C, .CPP, .cp) be script file.
Since gcc compiler notation for c++ file is g++, we can compile and link the files using
$g++ -g -Wall cow.cpp cow.cc -o cow.out
options '-g' and '-Wall' are for debugging info and getting warning for errors. Here cow.out is the name of the executable binary file that we can execute to run the program. it is always good to name your executable file otherwise name will be automatically given which might be confusing at times.
you can also do the same by using makefiles, makefiles will detect, compile and link automatically the specified files.
There are great resources for compilation using command line
enter link description here
~/In_ProjectDirectory $ g++ coordin_main.cpp coordin_func.cpp coordin.h
~/In_ProjectDirectory $ ./a.out
... Worked!!
Using Linux Mint with Geany IDE
When I saved each file to the same directory, one file was not saved correctly within the directory; the coordin.h file. So, rechecked and it was saved there as coordin.h, and not incorrectly as -> coordin.h.gch. The little stuff.
Arg!!