I am working with different cross compiler compilers, and an evaluation of premake for GCC has proven to be very successful.
Now i want to use Premake for cross compiling to different embedded targets and compilers. Is there someone that knows how to extend premake with new compilers, or it is possible already with current functionality in Premake5
If you haven't already, get the latest source code from the GitHub project. Take a look at the existing toolset adapters in src/tools. Read through the "Extending Premake" section of the project documentation. Ask questions on the Premake Developer forums.
Related
Hi I have a debian image on BBB I have already installed QT creator on B^3 but the problem is whenever I try to start a new project in qt creator, couldn't see any option of kit. Infact when i add qmake and compiler path the application throws error.
What can I do to solve the problem. Can i directly get the full pack of SDK from qt.io/download ?
You must compile Qt libraries for your device (BBB) on your own, using specified compiler. You can find more information on this topic, here:
Qt Cross-Compilation Options
As soon as you compile Qt libraries for your device, you must move them to appropriate directories (on your BBB).
First, I would suggest learning to cross-compile, it's much faster & more easily maintained when you want to move to new versions. There's a ton of documentation and community around doing this. Windows & Linux both of which are probably dated, but info is still relavent. I've heard it's much easier from a linux host, but that could be biased.
That being said, if you don't want to cross-compile I believe you can simply install the qt embedded libraries. This question may offer some good advice. Once you have the libraries installed, you should be able to use qmake directly to create the Makefile for your project, then you can use cmake, or g++, etc.. to do the actual compiling.
You're likely going to work in command line though, I'm not sure you can run QT Creator on the BBB directly. I could be wrong.
I would like to know reasons for use CMake for particular project over qmake and vice versa.
Simply what are the pros and cons of both build systems?
Both are build systems, but they're not very similar at all. If your project uses Qt, you're probably best off using qmake. CMake is more generic, and fits pretty much any type of project.
Both qmake and CMake generate a Makefile, which is read by make to build the project. Not all build systems generate a Makefile, but many do. Even a Makefile is a type of build system; it tells the compiler and linker what to do, in order to create an executable (or a dynamic or static library).
If your project uses Qt, but you don't want to use qmake, you'll have to do a few more things yourself:
running the Meta Object Compiler (MOC)
include paths (tell the compiler where to look for Qt headers)
linking (tell the linker where to look for Qt libraries)
So, you'll have to do a bit more work to build a Qt project without qmake, but it is possible and it will teach you a lot about how Qt and qmake do things.
On a personal note (take this only as a recommendation, do further research yourself): I'm not a big fan of qmake. It helps you with the Qt stuff, but apart from that, I've found it to be pretty limited.
In any case, I would recommend learning to build a small project (~10 source files) without using any type of build system. Not using CMake, not with a Makefile, just using the compiler and linker directly. You shouldn't actually build any real project in this way, but you should learn how to do it, just to learn what build systems actually do. Knowing what they do will make them a lot easier to use.
A few months ago, we switched a project from qmake to Premake, which is also worth a look. It's highly scriptable (with Lua), which is great when you need to customize your build process.
That said, it is a bit more "manual", so prepare yourself to learn how compiling and linking works at a more basic level, without the use of a build system. It's also in beta (Premake 5), so there are some bits and pieces still missing.
You can also take a look at qbs, which is supposed to be a better qmake. It's still in a beta stage, so I'd wait while it matures and becomes easier to use.
CMake is by far the more powerful build system. The syntax is "not so nice" to put it mildly. But then, for any complex project, what one has to do with QMake (or any buildsystem I know of) to achieve things isn't nice either. For simple projects, QMake is nicer to look at though.
If you need configure checks for third-party dependencies other than Qt, CMake is what you want, support for configure checks in QMake is minimal to non-existent.
QMake on the other hand works great with Qt Creator (CMake support in there is lacking, although it's doable to use CMake with Creator).
If you want to build and deploy for iOS and Android from within Qt Creator, I strongly suggest QMake. (Not sure if it's even possible these days with CMake - it will be certainly cause a lot more headache).
I use CMake for my Qt projects and am very happy with it. Specifically, I have the following in my CMakeLists.txt:
set(QT_VERSION_REQ "5.2")
set(CMAKE_INCLUDE_CURRENT_DIR ON)
find_package(Qt5Core ${QT_VERSION_REQ} REQUIRED)
find_package(Qt5Quick ${QT_VERSION_REQ} REQUIRED)
find_package(Qt5Widgets ${QT_VERSION_REQ} REQUIRED)
find_package(Qt5Gui ${QT_VERSION_REQ} REQUIRED)
set(CMAKE_AUTOMOC ON)
QT5_WRAP_UI( UI_HDRS ${UI_FILES} )
ADD_EXECUTABLE(${MOC_HEADERS})
target_link_libraries(${PROJECT_NAME}
Qt5::Core
Qt5::Quick
Qt5::Widgets
Qt5::Gui
)
I hope this helps if you do decide to go with CMake.
CMake will help you generating configuration files for many build systems (a "build system" is called Generators in CMake). See What is a CMake generator?.
It means that if you have a set of C/C++ sources and a well written CMakeLists.txt, you can use CMake to create projects for different build system (IDE based on command-line based) like Visual Studio, CodeBlocks, g++...
With CMake, you can choose the IDE and compiler you will use in the end and 'easily' switch between supported ones.
qmake, as far as I know, will only support QtCreator as an IDE (itleft using 3rd party compiler in the background: nmake from Visual Studio, g++, MinGW...). But you won't generate a Visual Studio solution (sln file) using qmake. That's the main limitation I see in qmake (because I hate QtCreator...Visual Studio is way more powerful and intuitive...but that's just my opinion).
It's true qmake makes it easier to compile Qt-based applications (because MOC, .ui and liking to Qt is natively supported) than CMake. But it's doable anyway using CMake (there's built-in functions for Qt integration). Only your CMakeLists.txt may have to be reworked a bit when moving to new releases of Qt (I had a hard time when moving from Qt4 to Qt5, I guess that using qmake makes this easier).
Personnaly, I use CMake for my build environment and, when I need to use QtCreator (for Android deployment mainly), I make my CMake scripts generate a .pro file for qmake/QtCreator. It works well because qmake .pro file syntax is really simple. Then I'm not locked to a specific IDE.
qmake
Has focus on projects using Qt
Project file is easily generated by QtCreator (good for beginners)
Supported by QtCreator
CMake
Is used in a wide range of projects
Supports a lot of platforms and languages
Supported by multiple IDE's: e.g. QtCreator, Visual Studio
Generates project description for multiple IDE's
Contains commands to make usage of Qt easy (Most important: automoc)
My recommendation: Use qmake in case QtCreator is your IDE and you starts with Qt or C++. Use cmake in case you want to do any complex stuff in your build.
Both qmake and CMake work similary. See http://www.th-thielemann.de/development/cmake/cmake_qmake_to_cmake.html for a tutorial to migrate from qmake to CMake.
I downloaded the qt embedded demo source code recently on my linux machine. Following are the outcomes during running of the program
I compiled it statically on my x86 machine and run the application on x86 machine it runs fine. But when i took the statically compiled binary file to other machine with Atom platform It run with some missing widgets. I found that the plugins cant be ported with static compilation. Can anybody tell me is it true? If no can anybody tell me the steps for it?
I compiled it dynamically with shared libraries. Then got an executalbe on linux. I did "ldd MyAppName". It show me the shared library files it is using. But I dont know how to package these. Can anybody tell me the steps to package it?
I checked in the article on deploying qt applications on X11-linux platforms. But its not complete. Can anybody give me the detailed steps?
Any help will be appreciated......
you either have a distro, that does'nt support atom, or libraries, that are not compiled with support for it. either way - something somewhere on your system (or your qt) is not compiled for atom
The problem is that you are compiling your app, and its libraries (static or dynamic) work for x86, not for Atom. Perhaps you are able to create some sort of fat binary (lipo?) so that pieces of your app will function on x86 and Atom, but bits using the x86-only libraries will not function on Atom. (Right? That's a concise definition of your problem?)
If you have the source code for the libraries that don't run on Atom, and they're important to you, you should consider porting the code to Atom. If it's open-source code, you can contribute to the project. While you didn't give many details, my (very generic) approach to this would be to get the code on an Atom machine, write a very short test application for the library, and work out the issues.
Re #2: There's little difference between compiling an app and linking to shared libraries or dynamic libraries. On your x86 machine, if you have this code (these "plugins") compiled as dynamic libraries, it's pretty much the same as statically linking those binaries into the app. These libraries will work on x86, whether they're dynamically or statically linked.
I'm not sure if that helps very much -- if you're getting binary Qt plugins as static or dynamic libraries without source, you're out of luck. Submit a bug report. If you have source code, you can do a lot more.
I just dynamically compiled my application and ported to atom platform. I found the dependencies and ported them also and set the environment variable LD_LIBRARY_PATH on target machine to my ported shared libraries and It worked. Thanks everybody for your suggestions
I come from UNIX world, I'm quite familiar with Linux, Solaris, Cygwin
and MinGW development. Recently I ported one of my
big projects (cppcms) to support MSVC,
including building static and dynamic libraries with CMake.
And I get all the time absolutely weird issues:
I had CMake build issues because Windows programming
lacks naming convention
for import and static libraries.
Now I discovered that I should use different versions of ICU (debug/release builds) according to the
actual build I do (Debug/RelWithDebInfo -- should use Debug ICU, Release release ICU) and so I should
change actual conventions for searching libraries according to debug/release mode only under MSVC.
Otherwise application just would not start giving a error on missing DLL.
I don't have any such issues under Mingw or Cygwin with GCC, Open Solaris with Sun Studio or Linux with gcc or intel compilers.
And I still have numerous wired issues and wired bugs and very strange behavior -- even some trivial things do not work
under MSVC builds, when everything works absolutely fine under Solaris/Linux/Cygwin/Mingw using GCC from 3.4 up to 4.4,
Sun Studio and Intel compilers). But not under MSVC.
To be honest, I have no idea how to deal with Last one! Because it looks like for me more like environment issues.
I know that the question is not really well defined. I think I'm quite experienced
developer and I know how to write portable and good C++ code. But using Microsoft native
tools drives me crazy with issues I just don't know how to solve.
Question: What should experienced Unix programmer with quite good base in Win32 API should know when it
starts using Genuine Microsoft Tools?
P.S.: Can someone explain why "Release With Debug Info" requires Debug version of MSVC runtime? And why there two versions of runtime exist at all?
P.P.S.: Please note I don't have issues with Win32 API, in fact Windows GCC build works absolutely fine.
Clarifications:
I'm looking for pitfalls that programmer that come from Unix world would may fall into.
For example, when moving from Linux to Solaris: make sure you compile code with -mt or
-pthreads when using multi threaded programs, linking with -lpthread is not enough.
P.S.: Can someone explain why "Release
With Debug Info" requires Debug
version of MSVC runtime?
It doesn't.
And why there
two versions of runtime exist at all?
Because the debug version does more error checking.
And I still have numerous wired issues
and wired bugs and very strange
behavior -- even some trivial things
do not work under MSVC builds,
* What am I doing wrong?
Not telling us what "wired issues and wired bugs and very strange behavior" you get.
* Where should I start?
By telling us the specific errors and problems you encounter.
* What do I miss?
Reading the documentation and learning the tools.
If your question is "What do I read to become a good Windows programmer?" then my answer is: Everything from Jeff Richter, as a start.
There is no magic bullet which will automatically make you an experienced Windows developer. Windows is a very different land compared to Unix. There are lots of quirks, weird behavior, and stuff which is just plain different. The only way to get out with your sanity intact is to tackle the transition one small problem at a time. Concentrate on a specific problem and try to understand the problem. Don't just "get it to work", but really understand what is happening. A good book about Windows programming will help.
There are huge amounts of Windows knowledge and experience accumulated in the SO community, but the only way to access it is to ask concrete questions about specific problems.
The release and debug versions of DLL's use different ways of allocating memory, that is why it is not advisable to mix release and debug versions. If you allocate something in a debug mode DLL and pass it back to the application which was compiled in release mode you may get into trouble.
In the case of your naming issues you may want to have different directories where you place your static / dll's. You can do do this in visual studio by using the configuration manager, not sure how it is under the express version.
I think you need to try and actually understand the new toolset rather than just try and squish it into your current understanding of your existing tools. For that, the best way, IMHO, is for you to try and start to use Visual Studio as Microsoft intended and then once you can build a simple project in the IDE you can move to building it using your preferred make system but do so with an understanding of how the IDE is using its make system to set things up for that build (which WILL work).
So, for example, for part 1 of your question you want to create a simple static library project and a simple dll project and look at the linker options tabs. Jump to the 'Command line' view and you'll see that a DLL uses the /OUT linker option to set the name and location of the dll file and the /LIB linker option to set the name and location of the import library. With a static library only the /OUT option is used and it indicates the name of the static lib. It's true that if you're building a static lib and a DLL from the same source and you have both the /LIB for the dll set to MyCrossPlatformCode.lib and /OUT set to MyCrossPlatformCode.dll then you may have problems if you also build a static lib with an /OUT switch of MyCrossPlatformCode.lib... Simply don't do that; either build the static libs to a different output directory (which is what OpenSSL does), or, better (IMHO), mangle the names somewhat so that you have MyCrossPlatformCode.lib/.dll and MyCrossPlatformCode_static.lib (which is what STLPort does).
Note that you might also want to mangle in (or account for) building with different versions of the Microsoft tool chain (so you might end up with stlport_vc8_x64d_static.5.1, perhaps).
An alternative approach, if you really can't face the thought of understanding your toolset, is that you could take a look at some of the popular open source systems that build quite fine on Windows and Unix systems; OpenSSL and STLPort for a start, perhaps.
Is there a quick, straightforward way to make a Qt application into an executable? I attempted to follow the instructions at http://doc.qt.digia.com/4.1/deployment-windows.html but have been unsuccesfull thus far; I'm unable to Any help would be much appreciated. Thanks!
I always use CMake to build Qt projects, it's easy, free and cross platform. Guide : Compiling Qt4 apps with CMake. CMake also come with CPack to easly make installer for Windows, Mac and Linux.
I agree with chmod700 about the Qt Creator suggestion, it's not my favorite IDE but it's still really nice and easy.
Do you mean an installer package? I assume you are able to compile, link, and run your app and you mean how do you package it up for others.
http://installbuilder.bitrock.com/ <-- special handling of Qt based projects but costs $
http://www.jrsoftware.org/isinfo.php <-- my personal favorite and it's free (can be rough to learn advanced features though)
Though if you mean how do you build your app, you may want to try the new Qt Creator (http://www.qtsoftware.com/products/appdev/developer-tools/developer-tools#qt-tools-at-a) which will setup build targets for you and really makes desktop Qt dev a snap. Also if you're still using 4.1, you can now use 4.5 under the LGPL on all platforms making it almost a no-brainer to upgrade.
I'm not sure if I understand your problem. Assuming you're using MinGW, it's really easy and quite straightforward:
get the Qt sources and unpack them to some folder (f.e. c:\Qt\4.5.0-static)
install MinGW. Make sure the MinGW executable folder is in the %PATH% variable.
open a cmd windows, go to the Qt sources and run configure -static. You can add other config options if you like to, but usually you don't need that.
when building Qt finished, go to your application sources, open a cmd window and run the qmake of your built Qt installation -- i.e. c:\Qt\4.5.0-static\bin\qmake in the example given above.
run make
you get a statically linked binary in the end (you might want to check it with Dependency Walker).
Doing the same using Visual Studio is pretty similar.
Or do you want to build dynamically and create an installer package?