is there a platform independent way in QMAKE to copy files? Currently I use xcopy under windows, which is able to handle german umlauts.
# Simple "Release" target related copy of compiled .exe file into .compiledOutput folder
# xcopy is windows dependant, but necessary to handle german umlauts
win32 {
build_pass: CONFIG(release, debug|release) {
QMAKE_POST_LINK += xcopy /Y $$quote($$system_path($$absolute_path($$OUT_PWD/release/$${TARGET}.exe))) \
$$quote($$system_path($$absolute_path($$OUT_PWD/../$${TARGET}/.compiledOutput/)))
}
else: build_pass {
# Do nothing, only copy release build to .compiledOutput
}
}
I know there is $$QMAKE_COPY which unfortunately resolves to copy for my Qt5.8 setup and copy has problems with german umlauts.
Not sure, but you can try:
Replace common Windows cp.exe with xcopy.exe .
Make soft- or hardlink of cp.exe to xcopy.exe. And include folder with it before folder with cp.exe in PATH environment variable. Qmake must use your version of cp.exe instead of system.
On other systems(rather than Windows) you can emulate xcopy.exe as a symlink or an executable script.
Related
Let's talk about it in linux terms. I have a ".so" file. I want to make the executable dependent on it, look for it in the same directory. How do you do it through qmake? Or can this only be achieved through the use of QLibrary?
For example, when you have a ".so" file and want to use it in your project, in qmake you write:
LIBS += -L"path to the folder that contains your .so" -lSoName
But the path is hardcoded, as you can see, and I'm wondering what to write there to make the executable look for the ".so" in the same directory.
You use RPATH
You can configure your binary or library to find shared library (or dll) in current directory using RPATH directive that is emedded in the binary itself which the loader respects at runtime
1- Add the following in your .pro file
unix {
message("Adding RPATH to the app")
QMAKE_LFLAGS += -Wl,-rpath=\'\$$ORIGIN/\'
QMAKE_RPATH =
}
This will set RPATH of executable to current directory and your executable will first try to look for that .so in your current directory and then in standard directory (this process is explained here)
2- After you compile and create binary VERIFY that RPATH is set correctly
objdump -x <path/to/binary> |grep RPATH
it should say $ORIGIN
Compile time configuration:
CXXFLAGS += -L"/path/to/libmarylin.so/file" -lmarylin
There are a few ways to do it.
If the executable is going in the current directory, just do LIBS += -L$$(PWD) -lSoName.
If you're putting the executable into some other sub-directory, specified by some qmake variable like DESTDIR, use LIBS += -L$$(DESTDIR) (or whatever variable holds that directory).
Alternatively, you can add the directory with the executable to the runtime path of the executable, which gives the dynamic linker a list of directories to search for any unresolved libraries at runtime. This can be done with QMAKE_RPATHDIR += -L$$(PWD) and LIBS += -lSoName, which will tell the linker to look for unresolved libraries in the current directory where qmake is run.
Some operating systems may also include the current directory in the runtime search path for libraries by default, in which case just doing LIBS += -lSoName should be sufficient. That is platform-dependent, though, while the above solutions are not.
I'm building a project in Qt Creator, and while I don't care where the intermediate .obj files go it's important that the final executable be put in (and run from) a particular directory where the many dependency DLLs etc. are to be found.
So, in Qt Creator, I select the 'Shadow Build' option and specify the path to this directory.
What I always find, however, is that instead of being put into this directory, the final executable is always placed into
the_Directory_I_Actually_Want/debug
... which is no use to me because, when I then try to run or debug the program from within Qt Creator, it won't start because the DLLs that it depends on are all in the_Directory_I_Actually_Want and not in the /debug subdirectory.
I've tried setting DESTDIR within my .pro file to the the_Directory_I_Actually_Want, and I've tried setting TARGET within my .pro file to the_Directory_I_Actually_Want/projectName, and I've tried faddling around with the various options that are part of the 'kit' configuration, and nothing seems to let me have any control over this.
Is there a way of doing this, or am I going to have to change the rest of my build system around just for Qt Creator's benefit?
Three years later...
Just use:
CONFIG -= \
copy_dir_files \
debug_and_release \
debug_and_release_target
On Windows you can use DLLDESTDIR variable which specifies where to copy the target dll or exe. Just add this to your .pro :
CONFIG(release, debug|release): DLLDESTDIR += $$PWD/../exec
On Linux you can use QMAKE_POST_LINK variable which contains the command to execute after linking the TARGET together. So it is like:
CONFIG(release, debug|release): QMAKE_POST_LINK += $$quote(cp project $$PWD/../exec)
Here project is the name of the target file which you provide by TARGET = project
These will copy the executable binary to a directory named exec one level upper than the program working directory. You can have your arbitrary path.
I want to integrate SQLite into my project using ExternalProject_Add.
cmake_minimum_required(VERSION 2.8.8)
include(ExternalProject)
# Download, configure, build and install SQLite
ExternalProject_Add(SQLite
PREFIX ${CMAKE_SOURCE_DIR}
TMP_DIR ${CMAKE_SOURCE_DIR}/temp
STAMP_DIR ${CMAKE_SOURCE_DIR}/stamp
#--Download step--------------
DOWNLOAD_DIR ${CMAKE_SOURCE_DIR}/download
URL http://www.sqlite.org/2014/sqlite-autoconf-3080704.tar.gz
URL_HASH SHA1=70ca0b8884a6b145b7f777724670566e2b4f3cde
#--Update/Patch step----------
UPDATE_COMMAND ""
#--Configure step-------------
SOURCE_DIR ${CMAKE_SOURCE_DIR}/source
CONFIGURE_COMMAND "" # How to add sqlite3.c to the target here?
#--Build step-----------------
BINARY_DIR ${CMAKE_SOURCE_DIR}/build
BUILD_COMMAND "cmake --build ."
#--Install step---------------
INSTALL_DIR ${CMAKE_SOURCE_DIR}/install
)
The build command would use the native compiler to build all source files added to the target SQLite. However, there are non. How can I add the only source file sqlite3.c to the external project within the CONFIGURE_COMMAND?
ExternalProject_Add assumes that the project you want to pull in already ships with a (possibly complex, possibly non-CMake-based) working build system.
You have two possibilities here:
You can stick with the amalgamated autoconf version of sqlite that you are currently using. In that case the CONFIGURE_COMMAND would invoke configure and the BUILD_COMMAND would invoke make. Note that this approach will not be portable to platforms that do not have autoconf installed.
You can switch to the bare-source amalgamated version of sqlite and provide your own CMakeLists.txt for building. Since sqlite can be built with a minimum of configuration and the amalgamation only consists of a single source and header file, this is not as hard as it may sound. In this case you can simply invoke cmake for configuation and building.
Note however that you cannot provide this information in-line with ExternalProject_Add. You will need an external build script, whether that is CMake, autoconf or something else.
Building on the correct answer above, this is what I came up with. Instead of adding a second file to my repository, it gets generated from the existing CMake file. Since the source directory of the external project gets cleaned on build, the generated file must be stored in a temporary location and copied into the source directory in a later step of the external project, in this case the update command.
# SQLite
cmake_minimum_required(VERSION 2.8.8)
include(ExternalProject)
# Add CMake project file
file(MAKE_DIRECTORY ${CMAKE_SOURCE_DIR}/temp)
file(WRITE ${CMAKE_SOURCE_DIR}/temp/CMakeLists.txt
"cmake_minimum_required(VERSION 2.8.8)\n"
"set(PROJECT_NAME sqlite)\n"
"include_directories(${CMAKE_SOURCE_DIR}/source)\n"
"add_library(sqlite3 ${CMAKE_SOURCE_DIR}/source/sqlite3.c)\n"
"install(TARGETS sqlite3 DESTINATION lib)\n"
"install(FILES sqlite3.h DESTINATION include)\n")
# Download, configure, build and install.
ExternalProject_Add(SQLite
# DEPENDS
PREFIX ${CMAKE_SOURCE_DIR}
TMP_DIR ${CMAKE_SOURCE_DIR}/temp
STAMP_DIR ${CMAKE_SOURCE_DIR}/stamp
#--Download step--------------
DOWNLOAD_DIR ${SFML_PREFIX}/download
URL http://www.sqlite.org/2014/sqlite-autoconf-3080704.tar.gz
URL_HASH SHA1=70ca0b8884a6b145b7f777724670566e2b4f3cde
#--Update/Patch step----------
UPDATE_COMMAND ${CMAKE_COMMAND} -E copy
${CMAKE_SOURCE_DIR}/temp/CMakeLists.txt
${CMAKE_SOURCE_DIR}/source/CMakeLists.txt
#--Configure step-------------
SOURCE_DIR ${CMAKE_SOURCE_DIR}/source
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_SOURCE_DIR}/install
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DBUILD_SHARED_LIBS=${BUILD_SHARED_LIBS}
#--Build step-----------------
BINARY_DIR ${CMAKE_SOURCE_DIR}/build
BUILD_COMMAND ${CMAKE_COMMAND} --build .
#--Install step---------------
INSTALL_DIR ${CMAKE_SOURCE_DIR}/install
)
I am sorry if the question was already asked but after some research I couldn't find an answer. I want to copy the .exe of a project into a folder automatically.
I am using Qt creator 5.0.1 MSCV2010 and it always makes two outputs: release and debug.
For example, I want the /release/project.exe to be in /release/exec/project.exe.
I saw I can copy file like .dll with in a .pro with:
INSTALLS =
But it only work with files which already exist, or the .exe is generated after the compilation. I think I can specify this into:
projects settings->Build compilation->step Make : jom.exe in C:\path\to\project-release
But I don't know what argument is needed,
Regards
On Windows you can use DLLDESTDIR variable which specifies where to copy the target dll or exe. Just add this to your .pro :
CONFIG(release, debug|release): DLLDESTDIR += $$PWD/../exec
On Linux you can use QMAKE_POST_LINK variable which contains the command to execute after linking the TARGET together. So it is like:
CONFIG(release, debug|release): QMAKE_POST_LINK += $$quote(cp project $$PWD/../exec)
Here project is the name of the target file which you provide by TARGET = project
These will copy the executable binary to a directory named exec one level upper than the program working directory. You can have your arbitrary path.
add a custom build step with the command an parameters
for windows (assuming you are doing this for the release build):
xcopy
Release\<target.exe> path\to\destination\file.exe /Y
%{buildDir}
This should work. I couldn't find any variable that points the target_path. So I defined it:
### to copy target file to build folder
CONFIG(debug, debug|release) {
TARGET_PATH = $$OUT_PWD/debug
}
CONFIG(release, debug|release) {
TARGET_PATH = $$OUT_PWD/release
}
win32: QMAKE_POST_LINK += copy /y "$$shell_path($$TARGET_PATH/app_name.exe)" "$$shell_path($$PWD/../build/)"
unix: QMAKE_POST_LINK += cp "$$shell_path($$TARGET_PATH/app_name)" "$$shell_path($$PWD/../build/)"
I want to copy a data file from a directory in my source tree to the directory of the linked app so it's available at runtime, on Windows only. There appear to be two suggested techniques: use a post target dependency to issue a DOS copy command (Including resource files in Qt Creator build directory) or use an install step (Copy a file to the build directory after compiling project with Qt), but I cannot make either work in the way I would like.
The former requires me to use qmake path variables to generate my source and destination paths, but they contain backslash path separators, which the DOS copy command cannot handle.
The install solution forces other users of my project to set up a post build step in Qt Creator before it will work (one per configuration, in fact) and I would like to avoid this, as I want to make my project work with a default Qt Creator installation.
Is there any way to do this apparently simple task that can be wholly defined in the .pro file for the project? For example, is there a way to expand qmake path variables in a platform specific way?
Though these commands run ONLY after the executable is ACTUALLY linked, this solution doesn't require an external batch file. Note: this a Windows-only solution:
From our .pri file:
win32 {
...
# Copy the appropriate dll files into the target destination directory.
QMAKE_TBB_LIBDIR = $$quote($$PWD/MySource/MyLibs/$${PLATFORM_NAME}/vc9)
QMAKE_POST_LINK = copy /y $${replace(QMAKE_TBB_LIBDIR, /, \\)}\\*.dll > $${replace($$quote(DESTDIR), /, \\)}
...
}
This places a command in the Makefile that copies all the .dll files in MyLibs/x64 or MyLibs/Win32 into the destination directory.
However, if the executable did not need to be linked, then the .dlls are NOT copied.
The post build batch file would not have this limitation.