I have a Qt project file (.pro) and a Makefile (self-written).
The project file is simply used for editing the source files in the IDE:
/home/project/
./src/fooApp.pro
TEMPLATE=app
CONFIG-=qt
TARGET=fooApp
SOURCES+=...
HEADERS+=...
./src/main.c
./src/foo.c
./src/foo.h
./build/Makefile
I would like to build the project via IDE QT Creator 3.5.1
Therefore I would like to invoke make on the Makefile.
During the build process I always get the error that no Makefile can be found hence no build was triggered.
The solution is to always invoke qmake first, then make (even if a Makefile is still present and custom setting make -C ../build in /home/project/)
Could someone please explain, why it is not possible ignore qmake and directly invoke make on the already existing Makefile?
(No Qt library is used for the project)
Regards
This is quite easy, I use makefile only project alot because I like qt-creator as an IDE. In the IDE goto the projects tab on the left.
Select the "build" tab near the top of that page, looks like: (build | run).
In the build steps:
remove the qmake build step by press hovering the mouse over that step and clicking the X that appears.
Edit the build directory so that it is the same directory as your makefile.
Note: you will have to click the shadow build check box next to it to enable it.
remove any other steps you don't want (infact just remove them all for now).
Add a new step make step. It will try to use the default make, but you can override that if you want. Also add any arguments like debug or -j4 etc...
Then you are done :)
Next time you hit build it will simply invoke that make command.
Note: You will need to do the same for any other configurations you have (like release, debug, etc...). You can also just add loads more configurations for doing other make options (if you have them) for instance make doxygen or such...
Just remembered you can also either:
I am not sure why, but when I tested it (as OP did) you can't seem to just setup a make step with parameters -C ../, it seems to want to look in the "build directory" first.
I tend to use the build location since its a nice feature of the IDE.
Note an issue with newer versions of Qtcreator as a makefile IDE is that you cant share your build settings with other people (i.e. can't configure control them) because they are locked to your PC profile... long story... but its very sad and I no longer use qt creator for that one reason.
Related
I normally use Qt creator with cmake to program C++ projects. Lately I read quite a bit about meson and it's simplicity and I like to test it. This example explains how to setup meson.
When using meson, I like however to still use Qt creators shortcuts for building (ctrl + B) or running (ctrl + R). How can I configure Qt creator to build a meson project, when I'm using a "generic project"?
Meson is currently not directly supported by Qt Creator. There is a bug report requesting that: https://bugreports.qt.io/browse/QTCREATORBUG-18117 and I am considering to actually implement that.
For the time being I use meson via the "Generic Project". Go to "New File or Project", "Import Project" and there "Import Existing Project". That gets you a dialog where you can select the files that your project consists of.
After that is done you will need to edit "projectname.includes" and add the include directories (one per line) into that file. Then you need to edit "projectname.config" and add defines (one per line) there.
Finally you will need to edit the build configuration and call ninja instead of make there.
With that it works reasonably well for my small project.
Until the QtCreator supports directly meson.build project files, I find this python2 script useful to create QtCreator generic project files: https://github.com/mbitsnbites/meson2ide
with meson and ninja in your PATH, this should work:
$ meson builddir
$ python2 meson2ide.py builddir
this generates a .creator project file in builddir (if you get an error about "mesonintrospect" not found, try this PR: https://github.com/mbitsnbites/meson2ide/pull/1)
To make CTRL+B work properly, In QtCreator build settings, remove the make build step and add a custom build step with the path to the ninja executable, and add the command line arguments
3>&1 1>&2 2>&3
Those redirect allow QtCreator to capture build errors in the "issue" panel.
I'm using Bison and Flex in an Xcode project. I didn't want to put the generated files under source control, so I was happy to find that Xcode natively supports Bison/Flex files, generating the parsers on-the-fly in its derived data folder. So far so good.
However, Xcode uses an embedded old Bison version (2.3):
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/yacc
which doesn't yet support the %define api.pure full directive. Since this bison executable is under the Xcode.app bundle I can't replace it, so I installed the latest version via Brew and added it to my $PATH through ~/.bash_profile (~/.bashrc also sources my bash profile). So in bash I can say:
$ which bison
/usr/local/Cellar/bison/3.0.4/bin//bison
However, Xcode still uses it's own version... I suppose the path to the internal bison is hardcoded.
My second approach was to create a custom build rule for Yacc files, and run the correct version of bison from there. This time the problem was that as Xcode ran my custom build rule, it immediately tried to build the resulting C files. The generated C files would however depend on the header file yet to be generated by Flex, because that's where e.g. yyscan_t is declared (used by Bison in the generated C file). But on the other hand, Flex-generated C files also include the Bison-generated header, so compiling with Flex first doesn't help...
What I need is to first only generate the Flex and Bison headers/sources and then build them along with the rest of the project.
How can I achieve this?
I've managed to solve the issue by putting the *.l and *.y files under a *.parser folder and adding that folder to the project. Then I removed the *.l and *.y files added the folder to the compiled sources:
And then made a Build Rule for *.parser like this:
This enables me to first run yacc and lex and only then will the resulting *.cpp files be passed to the compilation step.
If you go to your build target, Build Phases, and click the + on the bar with the search box on it, you can add a New Run Script Phase. You can then drag that above your current Compile Sources phase. You can do whatever you want in that script phase, and it will run before compilation starts.
This is a bit of a Zombie, but if I ever come back here again, I will want to see the answer.
Certainly from XCode 12 (probably before) the answer is trivially easy.
(1) Go to build settings
(2a) Press the + for a brand new setting variable.
(2b) Change the NAME to YACC, and it's VALUE to /usr/local/bin/bison (or whatever path you need for brew).
(3a) Press the + for a brand new setting variable.
(3b) Change the NAME to LEX, and it's VALUE to /usr/local/bin/flex (or whatever path you need for brew).
(4+) use the YACC/LEX settings for flags that you want to use.
I've managed to do it with custom build rules, using bison installed from brew and flex that comes with macOS, not the one bundled with Xcode. I'm not sure if my problem was the same as yours, but if you want to take a look my project is on GitHub.
Is it possible to build a single file in CLion and see the actual compiler command line being used?
I have a large existing project, which CLion managed to load however it fails to build, I suspect because of various CmakLists.txt setting. However as far as I can tell you can only build an entire project and it gets built using -j 8 so you get a lot of output which does not include the command line being used so it's hard to know what to fix. i know CLion does create a temporary build directory in .clion10 but I was hoping not to have to go a fish around in that.
Also as a newbie to CLion I can't seem to work out how to undock Clion Windows ( on a Windows 7 box ). The "Floating" option doesn't seem to let me drag a Window outside of the main Clion window.
You have to use add_executable command multiple times.
Here an example :
cmake_minimum_required(VERSION 3.3)
project(test_build)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(BUILD_1 main)
set(SOURCE_FILES_1 main.cc)
add_executable(${BUILD_1} ${SOURCE_FILES_1})
set(BUILD_2 main_2)
set(SOURCE_FILES_2 main_2.cc)
add_executable(${BUILD_2} ${SOURCE_FILES_2})
Old anwser :
You can use add_subdirectory(path_to_directory) to use an other CMakeLists and have multiples building process. ie: you have your cmakelists at the root of your project and multiple other in some files of your project. You just use add_subdirectory and you get other build options.
For your other question, on ubuntu i have to split the view and after i can drag in another floating window.
Under you can see one of my projects and the main CMakeLists.txt on the right
And the build options on CLion with this structure.
The CMakeLists.txt under the files are like full project builders.
In some of my projects I use some pre-build step(s) configured in the .pro file. So qmake will execute this step whenever it is activated.
Now in QtCreator, when I build (also when completely rebuilding the whole project), it doesn't always run qmake, since it tries to be clever and optimize this. It only runs it when the .pro file has been changed, causing several issues.
Also a common issue is, when you make a class inheriting from QObject after running qmake on that file, it will not notice it and hence not run moc on it. Such issues are solved by simply manually running qmake via the "Build" menu in QtCreator. But if I forget this I am sometimes confused by the compile errors I get because of this and this is really annoying.
(How) can I force QtCreator to do this step always when building a project?
I thought about adding qmake as a build step in the project configuration, but this seems to be a dirty hack to solve this problem.
Another dirty hack but a little more flexible: On Linux/Mac add "touch yourprojectfile.pro" as a build step or assign an external tool call to sth. like touch "*.pro" run in your current projects working directory. When the pro file is altered (which is mimicked by touch) qmake is executed. Not much cleaner but the external tool plus hotkey solution is more flexible than adding qmake into the buildsteps of each an every project.
Update:
I finally found a completely satisfactory solution for this.
In the pro file add:
qmakeforce.target = dummy
qmakeforce.commands = rm -f Makefile ##to force rerun of qmake
qmakeforce.depends = FORCE
PRE_TARGETDEPS += $$qmakeforce.target
QMAKE_EXTRA_TARGETS += qmakeforce
This deletes the generated Makefile an thus forces qmake to rerun for every build.
I think your best option is customize your QtCreator .This can be done by write a plugin for QtCreator ,or you can change the souce code of a plugin named Qt4ProjectManager ,then build it for yourself . This might be complex ,however, can be a solution.
What I've done is created a makefile that explicitly calls qmake. Of course, that means I have two makefiles, but in my project file, I have
MAKEFILE = makefile_qt
which means that the generated makefile will have that name.
So, for the makefile I manually created, I have:
default:
qmake;
${MAKE} -f makefile_qt;
Then, from QtCreator, I just call the regular make, which will default to makefile. Or you can leave the Qt-generated makefile as is, and just call make -f makefile to call your manually created one. I forget which has precedence, makefile or Makefile, and I'm not sure if it is always the same.
I'm using the following codes in my .pro file.
QMAKE_CLEAN += ./Makefile
This makes run qmake whenever executing clean.
I just installed QT 4.6 on snow leopard 10.6.3. I wrote a really simple program. I can generate a xcode project using qmake, but I can't step into QT function. How can I set it up?
By default, qt is built with a debug and a non-debug library. This is my understanding. For example,
% ls /Library/Frameworks/QtCore.framework/
Contents/ Headers# QtCore# QtCore.prl QtCore_debug# QtCore_debug.dSYM/ QtCore_debug.prl Versions/
Also, my default from source build of Qt 4.7 branch also has the *_debug libs.
Setting up for Xcode is cake, you just set up your project and
% qmake -spec macx-xcode
This -spec is the default for the official mac distribution, but if you build your own from source the default is macx-g++ which creates a Makefile project.
This generates a MyProject.xcodeproj that comes preconfigured to link all the necessary Qt frameworks, sets up paths, and has a Release and Debug build target set to the same options as the official SDK's.
This is all assuming you have your qt project file set up, if you need to generate that first from a raw source directory:
% qmake -project
Debugging works "out of the box" for these generated *.xcodeproj files. However, there's one little "hitch". Since Qt is full of custom data types, Xcode doesn't know how to display their "values" in the debugger's summary pane. So you can't see what value a QString has, for example.
There's a method of entering custom macros for display, but I've found these often (always?) don't work for QObjects.
To get that working, I've started a project that uses xcode's debugger c callbacks (also mentioned in the above linked article, though their example doesn't even work o.O). I call it Qt4DataFormatters.
I've just started it and have been adding types as the need arises. It's dirt simple to create one using the existing functions as a template though.
I haven't tried this on Mac, but on Linux you need to take the following process:
First, you need to setup Qt so that it has debugging symbols available to you:
./configure -debug-and-release separate-debug-info # other options
With the debugging symbols available, you should now be able to get valid stack traces.
When building your application with qmake, you need to have the debug (or debug_and_release) flag set in your project file:
CONFIG += debug
Once you've done that, you should only need to tell the debugger where the Qt source is located:
(gdb) dir /path/to/qt/src
After that, list should show you the actual Qt source code. You may need to add additional directories under the src directory for the debugger to pick it all up.