I'm using Qt Creator under Mac osx, but "Follow symbol under cursor" option, to allow me to jump for class and methods' definitions, does not really work... it only works for local symbols. neither does "Switch between method declaration/definition"
Any ideas?
Thanks much for any thought.
Lior
First off, which version of Qt Creator are you using?
There is a Qt Creator 1.3 release candidate final release (1.3) out now that you might want to try: http://qt.nokia.com/developer/qt-creator-1.3-preview Qt Website Download Section :)
Hope that helps!
As #badcat said, ensure that you have the most recent version.
Other than that, when you have problems following a "symbol under cursor" it could mean 1 of 2 things.
1) I would check that you have your project appropriately constructed so that it has all the include and source files that it needs.
2) This is more rare, but check that you have function definitions in header files and that they are included properly by your source files. As opposed to what you may ask? We have a project here where, instead of include files, functions are defined in .cc files, and extern statements are used so that other files have access to them. (It's legacy code) In such a case, Qt Creator doesn't know how to find anything because files are only aware of each other while linking and have no other way to see each other.
Related
SO!
Let's say I have a number of settings (GCC compiler 9.3.0 built from source, as the distribution I have to use has a very old one, along with environment setup) for a new Kit in QtCreator.
I have managed to setup an environment for compilation and execution of compiled binaries, and made a script to make it work (like qmake -nocache -recursive/make/sudo make install, direct execution of g++, and other stuff).
One thing that script can't do at the moment, is that it cannot create a kit for QtCreator with new compilers and environment being set as required, so after running a script, its user has to go through setting it up himself through GUI, which is bad, because this can cause misconfiguration.
This thing I'm trying to create is going to be used by around ~200 people in my company, so leaving readme.txt with instructions just doesn't go well enough for me - I don't want running around fixing missing "{" and "}" in Environment description in created Kits, and other stuff.
Are there ways to create Kits for QtCreator automatically from command line? Maybe, there's some files to edit?
I've looked into this one a few years back (I wanted to do something similar for registering Buildroot toolchains automatically in QtCreator), and I was unable to find an off the shelf solution. So i think there are 2 ways to implement this:
a) Implementing a command line utility the manipulate the ~/.config/QtProject/qtcreator/{toolchains,profiles}.xml files. Maybe by (re)using the existing C++ implementation within QtCreator, or just re-implement it ie. in Python. Back than I didn't start to work on this as there was no real business need.
b) Switching to qbs, as qbs has support for setting up toolchains from the command line ( see: https://doc.qt.io/qbs/cli-setup-toolchains.html)
If you decide to go with solution a), please let me know and maybe we can partner up to implement it.
Check out the command line sdktool bundled with QtCreator:
The SDK tool can be used to set up Qt versions, tool chains, devices
and kits in Qt Creator.
There still is a lot of knowledge about Qt Creator internals required
to use this tool!
I haven't tried it yet, but I did find the executable under Tools/QtCreator/libexec/qtcreator subdirectory of the Qt Creator installation directory. ./sdktool --help works for me under Linux.
I'm a windows developer and I need to use Code::Blocks
to develope multiplataform C++ GUI applications.
After installing Code::Blocks and wxWidgets in my first try to do a simple "Hello World" application, the IDE show me a box with $(#wx)
What is the $(#wx) ?
Googling for tutorials I see this
What is the -g ?
Finally the following error message appear:
For 3 days I'm trying over and over again without success !
I even try wxPack. Nothing works !
With VC++, C++Builder and even wxDev-C++ this is straightforward
Only Code::Blocks is so difficult !
Googling, I find many people with the same error, but the advices they get didn't work for me !
Can someone tell me step by step what I must do?
Thank you.
Your frustration comes, as usually does, from your ignorance. If your are required to learn about C::B, well, that's life. Don't waste time on getting so angry, life is short.
CodeBlocks are not tied to a compiler. You can use VC++, MinGW, TDM-GCC, GCC, etc. Thus, you must tell C::B the compiler to use. You may use different compilers for different "targets" (see below).
C::B is not tied to any library either. If you want to use wxWidgets you must tell C::B about the needed files and where to find them.
It's very common that people who use C::B use MinGW as the compiler. That's why when you first install C::B it searches for MinGW and, if found, set it as the default compiler. You can set your own preference in Settings->Compiler. Same goes for the debugger, usually GDB.
As a side note, be aware that MinGW is ONLY 32 bits. There's a different compiler (MinGW 64). TDM-GCC offers both compilers (and their GDB versions) at once, I recommend installing 32/64 versions in different folders and setting them in C::B as different compilers. For Linux, the "mother" GCC is the de-facto standard.
When you build your app you must define a target. This is nothing else but a way of telling things like "I want a 32 bit library" or "I want a 64 executable". In your required project you may set several targets. Select the desired one before compiling (combobox in the main tool bar).
While developing it's very advisable to set a target as a "debug". This means you want to use the debugger. This requires to use "debug symbols". With GCC (or one of its "children", MinGW...) you acomplish it but adding -g as a flag to the compiler.
Now you understand that probably you set not only one, but several targets like "release 64 exe", "debug 32 exe" etc. Right?
wxWidgets joins in scene
Despite C::B is made with wxWidgets, it doesn't ship with it. Download the version you like from wxWidgets site. While some binaries are offered, if you use some other compiler or some other parameters then you need to compile wxWidgets on your own. See the docs/msw/install.txt and learn about the different configurations (release, debug, static/dynamic lib, etc). Your "target" must match the wxWidgets configuration, so better build several versions, same as your targets. And don't forget to use the same parameters for your app target as you used to each wxWidgets target. You can do this at Project->Build options.
As with any compiler you must tell where to find the libraries and the headers. And the libraries you want to use. The Windows libraries (kernel32, user32, etc, they are a lot, ask in another thread) and the wxWidgets libraries.
When you update your app perhaps you use a newer wxWidgets version, but also want to support an older version with other wxWidgets version. You have several folders. For your project you should update all directories. Can this be done shortly? Yes. in C::B you can define variables(e.g. $wx31dir) and use them like $(wx31dir)/include. Redefining the var saves you a lot of typing.
You can use a global var $(#wx31dir) or several, project fitted vars. Your decision.
Finally, C::B offers a project template for a wxWidgets app. It will ask you some locations (wx dirs) and vars. If you don't understand well what it does, better don't use it and set everything on your own. First time is hard, I know. Go ahead and you'll get it if you pay attention to needed steps.
Have you read the CodeBlocks manual?
Since you having hard time using C::B, I suggest you switch to CodeLite which I find simpler to start with than C::B (My experience). Everything you need is documented on CodeLite Wiki. Creating project is well documented with screenshots but before you compile, open environment variables (Settings->Environment Variables) and add line WXWIN=/path/to/your/wxwidgets/installation and compile as it is explained there.
Ouch....
You do not need to interact with code::blocks at all to use wxwidgets.
You can simple download wx header and binary package (depends of your compiler), place it on directory and import (with #include) it in your source code.
I do not see what is relevant to C::B? You can use any library without compiling and setting any variable in your editor (IDE) - but then you lack of lot of feuters.
I hope that
Using wxWidgets Pre Built Binary in CodeBlocks at wxWidgets wiki
and
Using wxWidgets (MSW) 3.0 Binary with Code::Blocks Scripted Wizard
would be best and useful answer for your question.
Even I want to use wheel for my convenience every day, but I don't want to invent the wheel every day again and again.
Even that your question is about wxWidgets and Code::Blocks for MS Windows, and that the answer links are of the wxWidgets and Code::Blocks own,
For recommended stability, I include the full screenshot of this document of wxWidgets own wiki
and
this of Code::Blocks own wiki
newbie here.
Want to ask for any advice on how to Publish/Export, CodeBlocks Application made by using wxWidgets. After some research, i discovered that i should use DLL, or something like that, but since I am really new into it, I am missing the logic on how I should actually implement that. Since CodeBlocks offers wxWidgets and DLL as separate projects. So I am not really sure how to properly combine. Thanks in advance.
If you used wxWidgets as .dll, to get a self-standing package you have to distribute all the requested libraries. The simplest way is just to copy them from their source folder (in your case [wxWidgets root]\lib\gcc_dll) in the same folder as your executable. There could be many of them, but usually only two or three are needed. For simplicity you can copy them all, or you can try repeatedly to start the program, and add each time the library indicated in the error message.
Please note that to distribute your application you will probably want to compile it in Release mode, and consequently you should ship the Release .dlls (i.e. beginning with wx...28_ instead of wx...28d_).
I'm having trouble linking an Xcode project using the AAF SDK, with Xcode 5.1.1 on MacOS 10.9.5. When I link the main dynamic library, these symbols come up missing:
_StgCreateDocfile
_StgCreateDocfileOnILockBytes
_StgOpenStorage
_StgOpenStorageOnILockBytes
AssertProc
I can't find a definition for them anywhere in the entire source tree for the SDK. The first four appear to be part of Structured Storage on Windows. A Structured Storage library is provided in the SDK and I'm already linking that.
Can anyone tell me of a Mac system library that defines these? Or is there a linker argument that pulls in a library for them? Thanks for any help.
A late answer (!), but in case anyone comes across this... The solution is either:
To use the makefiles with the AAF SDK to generate the AAF dylib,
which works fine. or...
If you use Xcode to build the AAF SDK, ensure the correct
#defines are kept, namely:
_DEBUG OM_DEBUG OM_STACK_TRACE_ON_ASSERT OM_USE_SCHEMASOFT_SS OM_STRUCTURED_STORAGE
Note that DEBUG=1 is absent (it is added by default by Xcode) - if defined, this brings in AssertProc. Define NDEBUG on release builds and omit the debug defines.
The Stg... functions are part of the MS implementation of Structured storage as you stated, but should not be referenced on a Mac, the Schemasoft implementation being used.
I'd like to build a keyboard layout that runs on Win7 and later without using MSKLC.
I downloaded the Keyboard Layout Samples, and although it says it requires VS2013 Preview and WDK8.1 Preview, it builds using VS2012 and WDK8 after changing the "Platform Toolset" property from "WindowsApplicationForDrivers8.1" to "WindowsApplicationForDrivers8.0".
But: Checking the kbdus.dll built with Dependency Viewer reveals that it imports quite a lot of stuff from kernel32.dlland from msvcr110.dll. This is in contrast to kbdus.dll from the Windows\system32 directory, which, as one might expect, does not import anything and exports one single function.
My first question: Is it an issues that the dll built imports from msvcr110.dll?
I guess it is, as Win7 does not include this dll. (Honestly, I'm wondering how this can be, because these are official Microsoft samples.)
Tweaking around with compiler and linker settings, I managed to get rid of imports from msvcr110.dll, but the dll built still imports a lot of stuff and is quite large (> 70kB), compared to the original kbdus.dll (7kB). It's the same with x86 and x64, Debug and Release builds. I'm looking for the /compileandlinkanddonothingfancy switch.
My second question: How can these dlls be built correctly?
(Note: I found this question, but it is about WDK7. That will be what I try next, if I don't get it with WDK8.0)
I think one should pass /noentry to the linker.