I just upgraded to Qt 5.6.0. I noticed something that I did not notice before. A new project in Qt Creator gets now three build configurations: "release", "debug" and "profile", It seems to me that "profile" is new. If so what is its purpose?
When I looked at Projects -> Build steps -> Effective qmake call,
I have found this additional CONFIGS:
"CONFIG+=force_debug_info" "CONFIG+=separate_debug_info"
Also I found some comments for them that could clarify why this is needed:
Hello all,
once more I'm preparing a Qt 5 build for profiling purposes and wonder again
why there is no way to combine -release and -debug in Qt's configure
script. The only way to get a sane build for profiling Qt code itself that
I know of is hacking the mkspec and ensuring that -g is added even in
-release mode.
Is there any reason for that? Could we improve this situation somehow to
make it simpler to get a Qt build with optimizations and debug symbols?
Am I missing the recommended way to get this done?
This option produces release builds (with all compiler optimization), but with debug symbols (pdb files) that are required for testing performance of C++.
According to the online Qt documentation (Breadcrumb: "Qt Creator Manual" > "Specifying Build Settings", end of 1st paragraph):
A profile configuration is an optimized release build that is delivered with separate debug information. It is best suited for analyzing applications.
Link can be found here. I'm still a Qt newbie, and have personally never used this configuration.
Related
Some background: I am using Meson for an embedded C project. I have it working (example), but it isn't very clean.
The specific problem I would like to solve is including an out-of-tree Board Support Package (BSP) - a tree of headers and C files that act as initialization and abstraction code for a particular platform.
Previously I have been copying headers out of a vendor-provided BSP into my project on an as-needed basis, which does work, but there are disadvantages to doing this, the most important being the lack of reproducibility. Additionally, it causes duplication of code and makes it difficult to track where a particular bug came from if the bug is in the BSP.
The ways I have tried are:
Use an option in meson_options.txt to tell Meson where the BSP is on disk via meson configure. The issue with this method is that Meson throws an error during setup because options cannot be set until after setup is complete, and so it cannot find the requisite directories and refuses to continue.
Use a subproject and repeat the above - this causes the same issue.
I would ideally like the end-user to be able to set the BSP path with meson configure, instead of having to ever edit the build description (the whole point of Meson is to be user friendly!).
Is this possible? If it is not possible, why, and are there alternatives/common practice ways of doing this that I should know about?
In your question, you state that
options cannot be set until after setup is complete
That is not true. You can pass any option you want during the meson setup, using the following syntax:
$ meson <build dir> -D<option>=<value>
So I think the first way you tried to implement your option was correct, you just need to tell the user to set it directly during setup.
Due to:
extensive usage of code auto-generation (notably for the .isa instruction and decoder sublanguage)
scons symlinking sources into the build tree, and in particular symlinking src/arch/ARCH to src/ARCH
it becomes very hard to setup Eclipse to work well with gem5.
Has anyone managed to achieve a good setup? Especially interested in Linux hosts.
I have achieved a very good setup with the following horrendous hack: define the Eclipse project inside the build/ARM directory itself!
This is done by creating a "New makefile project with existing code" in the build directory. You will also want to fix the C++ standard library as mentioned at: How to solve "Unresolved inclusion: <iostream>" in a C++ file in Eclipse CDT?
This works amazingly because the way the gem5 build system works as of May 2020, the build/ARM directory contains exactly the final compilation tree, including all the source symlinks and autogenerated code,.
This setup is not perfect because there is still some C++ stuff in build/ outside of ARM, e.g. ext, but 99% of the time we don't care about those, and I can perfectly navigate key autogenerated code such as instructions and decoder.
I then just build via the command line normally with scons.
Humongous autogenerated files like exec-ns.cc.inc turn on Eclipse's large file limited mode. Notably, if you want to jump to a definition, Ctrl + click does not work for me, so I just copy the symbol of interest and Ctrl + Shift + T to go to its definition.
I don't usually bother to try GDB step debug gem5 through Eclipse and use it mostly for code navigation, since GDB Dashboard tends to work well enough for me, and I often need to do new log collection runs and I sometimes use reverse debugging when things get serious.
But I have tested step debugging through Eclipse, and it did work normally (no reason not to I guess), you just have to set it up in exactly the same was as for any other C++ application with a Makefile, i.e. basically tell eclipse the Binary name and the desired CLI on the debug configurations.
You have of course as usual to choose between a gem5.debug debug build or a gem5.opt build, where the .debug build is about 10-20x slower but gives greater debug visibility. In general, if the time to reach the point of interest in a debug build starts to annoy you however, what you tend to really want is to do use reverse debugging.
This is also mentioned at: https://cirosantilli.com/linux-kernel-module-cheat/#gem5-eclipse-configuration
Tested in Eclipse 2020-03.
Trying investigate how to create "Hello world" on different languages via HaxeDevelop. I'm newbie and may be inacurate at terminology.
1) C# project. Pressing F8 gives me error:
haxe -cp src -cs D:/Programs/Projects/CsTestHaxe/bin/ -main Main
Unix.Unix_error(8, "mkdir", "D:/Programs/Projects/CsTestHaxe/bin/")
Build halted with errors (haxe.exe).
Via googling pretty much outdated info at least found solution:
haxe -main Main -cs out
And it works but ouput go to "src" location which is bad. Next googling led me to "Custom build" and using .hxml with pre-build command at project settings.
But why default template/settings not works for such simple thing as "Hello world" (used cs.system.Console)?
How default build may be fixed / probably I've installed or setup something wrong via HaxeDevelop installation?
2) C++ project. Pressing F8 gives me error:
Warning: Could not find environment variables for Visual Studio
Missing HXCPP_VARS
Error: Could not automatically setup MSVC
Error: Build failed
Build halted with errors (haxe.exe).
Using command line (similar to C# above) I can exucute C++ sources, but cant compile it.
Installed Visual Studio Community 2017. Nothing changed, same error. VS provide different own parts for installation. Should I install any specific?
Found also many threads about OpenFL workaround for C++ compilation. But I needn't OpenFL and want to use default Haxe API and tools.
Also OpenFL and C++ always mentioned with Lime. Do I need it too? Installed Lime via command line. But seems nothing changed.
3) Am I right that HaxeDevelop not yet support HashLink?
And if possible couple words about why HashLink appeared if there is Neko affiliated with Haxe?
As a result here an additional question: is it right that Haxe during compilation to target platform only "convert" .hx source to target one and then using third party (target platform) compile?
1) C# project. Pressing F8 gives me error.
This appears to be a known Haxe issue. Since it's been fixed on the dev branch, you could try a nightly build from build.haxe.org. Alternatively, you could also try manually creating the bin directory, since that seems to be what the error is about.
2) C++ project. Pressing F8 gives me error:
The latest Haxelib release of hxcpp (3.4.64) does not support Visual Studio 2017 yet. You could use a development version by installing hxcpp from GitHub, since again, it should be fixed there:
haxelib git hxcpp https://github.com/HaxeFoundation/hxcpp
The alternative is to downgrade Visual Studio.
Also OpenFL and C++ always mentioned with Lime. Do I need it too?
Yes, if you want to use OpenFL, you also need Lime, as OpenFL depends on it.
3) Am I right that HaxeDevelop not yet support HashLink?
Actually, a HashLink project template was added. But to follow the general theme of this answer, it seems it hasn't made it into an official relase yet. You can get a nightly build from here.
And if possible couple words about why HashLink appeared if there is Neko affilated with Haxe?
There is a two-part blog series on haxe.org by HashLink's author: part 1, part 2. The first part has a paragraph talking about this exact topic. Here's an excerpt:
First, let me explain the reasons for writing another virtual machine in replacement of Neko.
[...]
Back then, the Neko virtual machine was not especially designed to run Haxe and suffered from some limitations, the main one being performance.
[...]
And to your final question:
is it right that Haxe during compilation to target platform only "convert" .hx source to target one and then using third party (target platform) compile?
That is true for some targets, but it depends. For C++, C# and Java, Haxe indeeds generates source code for the target language and then invokes the target-native compiler after doing its own compilation (this step is usually called "native compilation").
However, some targets produce byte code directly (SWF and Neko), so there is no native compilation step there. Other target languages are interpreted (JS, PHP, Python and Lua), so there's no native compilation step there either. For HL it actually depends, there is HL/Jit (byte code) and HL/C, which is compiled to native C code.
You can find a comprehensive list of Haxe targets an their characteristics here.
Phew, that was a lot of questions in one. ;)
E.g. how should I build release and debug version at the same time? I guess the answer make use of cache variables and some kind of "collection" of them.
Is it common way to get configuration params from cache params, isn'it ? If the answer is yes, how should I use several "collections" of them in a best way ?
Thanks a lot!
You don't specify the platform you are talking about. The Makefiles based generators will only build one configuration at a time, and the normal way to build several configurations is to use separate build trees, e.g. one for 64-bit Linux on Intel, one for 32-bit Windows, etc. Most CMake projects advise out of source builds, and assuming you wrote your CMakeLists files correctly you could have ~/src/YourProject, and ~/build/YourProject-Release, ~/build/YourProject-Debug.
This is the advised way to do it, assuming your source tree does not have any CMakeCache.txt etc in it. You can then run cmake -DCMAKE_BUILD_TYPE:STRING=Debug ~/src/YourProject in the debug directory, and similar for the release. This has the advantage that you can point dependent projects at the appropriate configuration.
The Boost CMake project has also explored building all configurations in the same build tree using library name mangling to differentiate. This may be worth looking at if you must build all configurations in the same build tree.
(for fellow googlers)
Be careful of not confusing build types and build configurations.
If you really mean "build types" such as debug and release and want to build them at the same time, then Cmake FAQ gives an answer : How can I build multiple modes without switching
Basically it involves using several out-of-source builds.
i am currently trying to implement a "third party framework" (FeedbackReporter.Framework) into my preferencepane.
Unfortunately I am getting the following error all the time when trying to launch my preference pane:
16.05.10 23:13:30 System Preferences[32645] dlopen_preflight
failed with
dlopen_preflight(/Users/me/Library/PreferencePanes/myPane.prefPane/Contents/MacOS/myPane):
Library not loaded:
#executable_path/../Frameworks/FeedbackReporter.framework/Versions/A/FeedbackReporter
Referenced from:
/Users/me/Library/PreferencePanes/myPane.prefPane/Contents/MacOS/myPane
Reason: image not found for
/Users/me/Library/PreferencePanes/myPane.prefPane
As far as I read so far, this problem is probably caused because my prefPane is no actual app, but a "plugin" of "System Settings.app" and thus #executable_path resolves to a path within the bundle of this app, instead of the bundle of my prefpane.
But I don't really picked up howto fix this problem. I guess it must be fairly easy since it should be a usual case that people use non-apple-frameworks in PreferencePanes.
Thanks for your hints!
--
Short Update:
As far as I understood tons of docs I read so far, there might be a setting which has to be done in the third-party framework. Obviously the "install path" has to be set to "loader_path" instead to "executable_path" in order to work in a preferencepane.
But since I am using a precompiled framework (FeedbackReporter.framework) this is probably a setting which the author has to change?! and even if i could compile the framework myself, i had no idea where to change this install_path in Xcode.
If you cannot wait for the next release just download the source, change it in
FeedbackReporter.xcodeproj/project.pbxproj
and then open and compile the framework yourself.
Actually, you can change it yourself without recompiling the third party framework. You can use install_name_tool to change where a MachO binary will look for shared object libraries. First use otool -L <binary file for your plugin> to get the paths of where it expects its libraries to be, then use install_name_tool -change ... to change the paths in that file. Repeat for any bundled frameworks.