I am trying to understand a makefile in which a Fortran code is used with cpp for preprocessing in the following manner,
cpp -P -traditional -DMPI -DLINUX -DX86_64 -DGFORTRAN -D'HEADER="testfile.h"' -D'ROOT_DIR="/home/Desktop"'...-D'FILE_DIR="/home/Desktop/MYFILES"' -I/usr/local/include file.F
I understood the usage of include directory but I am unable to understand the purpose of -D options (named as CPPFLAGS) listed here. I see that if I remove any of the -D option, my output is modified (I get only start and end of my program and no text in between).
Edit: I have a list of ifdef options and my makefile uses different subdirectories with -D option. What is it looking in those directories, Files in which the option is defined?
If I understand you correctly, you just want to figure out the meaning of -D.
gcc -D defines a macro to be used by the preprocessor.
the syntax is below:
$ gcc -Dname [options] [source files] [-o output file]
$ gcc -Dname=definition [options] [source files] [-o output file]
If you remove any -D, it means this macro isn't defined. So your output might be changed.
Related
I want to write a command to build FooMain.cc among the following files:
$ ls src
FooMain.cc
FooMain2.cc
BarMain.cc
Helper.cc
Helper.h
FileToInclude.cc
FileToInclude.h
...
Each main file (those including Main) has main() function and they require all the other files without Main in filenames.
The straightforward way to build would be like:
clang++ [options] FooMain.cc Helper.cc FileToInclude.cc ...
Here the expression HelperOne.cc FileToInclude.cc ... includes all the files but those including Main.
What I want to do is rephrase this expression with glob expression
clang++ [options] FooMain.cc [Some clever glob expression]
I looked up for a while but could not find similar questions.
Appreciate any clues. Thank you!
Using ksh93, bash with the extglob option turned on (shopt -s extglob), or zsh with the ksh_glob option turned on (setopt ksh_glob):
$ clang++ [options] FooMain.cc !(*Main*).cc
Using zsh with the extended_glob option turned on (setopt extended_glob):
$ clang++ [options] FooMain.cc *.cc~*Main*
I'm trying to understand the following line in a Makefile.in file:
CXXFLAGS += -O3 -DNDEBUG -std=c++11 -Wno-deprecated-declarations -Isrc -I #mathinc#
I know the -I flag adds a directory to the list of places where the compiler will search for included files but what does #mathinc# mean?
Note that the file is called Makefile.in -- this signifies that it is input to another file (or transformation).
In short, configure will run and determine, say, where the relevant include files are for #mathinc -- likely some math headers. After you run configure it will produce Makefile (no trailing .in) based on what it finds. Do inspect that file.
configure scripts are created in a system called autoconf which, like all build systems, has its fans and its haters. There are some decent tutorials as for example this one.
I have uploaded the very small exemple project on a github repository
I have a school project. The specifications say that we can enable or disable a component.
I came from the c world in which we can compile c to object and chose the object to link. I try this in OCaml.
I have two source file with the same function but their effect is different.
I have two folders called "on" with implementation and "off" folder with an empty body
For the test, I have a simple a.ml and a.mli file that only print hello world and b.mli b.ml that call the module a. (so I have on/a.ml and off/a.ml)
I compile the on version and the off with this command:
ocamlc -c -I on on/a.mli on/a.ml -o on/a.cmo
then I try to link the C-way
ocamlc on/a.cmo b.ml -o on_b.exe
but I get the error
File "b.ml", line 1, characters 9-15:
Error: Unbound module A
I have then read I should specify the folder to search in with -I.
ocamlc -I on -I off on/a.cmo b.ml -o on_b.exe
I was happy because of that work for the on version
but it will not work for the off version
ocamlc -I on -I off off/a.cmo b.ml -o off_b.exe
I get the error
Error: Files b.cmo and off/a.cmo
make inconsistent assumptions over interface A
I have inspected with ocamlobjinfo it seems to build B its searches for the first module called A
In this example, I have only A and B but in future, I will build with some version on and some off... but don't do it manually
A solution found but no really efficient is to clean all .cmo and .cmi files ...
thanks for your reading and your time
EDIT:
I have also test with -open but it seems to work only for standards modules.
As you can see, compiling your .mli files produces a .cmi file. This is the file that you indicate is there by using the -I dir option.
So, if I understand you correctly, you have a a.mli in both your on and your off directory.
Now, when you refer to the module A in your code, the compiler looks for it in the current directory, then in the linked directories in the order they are given. When you compile "on", the right .cmi is found (because -I on comes before -I off in your command line). In the case of "off", the "on" cmi is found, and the compiler sees that it doesn't correspond to the right cmo.
Your two compiling lines should be:
ocamlc -I on on/a.cmo b.ml -o on_b.exe
ocamlc -I off off/a.cmo b.ml -o off_b.exe
I just recently switched back to Linux from windows and VC, but I never done any special coding using g++ compiler.
Currently my libraries (boost and others) are scattered all over the hard drive and I need to learn how to setup my compiler and linker so that all the compiler settings..
(includes, libs, flags) etc.. will be held in one single file or place, so that it becomes easy to manage, because I don't want to type these things every time I launch the compiler on command line.
Also note that I'm using a vim as my code editor and do not want to use IDE.
What is the best way to achieve that goal?
You need to use some of Building tools. It's allow you type small command (in vim you need just type :make) which launch build process with predetermined parameters (includes, libs, etc).
For C++ in Linux the most common tools are:
- make;
- automake;
- CMake.
If you use Qt also qmake is available.
I've had experience with all of them and my suggestion is use plain make for small projects and CMake for others and don't use autotools while you don't have to do it.
Note: All hight-level tools just help generate appropriate files (Makefile) for plain make (CMake generate Makefile based on CMakeLists.txt, automake based on Makefile.am, qmake based on *.pro).
because I don't want to type these things every time I launch the
compiler on command line.
I don't like to type either. All I want to do for small builds is issue:
(1) a short alias (2) the name of the file to compile, and (3) an output file.
Then I want my tool to take care of all common options, and if necessary, include the paths to any extra -I include directories, -L library directories and form the command line for me.
I have a short script that can handle the drudgery. Separating your projects into separate directories and including a 'bldflags' file with specific options allows the scripts to load any project specific options you may require. It is flexible enough to take any additional options specified on the command line. Alias the script in your .bashrc, and all that is required for quick builds is:
g+ filename.cpp outname
Now this is a very basic script and is not intented to replace proper build tools for your projects, but for quick compilations, it, or something like it, will sure cut down on the typing required. Here is the short script:
#!/bin/bash
## validate input
test -n "$1" && test -n "$2"|| { echo "insufficient input. usage: ${0//*\//} source.cpp out [options]"; exit 1; }
## set standard build flags and test if exists/source ./bldflags
stdclfags="-Wall" # add any standard flags you use.
test -r ./bldflags && bldflags="`<./bldflags`"
## show build command and call g++
echo -e "building $1 with:\n g++ $stdclfags -o $2 $1 $bldflags ${#:3}"
g++ $stdclfags -o "$2" "$1" $bldflags ${#:3}
exit 0
Make the script executable and include a simple alias in your .bashrc giving it any name you like:
alias g+='/home/david/scr/utl/bgc++.sh'
Examples of basic use: (basic without additional flags or a ./bldflags file)
$ g+ input.cpp output
building input.cpp with:
g++ -Wall -o output input.cpp
With a few extra options added on the command line:
$ g+ input.cpp output -Wunused -fno-default-inline
building input.cpp with:
g++ -Wall -o output input.cpp -Wunused -fno-default-inline
Including project specific options in ./bldflags (e.g: -I/home/david/inc -L/home/david/lib -Wl,-rpath=/home/david/lib
g+ input.cpp output -Wunused -fno-default-inline
building input.cpp with:
g++ -Wall -o output input.cpp -I/home/david/inc -L/home/david/lib -Wl,-rpath=/home/david/lib -Wunused -fno-default-inline
So to address the I don't want to type these things every time I launch the
compiler on command line, this is a very quick and easy way I've found to cut the typing down to a minimum for quick/repetitive builds where a full Makefile isn't needed.
I have inherited a sample.pot file. Now, I have added new messages in a1.c and a2.cpp. Is it possible for me to use xgettext and output the contents to same sample.pot instead of creating a new one? Eg:-
xgettext -d sample -s -o sample.pot a1.c
xgettext -d sample -s -o sample.pot a2.cpp
Is this preferred way to go in order to update the template such that old messages are also preserved? The other question is how do we distinguish translatable strings from normal strings in source code. I assume xgettext will pull all strings from mentioned source code file.
It would be great if anybody can share the correct approach..Thanks
Does the -j, --join-existing option ("join messages with existing file") not do what you need?
Note that you can specify more than one input file on the command line.
xgettext -d sample -s -j -o sample.pot a1.c a2.cpp
The simplest way to achieve this is:
xgettext -o sample.pot -s a1.c a2.cpp sample.pot
You don't need -j, --join-existing because xgettext accepts .po and .pot files as regular input files.
The option -j, --join-existing is rarely useful. In conjunction with -D, --directory it has the effect that the output file sample.pot used as an input file is not searched in the list of directories. If you use -l c, --language=c you need -j, --join-existing because sample.pot would otherwise be parsed as a C/C++ source file.
Besides, -o sample.pot, --output=sample.pot has exactly the same effect as -d sample, --default-domain=sample. You can safely omit one of them.