When executing (asdf:load-system “foo”) at the REPL, how can ASDF know which version of project “foo” to run, if there are multiple versions of that project?
Each of my ASDF projects resides in a different directory. The top level of each directory contains the source and ASD files. But I keep different working versions of each project in multiple subdirectories, to enable easy reviewing or reverting to an earlier version. Each subdirectory contains its own source and ASD file for loading the appropriate files needed for that version. Is there an easy way to switch to different project versions from the REPL without typing in the full pathnames? I can put the pathname to each project in the *central-registry*, but should the version pathnames be there too?
Related
Currently I have to manually copy the platforms and imageformats plugin folders to the directory containing the .exe that MSVC compiled. This is very tedious as the output folders often get deleted if you're working on your CMakeLists.txt or changing compilation target.
Now qt_generate_deploy_app_script seems like an official Qt solution to solve this problem, but it does not work.
I have added the CMake bits to my CMakeLists.txt as stated
qt_generate_deploy_app_script(
TARGET HiveWE
FILENAME_VARIABLE deploy_script
NO_UNSUPPORTED_PLATFORM_ERROR
)
install(SCRIPT ${deploy_script})
I can see some generated deploy scripts appear under build\x64-RelWithDebInfo\.qt, but they do not seem to be run as no DLL folders get copied to where my .exe is.
Am I misinterpreting what qt_generate_deploy_app_script should do or is it simply broken?
If you want to Creat exe in windows From Qt project you should use windeployqt
To Deploy and create Exe output with QT in windows you should follow this way:
put your compiler path in your system path. for example, if you use mingw81_64, you should set it. something like Qt/tools/mingw81_64/bin
copy exe file that provides after building in release mode in one
folder and run mingw81_64 cmd (it has separate cmd) and cd to that
folder path
windeployqt app.exe
you are using Cmake So first create one release output and then use step 3.
This command will get all dll needs for your app and your exe will work .
if you use qml
windeployqt --qmldir (the path of its directory ) app.exe
and also see these youtube videos for more info:
https://www.youtube.com/watch?v=LdSTgR0xJco
https://www.youtube.com/watch?v=hCXAgB6y8eA
Could someone please explain how one uses the premake extensions. I added the eclipse extension in a directory under my premake installation. And in the premake script I added recuire "eclipse".
Running the script with premake5 eclipse, I get an error module "eclipse.lua" not found.
I added the path of the modules directory to my environment variables.
I'm using premake (premake5) on Windows 8.
Thanks
addons need to reside in a folder. You need to create a "eclipse" folder, then copy all the files in it, and the "eclipse" folder should be located where premake can load it (either next the executable or some other place handled through environment variables)
I got this working by adding the full path to the require statement.
require "C:/premake/eclipse/eclipse"
and running the command as premake5 eclipse
Note: This plugin does not generate project files that one can import into Eclipse.
When I release my Qt project, I want to redistribute the QtCore5.dll and Qtxxx.dll files.
How can I make myapp.exe to find them automatically?
The best way of doing this seems to be by editing a qt.conf file placed in the same folder as my executable.
myapp.exe is in c:\myapp\bin folder
The dlls are in c:myapp\common folder
"Better" way is to put your qt.conf into your resources :/qt/etc/qt.conf. This way has highest priority for resolving platform dependencies.
In our project we use cmake to generate necessary qt.conf file: in debug mode we put path to installed Qt binaries and in release - to local (deploy) folder.
Qt5xxx.dll files are linked, so you should place it in same folder, or make them available throught PATH environment variable. If you really want such exotic redistribution system (please, say real reason) - you may create your own platform-specific launcher, that will load necessary .dll's from any path.
Just put all required dll files into the same directory as your executable.
Note, that there are more files to distribute than just Qt*.dll - you will need proper plugin from platforms subdirectory and many more. Read Qt documentation on deploying application under Windows - it will teach you all required files.
I have been able create an application that depends on webkit and scripts in Qt5.2.1.But i was able to create a deb package for 14.04 version Ubuntu .But how can i make it as stand alone application .I have seen static and dynamic build .I tried static build but I don't kon w how to include webkit for static build.Also is it possible with shared library approach for creating a standalone application.Please help me out here..
Deploying a dynamically linked Qt application :
You should place Qt so files along the release version of your executable. These are libQtCore.so, libQtGui.so and possibly the ones for other modules that you have used. These so files are in your installed Qt directory in lib folder or in the directory /usr/lib/i386-linux-gnu. If you are using plugins you should place their so files in a folder named plugins beside your binary. In case of using icons and images you should ship their so files like libqico.so and libqsvg.so in a folder named imageformats.
Gathering required shared libraries :
If you want your application to run independently on a bare installed Linux, you should gather all dependent shared libraries and put them in your application directory. You can simply do it by a shell script named cpld. You can easily copy all dependencies to a folder.
It's worthy to note that you can put this in your .pro file to cause the dynamic linker to look in the same directory as your Qt application at runtime in Linux :
unix:{
# suppress the default RPATH if you wish
QMAKE_LFLAGS_RPATH=
# add your own with quoting gyrations to make sure $ORIGIN gets to the command line unexpanded
QMAKE_LFLAGS += "-Wl,-rpath,\'\$$ORIGIN\'"
}
I have a project with some folders which happen to contain source files with the same names.
My source tree looks like this:
project.pro
foo/
conflict.h
conflict.cpp
bar/
conflict.h
conflict.cpp
some.h
other.h
files.h
main.cpp
Per default, qmake generates a Makefile which will produce a build tree like this:
conflict.o
main.o
target
Where conflict.o is the object file resulting for both foo/conflict.cpp and foo/conflict.h.
I can't to change their names because they are generated using an external tool and forcing different file names would imply to change their contents, so this is not an option.
I also don't want to use qmake SUBDIRS template because this would imply that (1) every subdir is built separately as a library and thus very much complicate the overall build process (in my eyes at least) and (2) in the top level directory I can't have any source files. Or am I wrong?
Can't I just tell qmake to write the object files into separate directories within the build directory? So my build tree will look like this:
foo/
conflict.o
bar/
conflict.o
main.o
target
Or are there any other solutions neither requiring to rename the source files nor introducing something complicated like static libraries? I just can't believe that Qt didn't solve this (in my eyes simple) problem for years. (I already hat this problem 4 years ago but could rename the files in that project, while here I can't.)
If it's important: I use Qt 4.8 on both Ubuntu with G++ and Windows with mingw32.
Are you tied to qmake? If not, an alternative could be to use cmake. I just verified your usecase with a simple CMakeLists.txt like
cmake_minimum_required (VERSION 2.6)
project (conflict)
add_executable(conflict foo/conflict.cpp bar/conflict.cpp main.cpp)
which even included a source file in the top level directory (main.cpp). This properly builds the executable - the object files are created in sub directories like
./CMakeFiles/conflict.dir/main.cpp.o
./CMakeFiles/conflict.dir/bar/conflict.cpp.o
./CMakeFiles/conflict.dir/foo/conflict.cpp.o
cmake also includes support for Qt4, to automatically pull in the required include paths and libraries. It might require some effort to migrate from qmake to cmake, but given the requirements you have I would give it a try.