I just want to use qmake as pro-files parser for extracting project variables (like SOURCES), nothing more. I don't need to generate makefiles.
In other similar tools "dry run" mode usually presents. I.e. "just taste this thing, but do nothing with it".
Unfortunately qmake don't have such mode, but can i emulate it with some, probably ugly||hacky way?
Now i'm trying to remove all "generation"-code from qmake source, but it is hard and long task. And i'm like simple decisions :)
The simplest way is to give the -E option to qmake. It will dump the contents of the project variables and continue without generating the makefile.
It is equivalent to the code snippet given in previous edition of this post, but dumps all of the variables and requires no changes to qmake :)
Related
Long story short, we have a Qt project that I'm thinking of migrating to CMake. However, some of our customers use the existing library as a subproject in a Qt subdirs project. Does that mean we are stuck with Qt for the build system?
This is possible, but ugly. You could for instance use the system() function in a qmake file:
system(command[, mode])
You can use this variant of the system function to obtain stdout from the command and assign it to a variable.
For example:
UNAME = $$system(uname -s)
contains( UNAME, [lL]inux ):message( This looks like Linux ($$UNAME) to me )
As discussed in the comment, your fallback option would be to maintain both for your project, and give your customer a reasonable amount of notice period for qmake so that they have enough time for the migration if they are willing to.
Otherwise, running the desired cmake and build commands with the system() function looks, at least one, way to go.
We would like to use scons for building on Windows, mainly because of its caching facilities (we use ccache on Linux, and compiliation is considerably faster there). However, all our projects are defined in qmake .pro files. The way building now works, is that we call qmake to generate a Makefile, which we then use to build with jom. Having .pro files on a high level is quite practical, so we would like to keep that and not replace the .pro files by SConfigure files. So ideally we would have qmake generate a SConfigure file, the same way it generates a Makefile now, and then run scons on that SConfigure file. Is there something out there that can do that, maybe some generator for qmake? Or is it somehow possible to convert the Makefile created by qmake into an SConfigure file?
(I'm aware that the functionality of scons and qmake overlap, for instance the dependency generation and that it would likely be better to use just scons by itself, however, qmake works quite well for Qt projects and can also generate visual studio files, so we would like to keep it.)
They are not very happy with meta meta makes. However, as suggested in that rejected merge request, something might be possible off-source using QMAKE_SUBSTITUTES, but that is a practically undocumented feature.
Or you could go the way I tried and tinker with the code directly. Have a look at https://qt.gitorious.org/~phresnel/qt/add-some-qmake-to-autotools-glue , or more specifically the diff at https://qt.gitorious.org/qt/qt/merge_requests/1040 . The file qmake/generators/special/filelist.cpp does most of the work.
Imho, it is really a pity that extension of qmake is not easier; the greater flexibility of CMake was also the reason why I switched to it, completely abandoning my use of qmake.
I have a large software project which uses aspects of OpenGL for visualisation. I want to add a GUI and was thinking of using QT. Now from what I understand, building QT stuff can get ugly unless one sticks to using the qmake command...
However, my project relies on the GNU tools for building (g++, autoconf, automake, etc., etc.). Must I therefore restructure my whole build process to use qmake just so that I can use a few small aspects of QT? I am very reluctant to do so given the size of the project.
As a thought, could I possibly (somehow) use qmake for the graphical components (i.e. qt-dependent stuff) only and continue to use my standard GNU build process (make, g++ etc.) for everything else?
Thanks,
Ben.
A quick Google search turned up AutoTroll and a howto.
Personally, I have used Qt without qmake before, but it was for a personal project, so I just used a (non-portable) Makefile. I set a variable (QT4DIR, since QTDIR was used by Qt3) to point to where I installed Qt, then added -L$(QT4DIR)/lib -lQtCore -lQtGui, etc. to LDFLAGS and -I$(QT4DIR)/include/QtCore, -I$(QT4DIR)/include/QtGui, etc. to CXXFLAGS. It looks like those links explain how to do something similar for autotools.
Edit:
To handle the MOC, I've added implicit rules like:
moc_%.cc: %.h
$(MOC) $< -o $#
And then make sure that all required moc_*.cc files are included in my SOURCES. It's a bit of a pain to specify QObject-derived classes twice, but everything will get built.
After much head-scratching, I decided to compile the original code into a library using my original build process (but slightly modified to compile a library rather than a binary) and then compile the gui separately using qmake. This would then also link the gui in with the original library code. Not 100% ideal but works fine. Probably the biggest hurdle was converting some glut code into a QGLWidget...
Why does every source package that uses a makefile come with a ./configure script, what does it do? As far as I can tell, it actually generates the makefile?
Is there anything that can't be done in the makefile?
configure is usually a result of the 'autoconf' system. It can generate headers, makefiles, really anything. 'Usually,' since some are hand-crafted.
The reason for these things is to allow source code to be compiled in disparate environments. There are many variations on Unix / Linux, with slightly different system headers and libraries. configure scripts allow code to auto-adapt.
The configure step is a sort of meta build. It generates the makefile that will work on the specific hardware / distribution you're running. For instance it determines the name of the C or C++ compiler and embeds that in the makefile.
The configure step will also frequently take a set of parameters, the values of which may determine what libraries need to be linked against. For instance if you compile Apache HTTP with SSL enabled it needs to link against more shared libraries than if you don't. Since linking is handled by the makefile, you need an extra step to create a custom makefile (rather than requiring the make command to require dozens or hundreds of options.
Everything can be done from within the makefile but some build systems were implemented otherwise.
I don't personally use configure files for my projects but I admit I mostly export Erlang & Python based projects.
I don't think of the makefile as a script, I think of it as an input to the make utility.
The configure script (as its name suggests) configures the makefile, including as you say resolving dependencies.
If only from the idea of avoiding self-modifying code, the things in the configure script don't really belong in the makefile.
the point is that autoconf autohdr automake form an integrated system the makes cross platform building on unix relatively str8forward. THe docs are really bad and there are lots of horrible gotchas but on the other hand there are a lot of working samples
When I first came across this stuff I thought - "ha I can do that with a nice clean makefile" and proceeded to rework the source that way. Big mistake. Learn to write and edit configure.ac and makefile.am files, you will be happy in the end
To answer your question. Configure is good for
is function foo available on this platform and if so which include and library do I need
letting the builder choose if they want feature wizzbang included in a nice simple consistent way
I'm mostly a spoiled Windows + Visual Studio (or Borland C++ or whatever, in the past) developer. Although my first contact with Unix was around 20 years ago, and I've used Linux on-and-off for some years, I have only a very limited idea of how to set up a build on a *nix system.
For example, I'm OK with the basics of make - I can get a number of files to compile and link. But I don't really know how to set things up to cope with multiple configurations - how to get all the object files and targets for the release version to go to different folders from the debug version etc etc. Yes, I can RTFM and improvise something, but it's a fair guess that I'd improvise something stupid, overcomplex, fragile and WTF, where it'd make so much more sense to copy a common convention if only I knew what the common conventions are.
Also, I can run a configure script, and I'm vaguely aware that they're associated with autoconf, whatever that is, but I have little idea if/why/how I should set this kind of stuff up in my own projects.
Hopefully, this is enough to give the general idea of what I'm looking for. Of course I could ask/search specific questions here, but that assumes I know all the right questions to ask which I almost certainly don't. So - any pointers?
EDIT
Just thought I'd update this with some longer-term experience.
I tried using premake for a while, but couldn't live with it in the long run. In substantial part there's a dislike of Lua behind that.
Now, I'm using cmake. It generates makefiles/visual studio projects/whatever. It has (so far) handled everything I've needed to do, including support for unit testing and custom build steps. And as I got used to the cmake way of doing things, I found it was a good way, allowing me to easily use multiple sets of tools at once - I can be checking test coverage in MinGW GCC while simultaneously debugging in Visual Studio.
That reveals, of course, that I'm still mostly working in Windows - but switching back and forth is easier than ever.
The downsides of cmake...
Although it generates makefiles/whatever, it can't really be seen as a makefile generator. The resulting makefiles are dependent on cmake being installed. To be honest, I don't really understand why they don't drop makefiles altogether for makefile platforms and just do the building directly, slightly reducing the potential for problems.
It wasn't easy to get started.
The second point has mostly been resolved by asking questions here...
How do I fix this cmake file? - problem linking to imported library
How to apply different compiler options for different compilers in cmake?
For the cmake "include" command, what is the difference between a file and a module?
How to adapt my unit tests to cmake and ctest?
I'd strongly suggest using one of the newer cousins of Make instead of autoconf or makefiles for smaller projects. One of the best ones for you (and the one I mostly love) could be premake4. Why do I suggest it? Because it's extremely simple to use, yet quite powerful, and capable of producing GNU Makefiles, Visual Studio projects, Code::Blocks projects and many more. And the premake files are very clear and readable, using the Visual Studio nomenclature that you're already familliar with.
Here's an example:
-- A solution contains projects, and defines the available configurations
solution "MyApplication"
configurations { "Debug", "Release" }
-- A project defines one build target
project "MyApplication"
kind "ConsoleApp"
language "C++"
files { "inc/**.h", "src/**.cpp", "main.cpp" }
configuration "Debug"
defines { "DEBUG" }
flags { "Symbols" }
configuration "Release"
defines { "NDEBUG" }
flags { "Optimize" }
I would stay away from autoconf until you actually need it as it is pretty complex to use, and in most small projects, make is all you need...
I don't have a tutorial, but I will give you an extremely amazing(and portable between both BSD and GNU make) makefile to start with for small projects. I dug it out of the original BSD 4.3 assembler(as)
HDRS = project.h
OBJS = main.o
LDFLAGS =
project: ${OBJS}
${CC} ${LDFLAGS} ${OBJS} -o project
.c.o: ${HDRS}
${CC} ${CFLAGS} -c $*.c
clean:
rm -f *.o ${OBJS} project *.core a.out errs core
just replace Project with your projects name and such..
edit:
technically, you need a BSD 3 clause license for Berkeley... as per:
* Copyright (c) 1982 Regents of the University of California.
* All rights reserved. The Berkeley software License Agreement
* specifies the terms and conditions for redistribution.