Cross-platform support?
-
On my machine clang still uses the GNU one, but they are working on it: lld.
That's not yet found its way into normal distributions of clang, but there's also
llvm-link. However, that appears to be focused much more on cross-module linking at the IR level rather than at the object code level. (I've never tried using it.)
-
But then you are happy trying GTK+ without one, because, well, it does not really have any. So go ahead and use Qt without their IDE too. It works fine with Eclipse or CodeBlocks or just VIM with youcompleteme.
There is a stand-alone documentation browser, the "Qt Assistant" or you can use the documentation on the web. Which is no worse than GTK+, it has the same two options.
These two things go together because the documentation for Qt all assumes you're using the IDE. At least, what I could find. Finding some helpful howtos for non-IDE dev is somewhat hampered because none of the results were up to date. I much prefer non-IDE dev, myself.
I'll have to see how much further I can get on your suggestions. Thank you for them.
Mono is somewhat behind and lacks WPF, but some cross-compatibility is possible even then. In fact GNOME has some applications running on mono (but GTK+ UI; the basic WinForms are there too though, only WPF is not).
I looked into this; it seems like a bit of a nightmare. At least, it's more than a single-developer shop (ie, me) can handle in the time frame I have. If it worked out of the box, that would be a dream. Hopefully soon...
-
These two things go together because the documentation for Qt all assumes you're using the IDE.
"The" IDE, Qt Creator, only appeared in version 4 cycle and was built on the stand-alone tools (Qt Designer and qmake or cmake) that were used up to that point. These tools were created with sensible defaults and don't need much setup. So the IDE is not really doing that much and everything it does ends up in simple, readable and documented text files (the UI layout is XML, but you'll be editing that one with the Designer).
So you can just start from a sample or use the IDE only to create the project template and from then on just manually edit the files.
none of the results were up to date
Qt is very mature and the core stuff is very stable, so most of them apply just fine. Use latest documentation for cmake but otherwise the way the special
mocpreprocessor works and the use ofQ_OBJECTmacro and compilation of the UI layouts withuicdid not change since very early releases.
-
"The" IDE, Qt Creator, only appeared in version 4 cycle and was built on the stand-alone tools (Qt Designer and qmake or cmake) that were used up to that point. These tools were created with sensible defaults and don't need much setup. So the IDE is not really doing that much and everything it does ends up in simple, readable and documented text files (the UI layout is XML, but you'll be editing that one with the Designer).
So you can just start from a sample or use the IDE only to create the project template and from then on just manually edit the files.
I'm retrying this now with an updated install; turns out that I was ignorantly using somewhat older versions of these tools. One of the main frustrations of Ubuntu is the relative age of some of its sources; for 14.04, the repository version of Qt is a couple versions behind, for instance. Similar with Qt Creator. I often wish software maintainers could be convinced to keep up-to-date debian repos.
Qt is very mature and the core stuff is very stable, so most of them apply just fine. Use latest documentation for cmake but otherwise the way the special moc preprocessor works and the use of Q_OBJECT macro and compilation of the UI layouts with uic did not change since very early releases.
Part of my dysfunction may be that I am far better at taking apart than putting together. This may come from years of working on existing code bases, or it may just be my personality. Since most of the example code in the documentation requires some measure of tinkering (ie, creating files and blindly hoping that you're doing it correctly), it is instantly offputting. A good example is (http://doc.qt.io/qt-5/cmake-manual.html) where they specify contents of a CMakeLists.txt file, but don't say that's what they're doing. If I weren't expecting that they were talking about that file, I'd be utterly at sea as to how to start... and that's ignoring that they don't actually have a full example.
So, yes, I am certainly on board with you about Qt being mature and stable. There is no doubt in my mind about that. However, their documentation leaves much to be desired!
-
However, their documentation leaves much to be desired!
I find it rather good. It did cause me a few stumbles though when I did things wrong because the right way wasn't emphasized enough IMHO, so I think your point is valid up to a certain level.
A quick note: I just recently went through a fresh install of 5.4 and accompanying tools using their online installer, and for some reason the docs weren't added in QtCreator, so pressing F1 while hovering a class/function didn't work. I find that the best way to access the docs so do try that out. If it fails you just need to link to correct .qch files in the options.
-
Another gotcha:
Cloned their repo to build for Windows to cross-compile... except the "qt" repo is 4, not 5. For that, you have to clone the qt5 repo.
One the plus side, the qt5 repo is set up with submodules (ie, correctly), so that may make the pain worth it.
Also, their installer doesn't work the way I'd like it to; it installs in its own, isolated folder. So "qmake" invoked from just any old where gives me the old version. I'm hoping "make install" from the repo is more sensible.
-
Sorry, can't give a helping hand there, I only used the installer, had no specific need to compile from source. Let alone on Windows.
-
Oh no, not on Windows--for Windows. What I'm trying to avoid is having to reboot to recompile, which is, for me, the #1 advantage of using Qt or GTK--being able to keep using Linux daily while working on development. I will also want to at some point add support for OSX, which means having to recompile for that so I can add the build kit appropriately.
But this is my original post's complaint: part of the reason for choosing something like Qt is for cross-platform support, but setting it up to cross-compile out of the box is hilariously difficult, and not for any good reason. Given the way that Qt Creator is set up, it should be straightforward for them to ship a precompiled set of Qt binaries for cross-compiling for any of the six (or nine if you include mobile, assuming noone in their right mind is going to want to compile, say, on Android for Windows) possible combinations. Indeed, I would expect Qt to have a very obvious and simple Linux->Windows compile process. That it does not is irksome.
-
To clarify:
I would, minimally, like to share my project's repo between Linux and Windows and have no chronic build issues. I know their may be some tweaking required to get things working, but I don't want to have to, say, manually fix code between rebuilds.
Ideally, I'd like to work exclusively in Linux and build for Linux, Windows, and OSX. This is what I'm trying to set up now. This requires having the libraries for Windows and OSX available on Linux (ie, building Qt or GTK+ for both of those additional platforms); it would seem like a cross-platform framework like Qt, which is otherwise quite excellently put together, would have out-of-box support for this kind of thing. I'm probably expecting too much. In any case, I'm currently waiting on the new repo to finish cloning and we'll see whether building qt5 for Windows and adding the new build kit to Qt Creator works.
-
Oh, sorry, misunderstood.
Well, I can tell you Android actually is painless. Download SDK and NDK, point QtCreator to the right directoy, done. Even deploying to device just works. You may need to install adb separately, not sure which adb binary it uses, but I already had it installed due to fiddling with custom ROMs so it just worked for me.
I only ever once needed to deploy a GUI app on Windows so far, and I already had a testing VM with Qt installed so I just used that.
iOS requires some XCode shennanigans AFAIK, not sure about Windows Phone.
-
...Ubuntu is the relative age of some of its sources; for 14.04, the repository version of Qt is a couple versions behind
Oh $deity yes.
I just checked and the Ubuntu repo is several years out of date.
I wonder why.The separation of qt and qt5 repos is due to the small amount of source incompatibility.
4.8 is still supported, and there are notable changes in API which mean 5.x is not quite a drop-in replacement.
We're moving a few projects up to 5.x later this year, will be interesting to see how it goes.
-
Oh, sorry, misunderstood.
Well, I can tell you Android actually is painless.
No worries; and I have actually seen the setup for Android development. It is remarkably simple, though that is cheating somewhat in that (almost) everyone who builds for Android is cross-compiling (or Java-ing), so Android woes would probably themselves be cross-platform. Heh.
The separation of qt and qt5 repos is due to the small amount of source incompatibility.
Well, I noticed they have everything set up as submodules, which is marvelous. For that alone I can forgive the inconvenience.
So, I got this working, and here's what I had to do, in short (I may write this up at some point, since it's well worth knowing):
On Ubuntu 14.04.
-
Installed latest Qt from the installer, since the source installer was wonky and I didn't know how to work it at first. (You have to set the target directory as a configure directive before you compile.) Presumably this could be done by compiling from source.
-
Installed the obvious needful thing, a cross-compiler. In this case, it was mingw. Specifically, for the settings, I used the i686-w64-mingw32-g++ binary.
-
Cross-compiled Qt on Linux for Windows (ie, compiled on Linux with the target platform being win32; the "xplatform" argument to Qt's Makefile is "win32-g++".
-
Added the Windows qmake binary (./$version_number/$compiler/bin/qmake) to Qt versions in Qt Creator; added the compiler I used to build that binary (i686-w64-mingw32-g++) to the compiler list; then created a kit using that compiler and targeting that version of Qt.
Debug builds don't work for mysterious reasons that I haven't sorted out yet, but the binary ran on Windows with one caveat: I had to ship the pthreads DLL with it to make it work. There is probably a way of either building it in or simply not using pthreads (it may be included in the demo program I was compiling, and therefore not necessary), but I haven't gotten that far. My next goal is to get cross-compile working for MacOS.
If it works, and if Qt's amenable to my preferred method of coding (when I stop using Qt Creator), then sometime this year I'll be shipping my first Qt application.
-
-
I had to ship the pthreads DLL
The
i686-w64-mingw32-g++compiler comes with two versions.i686-w64-mingw32-g++-posixandi686-w64-mingw32-g++-win32. The-posixmeans it uses pthreads for threading, the-win32uses native thread api.The unadorned
i686-w64-mingw32-g++is directed to one of them using alternatives. Try configuring it to use the-win32variant or use that variant explicitly (and rebuilding qt, obviously, unfortunately). That should not needpthread.dll(the thing I build does not, but I am not using Qt).
-
Awesome! Thanks for that tip. That should be very useful.
I am going to have to ship some stuff with it anyhow, as I'd like to dynamically link Qt (since there may be multiple programs at some point, hypothetically) rather than statically link it. Also, I need to rebuild it anyhow; it built pretty fast... or maybe I just played lots of Skyrim... hrm.
-
as I'd like to dynamically link Qt (since there may be multiple programs at some point, hypothetically)
At this point I'm getting so damned sick of conflicts with dynamically linked versions that I'm beginning to be of the opinion that dynamic linking is only useful for lawyering out of the GPL (Yes, I know how RMS feels about how the GPL as it relates to dynamic linking. I feel less dirty agreeing with corporate lawyers than I would feel agreeing with RMS, so fuck the opinion of the FSF. I am also quite fed up with jackwads using the GPL for libraries when the LGPL is right fucking there and is entirely more reasonable.)It's not like disk space and bandwidth are hard to come by anymore.
-
I am also quite fed up with jackwads using the GPL for libraries when
the LGPLBSD/MIT/WTFPL/literally any other license is right fucking there and is entirely more reasonable.)
<not empty
-
Even LGPL ain't too bad.
Personally, if I ever release any F/OSS, I'm going to release it under every license EXCEPT the GPL's.
-
I am also quite fed up with jackwads using the GPL for libraries when the LGPL is right fucking there and is entirely more reasonable.
Depends what your goals are. GPL serves a purpose, if you share that purpose it's a great license for libraries too.
-
some other implementation of ld
https://pbs.twimg.com/profile_images/503509190988414976/HIfeTLj_.jpeg
-
And that purpose is "Being the maximum level of self-centered head in the clouds dickweed possible".
-
And that purpose is "Being the maximum level of self-centered head in the clouds dickweed possible".
That purpose is "all software should be free. You want to use my software for free, yours should be free too!". Nobody forces you to use GPL libraries, you can choose to use different libraries or write your own. I understand it's inconvenient when the best library is GPL, I've been a commercial software developer before, but that's the purpose of the GPL.
-
That purpose is "all software should be free. You want to use my software for free, yours should be free too!". Nobody forces you to use GPL libraries, you can choose to use different libraries or write your own. I understand it's inconvenient when the best library is GPL, I've been a commercial software developer before, but that's the purpose of the GPL.
This. I don't follow that ideology myself and tend to release the few things that I write myself under BSD or similar, but I also see where they're coming from. There's also the fact that non-copyleft licenses allow commercial companies to incorporate your work, make money from it, and give you nothing more than a sentence in some documentation page that no one will ever look at. And I can certainly see why people would object to that.
-
If someone can manage to make a commercial product out of my various Dwarf Fortress file format decoders, I'd be happier that it's possible than upset that they didn't give me a cut.
-
There's also the fact that non-copyleft licenses allow commercial companies to incorporate your work, make money from it, and give you nothing more than a sentence in some documentation page that no one will ever look at.
I've had people do that with my code. I don't mind at all. The product wasn't my code; my code was a part of a library that made what they sold possible, but they added a lot of functionality on top (and that was what the customers were really paying for in the first place). If I were to go round trying to charge a fee for commercial usage, I'd just get my code being used less, and having my code in wide usage is a good thing anyway (I've had people buy me drinks at conferences and things like that, which is damn awesome).
-
At this point I'm getting so damned sick of conflicts with dynamically linked versions that I'm beginning to be of the opinion that dynamic linking is only useful for lawyering out of the GPL
Then explain why Windows makes it impossible to have a completely statically linked program? Are you accusing the Windows team of having a dynamic linking fetish?
-
The Windows team is made entirely of fetishists of various stripes.
-
There's also the fact that non-copyleft licenses allow commercial companies to incorporate your work, make money from it, and give you nothing more than a sentence in some documentation page that no one will ever look at. And I can certainly see why people would object to that.
If they're objecting, it's their own damn fault for releasing their software under a license that allows that.
-
If they're objecting, it's their own damn fault for releasing their software under a license that allows that.
That's... kind of my point? I was saying why people choose the GPL...
-
But evil big companies can still sell GPL software.
Look at ORACLE LINUX.
-
people choose the GPL...
People choose to release their code under GPL, because no non-GPL alternative already exists, surely?
(I know if I have a choice between a GPL library that does X and a non-GPL library that does X, life is simpler if I choose the non-GPL one...)
-
but I also see where they're coming from
"We've got so many things, for you to use, for free... All you need to do is j̢̢̥̹̮͔́ͧͦ̃ͯͫ̓̐̚o̖̯̘̳̞̳ͬͩ͂͜͜͝i̛̥̗̅ͫ̾̏̄ͮͪ̄ͬn̛͎̭͔̦̂ͭͬ͛ͤ͊͐ͥ͡ ̴̴̶͚̲̺͎̌ͦ̃̓͌ư̷̬̳̤̍ͩ͛ͣ̓̆̌̓̕s̷͗̐͏̞̬.̴̯̪̎ͩ̌̉ͥ̓͜͠.̸̢͚̤̦̪͉ͪ̈͊̾.̱̙̠͗͗̌̿̽̓ͩ͘͞"
Yep, I see where they're coming from too. And it's a dark, dark place.
-
(I know if I have a choice between a GPL library that does X and a non-GPL library that does X, life is simpler if I choose the non-GPL one...)
There are two libraries — gmp and readline — that I have wished were differently licensed in the past. Fortunately, there are alternatives to both of them (though the alternatives to gmp usually come with a speed penalty). I'm aware that gmp now has a more permissive license than it used to, but I'm not about to rejig all my code to use it now. Well, not unless I have a lot of spare time!
However, those two are rare examples of libraries that started out with the GPL as their license. Most developers aren't such massive dickwads.
-
dark, dark place.
The GPL guys think everybody else is heading for a dark, dark place where users of software are denied the right to tinker and modify it to suit their purposes.
Also, worth repeating: Nobody forces you to use GPL libraries. There are no secrets or surprises about what the conditions are, they're stated plain and simple on the box and widely broadcast over the Internet. If you don't like the price, don't use the library.
