I've come across a build system that uses scons. Not being familiar at all with scons itself being a rather sophisticated framework I get very frustrated not being able to debug build issues.
I want scons to printout the fully expanded command line being invoke ( as you see with most build systems) I found out you could use the --debug=presub option but ( at least on OSX ) it is useless since it prints the value of unexpanded variables
for example:
Building build/obj/ios-uni-rel-sta-clang/common/libs/boost/libs/date_time/src/gregorian/date_generators.i386.o with action:
$SHCXX -o $TARGET -c $SHCXXFLAGS $SHCCFLAGS $_CCCOMCOM $SOURCES
There is also a VERBOSE=1 parameter you can supply on the scons command line but ( at least with the 2.3.4 ) version I got, it doesn't seem to be verbose much anything.
I'm not saying Scons is bad, but it is become a bit taxing and expansive to maintain :(
Anyone familiar with Scons? What module, where is the actual command gets invoked? I just want to add a few prints ...
Alternatively, how can you setup PyDev or PyCharm to hook up using the scons --debug=pdb? Did anyone this?
Somewhere in a SConstruct, SConscript, or some python module loaded by either (could be in site_scons under top dir) someone is changing the *COMSTR env variables.
It will look something like:
env['SHCXXCOMSTR'] = "Building $TARGET"
or:
for k in env.keys():
if k.endswith('COMSTR'):
env[k] = "Building $TARGET"
You'll want to comment out those lines.
The default SCons behavior is to show the command lines.
http://scons.org/doc/production/HTML/scons-man.html#cv-SHCXXCOMSTR
SHOWBUILD=1
For example:
$>scons SHOWBUILD=1
This worked for me
Related
Sorry, I'm new to Xcode and not very familiar with it, I use Xcode (command line tool project with external build system) to compile cpp files and automatically execute cpp unix executable files. After the program is compiled (command+R), I set the settings as shown in the screenshot below to automatically execute. Is there any way for me to execute also add additional commands?
Such as iconv.
The following line is what I ultimately want to execute.
./myFile argument1 | iconv -f big5
But my Xcode looks like it's executing only
./myFile argument1
really thanks
On the same place where you setup the build scheme, you can also add a post-build script.
Go to the left of the panel, and expand Build
Select Post-actions
Near the bottom center, click on + -> New Run Script Action
Add script like you would run them in terminal
Note the current directory will not be where the project is built
You can use ${TARGET_BUILD_DIR} macro for the build directory
Note, you want to make sure to select your current project at the Provide build settings from so it can import the correct path macros like TARGET_BUILD_DIR
A screenshot of adding a post-build script:
*Older versions of Xcode might have different GUI, but the idea should be about the same.
Sidenote, ⌘R is really for running the program within Xcode, consider using ⌘B.
I have some Python scripts which should run when building the Flutter Windows app. It looks like:
find_package( PythonInterp 3 REQUIRED )
add_custom_target(
myscript ALL
COMMAND ${PYTHON_EXECUTABLE} somefile.py
)
add_dependencies(${PLUGIN_NAME} myscript)
However, in my script, I need to know whether it is doing a debug or a release build. But I cannot find out an approach to do this.
I have tried to print every cmake variable, and nothing indicates it is a debug or release. I have also tried to print out all environment variables in the python script, but again nothing interesting.
Thanks for any suggestions!
In https://github.com/flutter/flutter/issues/99595, #stuartmorgan provides a good answer, so I paste it here in case someone needs it:
There is nothing special about the CMake builds used in the Flutter template; determining the build type is done in the usual way.
And that "usual way" is https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-configurations :
# Works correctly for both single and multi-config generators
target_compile_definitions(exe1 PRIVATE
$<$<CONFIG:Debug>:DEBUG_BUILD>
)
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 am trying to build SOCI on Windows with a different library suffix using the CMAKE_SHARED_LIBRARY_SUFFIX option, but the script seems to ignore it.
Here is the command I run in a batch file:
cmake^
-G "NMake Makefiles"^
-DCMAKE_BUILD_TYPE=Release^
-DCMAKE_SHARED_LIBRARY_SUFFIX="-vc140-x64-mt.dll"^
..\soci.3.2.3
The documentation does not say anything about the CMAKE_SHARED_LIBRARY_SUFFIX option, but the core/CMakeLists.txt script uses it to define the SOCI_LIB_SUFFIX option, which is reported on the screen when cmake is run. However, its value is always ".dll" instead of "-vc140-x64-mt.dll", so it must be overwritten somewhere I don't know.
Any idea why is this happening and how fix it?
Sorry about the title, couldn't really think of anything else to describe the problem :)
Ok, so the thing is like this: I'm trying to use a proprietary freeware application under Linux (and hence the problem; if I had the source, I could have rebuilt it). Furthermore, I'm trying to run it on an unsupported flavor of Linux, and nearly all components of the application work individually, but not together (as they should if the application ran fully).
Let me clarify a bit. There is a GUI, that starts up fine in the unsupported OS. Then, from this GUI, you can call a bunch of command line tools - helpfully, the GUI also spits out the command line being called in each case.
Now, called from the GUI some of these commands fail - however, since I have the actual command line called (let's say: "extprogram -arg1 1 -arg2 2 ..."), I can repeat these from the terminal. And so, I discover that the application as a whole carries it's own libc libraries; and using these libraries, (some of) the commands (ran from the terminal) tend to fail - however, I discovered that from the command line, this usually works for those that fail:
LD_PRELOAD=/usr/lib/libstdc++.so.6 extprogram -arg1 1 -arg2 2 ...
# or alternatively, this works too:
# LD_LIBRARY_PATH=/usr/lib extprogram -arg1 1 -arg2 2 ...
(in other words, using the system libstdc++ instead of the application supplied one, tends to fix things)
So, now if I could persuade the GUI to call these tools with "LD_PRELOAD"/"LD_LIBRARY_PATH" - I guess, all would work fine...
Unfortunately, the GUI doesn't call a script that would further call these executables, which I could change directly (as far as I could see via grepping) - seemingly, it's the GUI executable that creates the system calls; I tried 'strace'-ing, but I cannot find something like a temporary script or anything that I could change...
So, I thought maybe I could "cheat" with making an executable bash script; so I move the executable - and create a script that should call the moved executable with LD_ prepended:
mv extprogram extprogram.old
cat > extprogram <<EOF
LD_LIBRARY_PATH=/usr/lib extprogram $#
EOF
... but this fails; apparently GUI application recognizes something is not right.
So, I was thinking - is it possible to somehow, maybe, have a C/C++ code "wrapper" that would somehow "load" this executable, but in an "environment" which has "LD_LIBRARY_PATH=/usr/lib" set - and pass it its arguments (and also return it's return value)? Then I could build this "wrapper" natively on the OS, with the same name as the original executable - and have the whole thing working, without touching the original executable (apart from renaming).
Many thanks in advance for any answers,
Cheers!
You're close. You forgot the shebang and to make the script executable. Also you were calling the wrong external program. Finally, I'd use the absolute path to the old script, because you don't know what the CWD will be for the GUI.
mv extprogram extprogram.old
cat > extprogram <<EOF
#!/bin/sh
LD_LIBRARY_PATH=/usr/lib exec /psth/to/extprogram.old "$#"
EOF
chmod +x extprogram
using the system libstdc++ instead of the application supplied one, tends to fix things
I'd be curious to know what problems using the application-supplied libstdc++.so.6 causes, but if the system one fixes things, then a much simpler solution is to remove (rename) the troublesome library, rather than doing the whole shell wrapper solution.
If the application can't find the "bad" library, there is a good chance it will find the system one.