This question already has answers here:
Detect GCC compile-time flags of a binary
(4 answers)
Closed 9 years ago.
Is there any macro in c++ (using gcc) to get the compilation options used to build the executable ?
I'm sure I saw something like that in some about dialogs.
any help will be appreciated
PS: while the question in Detect GCC compile-time flags of a binary interests in finding the options activated to compile a program, I'm interesting in finding the exact command line options used to compile my program from within this program source.
Apart from creating the compile string from the
Common Predefined Macros
, which seems hectic. I think there is an easy way to do it. The gcc -V on debian gives back flags used for configuration.
However, my shot would be to get full command in ./configure equivalent step and dump it to some file like config_line.h as a define.
Something like:
./configure:
#!/bin/sh
echo "#define conf_flags \"configured with: "$*"\"" >> config_line.h
#do some configuration steps here
#maybe even compilation itself
Then:
luk32:~/projects/tests$ ./test.sh --with=test
luk32:~/projects/tests$ cat ./config_line.h
#define conf_flags "configured with: --with=test"
You get full config line defined in the external file under a define statement. I think its fairly straight forward and easy to use. And no need for much compiler magic.
It is also worth of noting you can most probably (if not always) create such file(s) right before the actual compilation so they are actually up-to-date and valid during compilation step. Answer in get-the-compiler-options-from-a-compiled-executable would imply the executable already exists, which might be a bummer in some cases.
Note: I gave bash example, but I'm pretty sure you can output similar header file under any half-descent build system, be it make, qmake, cmake, etc. the bash begin the simplest case.
I think most of them have access to the command line they are invoked with, as well as they provide easy way to get actual compile command. For example to provide two literals, one with commands used for make like -j 13 and another g++ ... used for actual compilation step performed by make.
Note2: I know this is not an answer the OP asked, but I guess it serves his purpose in the 1st place.
Because I'm using qmake build system I came across this solution :
I added this line to the end of my pro file :
QMAKE_CXXFLAGS += -DFLAGS=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\"
then retrieved what I want from the FLAGS macro
Related
I have written a program prg which can be run using bash with some subcommands like so
$ prg subcommand1
Output of subcomman1
$ prg subcommand2
Output of subcomman2
The program is written in C++11 and compiled with CMake (3.10+).
Now, I'd like to add another optional command, say optional_subcommand.
Optional - in a sense that a user can decide whether to compile program with it when configuring Cake.
To clarify, when the code is not compiled withoptional_subcommand support, the output should be something along this lines
$ prg optional_subcommand
Option not supported...
The optional_subcommand requires external library to be installed. Hence find_package(SomeLib REQUIRED) must be invoked at some stage by CMake. The code for optional_subcommand requires this library to compile.
All I can think of is writing some dummy code for optional_subcommand which is then replaced on request by CMake. I think this can be achieved be asking CMake to overwrite, say optional_subcommand.cpp with either dummy or not.
Is proposed solution sensible or perhaps there is a better way to achieve this?
CMake can define a preprocessor symbol and add extra files to your target (below, prg) if needed:
if(SomeLib_FOUND)
target_compile_definitions(prg PUBLIC HAVE_SOMELIB)
target_sources(prg PRIVATE src/optional_subcommand.cpp)
endif()
You can then wrap the command dispatching code for optional_subcommand with #ifdef HAVE_SOMELIB.
Ok, n00b question. I have a cpp file. I can build and run it in the terminal. I can build and run it using clang++ in VSCode.
Then I add gtest to it. I can compile in the terminal with g++ -std=c++0x $FILENAME -lgtest -lgtest_main -pthread and then run, and the tests work.
I install the C++ TestMate extension in VSCode. Everything I see on the internet implies it should just work. But my test explorer is empty and I don't see any test indicators in the code window.
I've obviously missed something extremely basic. Please help!
Executables should be placed inside the out or build folder of your workspace. Or one can modify the testMate.cpp.test.executables config.
I'd say, never assume something will "just work".
You'll still have to read the manual and figure out what are the names of config properties. I won't provide exact examples, because even though I've only used this extension for a short time, its name, and therefore full properties path, has already changed, so any example might get obsolete quite fast.
The general idea is: this extension monitors some files/folders, when they change, it assumes those are executables created using either gtest or catch2. The extension tries to run them with standard (for those frameworks) flags to obtain a list of test suites and test cases. If it succeeds, it will parse the output and create a nice list in the side panel. Markers in the code are also dependent on the exactly same parsed output, so if you have one, you have the other as well.
From the above, you need 3 things to make this work:
Provide correct path (or a glob pattern) for finding all test executables (while ignoring all non-test executables) in the extension config. There are different ways to do this, depending on the complexity of your setup, they are all in the documentation though.
Do not modify the output of the test executable. For example, if you happen to print something to stdout/stderr before gtest implementation parses and processes its standard flags, extension will fail to parse the output of ./your_test_binary --gtest-list_tests.
If your test executable needs additional setup to run correctly (env vars, cwd), make sure, that you use the "advanced" configuration for the extension and you configure those properties accordingly.
To troubleshoot #2 and #3 you can turn on debug logging for the extension (again, in the VSCode's config json), this will cause an additional "Output" tab/category to be created, where you can see, which files were considered, which were run, what was the output, and what caused this exact file to be ignored.
This messed with me for a while, I did as Mate059 answered above and it didn't work.
Later on I found out that the reason it didn't work was because I was using a Linux terminal inside windows (enabled from the features section) and I previously had installed the G++ compiler using the linux terminal so the compiler was turning my code into a .out file, for some reason TestMate could not read .out files.
Once I compiled the C++ source file using the powershell terminal it created a .exe file which I then changed the path in the setting.json as Mate059 said and it showed up.
TL;DR
Mate059 gave a great answer, go into settings.json inside your .vscode folder and modify "testMate.cpp.test.executables": "filename.exe".
For me it also worked using the wildcard * instead of filename.exe but I do not suggest to do that as in that might mess up something with the .exe from the main cpp file and what not.
I have been coding for over 5 years and would now like to take a step away from IDE's and try a project without one. I have the things I need to get started (I think), a HelloWorld.cpp file, the Windows Command Prompt open and Clang installed.
Now that I have these things my question is this - What do I need to type into the Command Prompt to make Clang take my C++ code in the HelloWorld.cpp file and compile it into a separate file containing the assembly code, and then make Clang take my assembly code and assemble it into a separate file containing the object code, and then finally make Clang take my object code and link it into a separate file containing the machine code?
Ultimately meaning at the end I will have 4 files, one with C++ code, one with assembly code, one with object code and finally one with machine code. The point of all of this being the ability to read and understand each stage of the process before running the file containing the machine code.
Being someone who has left the world of IDE's for the first time, I find the official Clang documentation very confusing and cannot find a straight answer to my question.
Same as with GCC, and I'll do you one better by first preprocessing the source file. In principle Clang also can emit LLVM bitcode or LLVM IR as two extra intermediate stages.
clang++ source.cpp -E
clang++ source.ii -S
clang++ source.s -c
clang++ source.o
This last one gives a.out as an executable file. You can define the output file for each command by appending
-o output.file
The extensions may not be 100% correct. Just check what comes out.
I was trying to verify if my macro really works during compilation by md5sum command in ubuntu.
For example, by "nvcc -DTEST_MACRO ...." I got an executable A.
Then by "nvcc ..." I got an executable B.
Of course the md5 values are different.
But, I recompiled and generated A again. Its md5 is different from previous one.
I took a pure c++ code and checked with g++, and its md5 value turns out to be the same no matter how many times I compiled. So I think there is something like time stamp in the executable generated by nvcc.
Just out of curiosity, how do I verify if my thought is right?
Anyway, how do I verify if "TEST_MACRO" really works in this case?
I think this variability is not necessarily due to an embedded timestamp, but rather by the way nvcc builds executables.
nvcc is a compiler-driver, meaning it launches a sequence of commands "under the hood" to compile code. During the execution of this sequence, a variety of temporary files are created with randomly-generated filenames. You can get a sense of this by looking at the output of your nvcc compile command with the -v switch added.
Some of these filenames do get embedded in the executable, and since these randomly-generated file names vary from one invocation of the nvcc compile command to the next, the resultant binary will vary.
If you want to verify this yourself, run your nvcc command with -v added. Then inspect the output at the end for a tmpxft... filename. Then grep the generated executable for that filename, eg.:
grep tmpxft_0000a76e myexe
(replace the tmpxft_0000a76e with whatever appears in your nvcc verbose output, and replace myexe with the actual name of your executable.)
If you want to verify if a TEST_MACRO really works, there are a few options. The least intrusive might be to put the following line in your TEST_MACRO body:
#ifdef TEST_MACRO
...
#warning TEST_MACRO_COMPILED
...
#endif
and you should see this echo'ed to the output during compilation, when you specify -DTEST_MACRO
(The above is a useful technique to avoid mistakenly including debug macros and other things you don't want in a production/release build of code.)
Of course, there are probably many other possibilities. If the test macro includes executable code, you could put a printf statement in it, to see evidence at run-time.
I need to have some of my C++ classes, functions and namespaces renamed as a part of my build script, which is runned by my CI system.
Unfortunatly a simple sad/awk/gsar/... technique is not enough, and I need smart rename refactoring, that carefully analyses my code.
Actually I found out, that CDT C/C++ rename refactoring does, what I need. But it does it from Eclipse IDE. So I need to find a way to start it from command line, and to make it a part of my CI build script.
I know that Eclipse has eclipsec executable, that allowes running some Eclipse functions from command line (see e.g. here).
But I can't find any suitable documentation for functions, CDT exports to command line. The only thing, I found is the this. But it doesn't solve my problem.
So, I need help to run CDT rename refactoring from command line (or someway like that). If it is not possible, may be someone will advice another tool, that can do rename refactoring for C++ from command line ?
Pragmatic Approach
"I need to have renamed as a part of my build script"
This sounds a bit like a design problem. However, I remember having been guilty of the same sin once writing a C++ application on AIX/Win32: most notably, I wanted to be able to link 'conflicting' versions of shared objects. I solved it using a simple preprocessor hack like this:
# makefile
#if($(ALTERNATIVE))
CPPFLAGS+=-DLIBNAMESPACE=MYLIB_ALTERNATIVE
#else
CPPFLAGS+=-DLIBNAMESPACE=MYLIB
#endif
./obj64/%.o: %cpp
xlC++ $(CPPFLAGS) $^ -o %#
Sample source/header file:
namespace MYLIB
{
class LibService :
{
};
}
As you can see, this required only a single
find -iname '*.[hc]pp' -o -iname '*.[hc]' -print0 |
xargs -0 sed -i 's/OldNamespace/MYLIB/g'
Eclipse Automation
You could have a look at eclim, which does most, if not all, of what you describe, however it targets the vim editor.
What eclim boasts, is full eclipse intergration (completion, refactoring, usage search etc.) from an external program. I'm not fully up to speed with the backend of eclim, but I do know that it works with a eclimd server process that exposes the service interface used by the vim plugin.
I suspect you should be able to reuse the code from eclimd if not just use eclim for your purposes.
We are completing a command-line rename tool for C++, that uses compiler accurate parsing and name resolution, including handling of shadowed names. Contact me (see bio) for further details or if you might be interested in a beta.