I'm trying to get a COTS compiler/linker suite working with CMake and for the most part everything is working well. The issue I am running into is with the librarian.
A typical call as defined in COMPILER-${lang}.cmake file would look like this:
SET(CMAKE_C_CREATE_STATIC_LIBRARY " -v -c ")
but the librarian has no specific way of being told where the object files are so I would like to prepend the object files with the binary directory so as to give the librarian a specific place to find them. However I can't come up with the right syntax to do so.
Any thoughts on how one would do this?
After much work with the compiler/linker suite, it was determined that the main problem was that the compiler did not have the ability of being told where to put the object directly - in essence it did not support the typical -o parameter.
This resulted in the compiler naming the output file whatever it wanted and not paying attention to the that was being passed to it by the make utility.
It also turns out that the main compiler executable was really just a wrapper for the preprocessor, code generator and assembler so I ended up just RE'ing it and building my own wrapper that did support the -o parameter. It was definitively easier doing that trying to get CMake to work with this non-standard approach to generating outputs. Once the compiler started supporting the -o parameter the librarian worked without any issues.
Related
I was having trouble with the linker for the embedded arm gcc compiler, and I found a tutorial somewhere online saying that I could fix my linker errors in arm-none-eabi-gcc by including the argument -specs=nosys.specs, which worked for me, and it was able to compile my code.
My chip is an ATSAM7SE256 microcontroller, which to my understanding is an arm7tdmi processor using the armv4t and thumb instruction sets, and I've been compiling my code using:
arm-none-eabi-gcc -march=armv4t -mtune=arm7tdmi -specs=nosys.specs -o <exe_name>.elf <input_files>
And the code compiles with no issue, but I have no idea if it's doing what I think it's doing.
What is the significance of a spec file? What other values can you set with -specs=, and in what situations would you want to? Is nosys.specs the value I want for a completely embedded arm microcontroller?
It is documented at: https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Overall-Options.html#Overall-Options
It is a file containing switches to override standard defaults for various build components such as the compiler, assembler and linker. For example it can be used to replace the default C library.
I have never seen it used; typically bare-metal embedded system builds explicitly specify --nostdlib then explicitly link the required library. It could be used for environment specific build environments to link other default code such as an RTOS I guess. Personally I'd rather make all that explicit on the command line that hiding it in a file somewhere.
Essentially it applies the switches specified in the file as if they were defaults, so can be used to define defaults for specific build and execution environments.
The format of the specs file is documented at https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Spec-Files.html#Spec-Files
Without seeing both the linker errors and the content of the nosys.specs file in this case it is difficult to say how or why it solved your linker problem. The alternative solution of course would be to apply whatever switches are in the specs file directly.
Is there a sensible way to get a CMake variable containing the build command or all the compiler flags that CMake will associate with a target?
It doesn't seem practical to try to gather and maintain a list of all properties that could add flags. Besides, CMake must have this info somewhere, since it has to eventually generate a build system.
From the CMake docs it looks like this feature once existed and was provided by calling build_command() but this was replaced:
Note In CMake versions prior to 3.0 this command returned a command
line that directly invokes the native build tool for the current
generator.
Is there a new command that gives the old behavior of build_command()?
Is there a sensible way to get a CMake variable containing the build command or all the compiler flags that CMake will associate with a target?
The answer is no (CMake 3.23 is latest at time of writing), not during the CMake configure step.
In general, such a thing is ill-defined, which is likely why it was removed from CMake and will likely not be re-added. The complications arising from generator expressions, multi-config generators, generators that don't construct command lines (like VS/msbuild), source-file-specific properties, and the simple fact that after the command is called, relevant state might change, all make such efforts quixotic.
Honestly, this is such an odd thing to want at configure time, I wonder if this isn't an XY problem. It's unlikely that one target depends on another in such a way that the entire eventual command line is needed (rather than a particular property) to create it.
I know this is many years later now, but what were you trying to do?
CMake provides many ways post-generation to get information about the compiler command lines.
There's the CMake File API, meant for IDE integration,
The CMAKE_EXPORT_COMPILE_COMMANDS option that creates a Clang-compatible compile_commands.json, and then there's
The CMAKE_<LANG>_COMPILER_LAUNCHER variables that would let you instrument a full command line with a custom script while the build is running.
One of these might be useful. The latter is commonly used with ccache, but can be (ab)used with any arbitrary program as long as the output file is eventually generated.
Note that the latter two only work with the Makefile and Ninja generators.
If you want the final output of how the source files will actually be compiled you will want to look at the generated files. I don't really know a better way currently:
Example:
Here is an example output from Ninja Multi
build\CMakeFiles\impl-Release.ninja
This file will list all of the compile definitions, compiler flags, include directories, object directory, etc.
Under the path "cmake-build-debug/CMakeFiles/" you'll find a folder named as "TopFolderOfYourProject.dir", where the cmake generates all its build system files, including a file "build.make". In this file you can see something like this:
CMakeFiles/somepath/somesourcefile.c
#$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --progress-dir=xxx\cmake-build-debug\CMakeFiles --progress-num=$(CMAKE_PROGRESS_1) "Building C object CMakeFiles/somepath/somesourcefile.c.obj"
Besides this, you can find extra info about the flags in the file "flags.make", it contains all extra compiler flags specified by developers.
And in "includes_C.rsp/includes_CXX.rsp" you can see the including path.
Build flags are, actually, associated with source files, because you can have differrent flags for different files. On the other hand, for the most cases these flags are equivalent.
Anyways, to get all build flags for a source file you can use COMPILE_FLAGS property:
get_source_file_property(RESULT file.cpp COMPILE_FLAGS)
Trying to do this and stumbled upon the -I option here: $ g++ -o version version.cpp -I/usr/local/qt4/include/QtCore -I/usr/local/qt4/include -L/usr/local/qt4/lib -lQtCore
I can't find any information about it
If you're looking for what -I does:
-I[/path/to/header-files]
Add search path to header files (.h) or (.hpp).
From https://caiorss.github.io/C-Cpp-Notes/compiler-flags-options.html
This pretty much just means that any #include statements you make to an external library (in your case qt) have to be referenced so that g++ knows where to look.
if my understanding is correct, question is about -i, not -L, I hope this helps:
-Idir Append directory dir to the list of directories searched for include files.
on this link
http://www.cs.virginia.edu/helpnet/Software_Development/compilers/g.html
g++ - GNU project C++ Compiler (v2 preliminary)
g++ [option | filename] ...
Capabilities
The C and C++ compilers are integrated. Both process input files through one or more of four stages: preprocessing, compilation, assembly, and linking.
C++ source files use one of the suffixes `.C', `.cc', or `.cxx'.
Options
There are many command-line options, including options to control details of optimization, warnings, and code generation, which are common to both gcc and g++. For full information on all options, see gcc(1).
Options must be separate: -dr' is quite different from- d -r '.
-c Compile or assemble the source files, but do not link. The compiler output is an object file corresponding to each source file.
-Dmacro Define macro macro with the string `1' as its definition.
-Dmacro=defn Define macro as defn
-E Stop after the preprocessing stage; do not run the compiler proper. The output is preprocessed source code, which is sent to the standard output.
- g Produce debugging information in the operating system's native format (for DBX or SDB or DWARF). GDB also can work with this debugging information. On most systems that use DBX format, `-g' enables use of extra debugging information that only GDB can use.
Unlike most other C compilers, GNU CC allows you to use ` -g' with `-O'. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.
-Idir Append directory dir to the list of directories searched for include files.
-llibrary Use the library named library when linking. (C++ programs often require `-lg++' for successful linking.)
-O Optimize. Optimizing compilation takes somewhat more time, and a lot more memory for a large function.
Without `-O', the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you would expect from the source code.
Without `-O', only variables declared register are allocated in registers. The resulting compiled code is a little worse than produced by PCC without `-O'.
With `-O', the compiler tries to reduce code size and execution time.
-o file Place output in file file.
The various clang-based completion tools (like youcompleteme) need to be told what compiler flags a source is to be compiled with. It would be nice if the compiler options to be used could be extracted from the project files. What would be easiest way to extract the flags (automatically, not manually) from either the cmake projects or the generated result in make or ninja format?
See http://clang.llvm.org/docs/LibTooling.html
Set CMAKE_EXPORT_COMPILE_COMMANDS=ON.
Ninja is actually able to print out commands to build all or specific target. And it does it extremely fast. As in on my machine in 0.033s for 1122 commands. It can print them either as shell commands or as compilation database and ycm has utility to use the compilation database.
It is important to note that the compdb ninja tool requires a rule name as argument. That does not seem to be mentioned in documentation.
The easiest is usually to do something in essence of CC=echo CXX=echo make and extract the arguments from it.
There's already an implementation of this in the clang_complete plugin, see the cc_args.py script at https://github.com/Rip-Rip/clang_complete/blob/master/bin/cc_args.py and documented in https://github.com/Rip-Rip/clang_complete/blob/master/doc/clang_complete.txt for more informations. If I'm not mistaken YCM can read .clang_complete files.
For example in clang_complete you run it like make CC='~/.vim/bin/cc_args.py gcc' CXX='~/.vim/bin/cc_args.py g++' -B
I'd not be surprised if YCM had a similar mechanism already available out of the box.
[EDIT] Yes it has, see https://github.com/Valloric/YouCompleteMe#c-family-semantic-completion-engine-usage and the "Clang's CompilationDatabase" support from the YCM documentation. Basically, either have make generate a file with the compilation flags for YCM to use or have clang generate a compilation database and have YCM use that.
I'm wanting to setup my CMakeLists.txt file so that it can generate the .clang_complete file required by the vim plugin clang_complete.
Ordinarily, you would do this by passing a parameter to the python script it supplies with the compiler and all of the parameters for compilation. Note that I am omitting the actual directory cc_args.py is in to save on space.
cc_args.py gcc test.c -o test -I~/IncludeDirs/
You can also do this during the make phase...
make CC='cc_args.py gcc' CXX='cc_args.py g++'
However, I am unsure of how to (if it is possible to) set this up within a CMakeLists.txt file. It's really annoying to have to type this in every time I want to setup clang_complete. The reason why I want to do it this way, is because I have multiple projects that I use a custom script to build the CMakeLists.txt file, so having to write a script for each one or manually place a generic one is a step I'd like to avoid.
I've tried a couple of things that have so far have come up with errors.
I've tried setting CMAKE_CC_COMPILER and CMAKE_CXX_COMPILER to lines similar to the first i.e. "cc_args.py g++". The errors that come up here say that It can't find the compiler (which is understandable).
The next thing I tried was setting the Compiler variables just to the cc_args.py and adding a flag for the actual compiler: suffice to say, that failed horribly. CMake said that it couldn't compile a test program (considering the script isn't a compiler, and the tests don't use the flags I set, I'm not surprised at this).
So without writing any other external scripts that require moving around, is there anyone that can think of a way that can do this?
The solution is to set the CXX environment variable before executing cmake. Something like that:
CXX="$HOME/.vim/bin/cc_args.py clang++" cmake ..
make
See http://www.guyrutenberg.com/2013/01/29/vim-creating-clang_complete-using-cmake/ for more details.
I know you said "without writing any other external scripts," but it seems like you just need a one-liner:
exec cc_args.py g++
And then set that file as your CMAKE_CXX_COMPILER. You could even use CMake's file() function to write the one-liner at build time if you don't want to have to distribute it.