I wondering if there is such a thing like optional targets or sub project in qmake, the Qt build tool.
Project
In my test example I have a subdirs project which contains another two projects, one shared library and one basic application. The application depends on the library which works great. Additionally I have one additional compiler (invoking lrelease) and one additional target (invoking lupdate), which also works like a charm (the shared library provides them as pri file for multiple projects).
After a complete build in release mode, the Windows deployment tool (namely windeployqt.exe) is called and deploys the target with all required shared libraries and plugins to my deployment directory.
Last component I wish to add is the creation of an installer using the Qt Installer Framework, which in fact should be easily done one the executables are located. Thus I want to create another sub project which contains all the installer stuff and provides the qmake steps to create one. But the project should not be build all the time but only when I want to, preferably over the create menu of Qt Creator.
Question
Is there any way to make a qmake subdirs sub project fully optional, so it will not be built using the default build all?
You can add a check around it:
enableOptional {
message(optional enabled)
SUBDIRS += YourSubDir
}
And call qmake with
qmake CONFIG+=enableOptional yourProject.pro
The qmake documentation states that one should use the test function requires(condition) to skip building a whole project. Using this one may add a new build configuration, namely bundle as example, which defines a configuration variable as #Jeffrey pointed out in his answer.
I managed to get it working with the following qmake project definition:
requires(BUNDLE_INSTALLER)
TEMPLATE = aux
QMAKE_POST_LINK = ...
Once you define the variable, over a new build configuration for proper working with Qt Creator (example), the steps listed under QMAKE_POST_LINK are performed. So I may bundle the installer, if I want to.
Related
I want to use qt creator for modifying a project that just uses makefiles. How i can do it? Right now i can just open project files one by one and there is no auto code completion or other advantages of ide. My main concern is use the ide over ssh actually.
I tried open all folder but it didnt work too.
You can use Qt Creator for non-Qt projects, but it will always assume you want to use qmake, CMake, or QBS as your build system. It's not going to read your plain Makefiles and recognize what source files you are using.
In the New Project wizard, you can select non-Qt application. I recommend selecting qmake as your build system, which will create a .pro file, even if you won't end up using it. Then after it creates the project, go into your Project settings under Build Steps. You can delete the built-in steps and add your own custom build steps to do whatever you want. Call make or whatever. Do the same for the Clean Steps.
I am trying to create Team City build template which requires minimum customisation, and I want it to play nicely with legacy projects and projects developed with .NET Core/Standard and .NET CLI.
I am stuck with NuGet as there were some considerable changes in how things work.
Earlier we had to create nuspec file to pack project as a NuGet package. At least in that file we could define various package-related properties.
New csproj file format allows us to define all package properties inside itself. That's fine, but how then do we know which projects should be packaged and which should not?
So far our TeamCity's build step Pack NuGet just contained **.nuspec for Specification files: field. The very fact of nuspec file presence served like a flag pack & publish this project.
However, for dotnet pack we need to specify the project. There is no simple way to distinguish 'main' projects from 'auxiliary' ones on which mains depend. (Let us ignore that project-to-project references are currently not supported.)
We either could pack all projects specifying **.*proj (yet in that case we are to know which packages to publish) or we might specify projects explicitly in a build configuration, but I don't like this approach because you must edit build configuration each time new project is added to the solution.
I also considered the option Generate package on build and omit dot net pack step as package is created on build. The only thing left is publishing the packages with dotnet nuget push specifying **/%BuildConfiguration%/*.nupkg.
Unfortunately when starting build against solution without projects with enabled Generate package on build makes TC fail complaining that
Target files not found for pattern "**/Release/*.nupkg"
Hence, I either need another recipe for achieving the required result or an advice how to make TC consider empty result just as a NOP and mark build as successful.
Yet another option is to use nuspec even for new csproj...
Since TeamCity 2017.2 will be available option to associate build configuration with multiple templates. So you will be able to create different templates to create packages for old projects and new .NET CLI projects.
To specify paths for target .NET projects, which should be packaged, you could use build configuration parameters.
To set such parameters during the build you could send in the preceding build step service message. The value of this parameter could be set to the list of target project files which could be selected via script like that: https://stackoverflow.com/a/8153857/305875
In Qt Creator, in Tools -> Options -> Build & Run -> General -> Build and Run -> Default build directory I have this value:
../build-%{CurrentProject:Name}-%{CurrentKit:FileSystemName}-%{CurrentBuild:Name}
This works but on project creation the variables in that string get replaced with their values, which means that if I later rename the project, I need to go through all of [Debug, Profile, Release] modes and manually change the builddir's path so it reflects the new project name.
So I want:
A way to use variables like %{CurrentProject:Name} in the project settings
(less important) A way to have Qt Creator automatically put references to such variables in the project settings on project creation, so I don't have to adjust them on project creation
Alternatively: Some other pain-free way to rename my project without having to update so many places
Note: I could remove the project-name part from the builddir template, and put the builddir in "." (project dir) rather than in ".." (parent of project dir), that way it would work and there would be no name collisions (MS Visual Studio does it this way), but unfortunately qmake has a limitation (see tobias.hunger's post) that makes it sometimes break unless the project dir is at "the same level" as the builddir.
You'll need to implement this feature yourself. This happens so rarely that until now nobody really needed it. A workaround, if your build/run environment isn't customized, is to remove all kits from the project and re-add the desired kits. It will then create build folders using appropriate names.
But it seems like much ado about nothing: Qt Creator's build folder names might as well be random strings, you should not need to manually refer to them. For product deployment, you'd be using some sort of a CI system, or a manually invoked build script that stages the deliverable(s) (e.g. installer or disk image) where they belong.
I have a simple question - what is Shadow Building? I've seen it in Qt in Target Setup dialog, but don't know what it does or if I should use it.
It's also present in Projects tab, under General group.
Shadow building is a technique used to build different Qt builds of the same version for different platforms/compilers/etc. Your compiled build is in a different directory, separate from the original Qt source directory.
I've created a shadow build for my MSVS2010 compiler. If I wanted to, I could create a new build for MinGW in a different build directory.
See the definition here, and more information about configuring your build here.
Additional information for Mateen's answer.
By default, Qt Creator builds projects in a separate directory from the source directory, as shadow builds. This keeps the files generated for each build and run kit separate. If you only build and run with a single kit, you can deselect the Shadow build checkbox.
https://doc.qt.io/qtcreator/creator-build-settings.html#qmake-build-configuration
I've got an application project that depends on a couple of shared libraries that I have created myself. According to the Qt 4.6 documentation "Deploying an Application on Mac OSX":
Note: If you want a 3rd party library
to be included in your application
bundle, then you must add an excplicit
lib entry for that library to your
application's .pro file. Otherwise,
the macdeployqt tool will not copy the
3rd party .dylib into the bundle.
I have added lib entries to my application's .pro file but the libraries that I have written do not get copied into the bundle when I execute macdeployqt. I have the following in my .pro file:
LIBS += -L../Libraries -lMyLib
Everything builds okay, its just when I try to run from the bundle that I run into problems i.e. "image not found" errors.
Is there a bug in macdeployqt or do I have to something more to my .pro file?
badcat is correct that the Qt 4.6 documentation has a grossly inflated view of what is possible with macdeployqt tool.
In my experience, the only things that are done by macdeployqt are:
Copy the Qt libraries into your app bundle in the foo.app/Contents/Frameworks/ directory
Adjusts the link libraries of one binary, namely foo.app/Contents/MacOS/foo (must have same name as app bundle, even if you mention another binary in Info.plist)
So, for every other binary and library you want to deploy in your app bundle, you must do the following:
Run macdeployqt to enjoy its useful but feebly inadequate benefits
macdeployqt <path_to_your_nascent_app_bundle>/foo.app
Install your extra libraries manually
cp <original_library_path> foo.app/Contents/Frameworks/<lib_name>
Find out what libraries each binary links to.
otool -L <binary_file_name>
Change the internal libary paths in your binaries
install_name_tool -change <original_library_path> #executable_path/../Frameworks/<lib_name> <binary_file_name>
I wrote a perl script that automates these steps for my application, but it's a bit too specific to my particular environment to post here.
You don't need to take care about manual deployment of third-party libraries. I am uploading a patch to Qt that makes it possible to specify additional library search paths, so that the macdeployqt tool finds the third-party dependencies:
https://codereview.qt-project.org/#change,47906
After this one there will be another commit that will add support for third party libraries' deployment.
Did you check the .app bundle to see if the libraries are really not there?
If that's the case, I'd assume there really is a bug in macdeployqt, or it simply can't find the library you are linking. Personally I've never seen macdeployqt actually copy any needed 3rd-party libraries into the bundle.
The interesting part is that macdeployqt never ever works directly with the .pro file. It just does some stuff to the produced application bundle. And after a quick glance into the documentation this Qt 4.7 documentation page obviously proves me right:
Note: If you want a 3rd party library to be included in your application bundle, then you must copy the library into the bundle manually, after the bundle is created.
I'd assume there is a bug in the 4.6 documentation. For me macdeployqt never placed any library files in my bundle (except for the Qt* ones, of course).
I did spend a lot of time with this stuff in my past, and ended up writing a simple little (Python) script that packs everything up into my bundle, changes the library names as needed and puts everything in a .dmg file with automatic naming.
Possibly not what you wanted to hear, but it works. ;)
https://github.com/auriamg/macdylibbundler
dylibbundler is a small command-line programs that aims to make bundling .dylibs as easy as possible. It automatically determines which dylibs are needed by your program, copies these libraries inside the app bundle, and fixes both them and the executable to be ready for distribution... all this with a single command on the teminal! It will also work if your program uses plug-ins that have dependencies too.