Photo by Luca Mascaro on Flickr
It’s official: we are pleased to announce the first ever Qt contribution-centric event!
On June 16-18 in Berlin, Germany we will be hosting a summit where Qt contributors from around the world can meet to discuss Qt and to plan ways of working together on creating Qt for the future.
As we move forward with our Open Governance project, we believe that by summer it will be about time to put people together in one location. There are many topics to discuss for us, developers already contributing today and those sitting on patches for tomorrow.
The idea is to meet in sessions following an adapted (and partly more structured) un-conference format. Right now, we’re collecting topics that we would like to discuss but there will be plenty of room for suggestions by attendees and ad-hoc sessions.
The Summit is invitation only and here’s a form for you to request your invitation. Please include the contributions you have made to Qt or provide other justification as to why you should come. This isn’t a spectator event!
We will review all requests and come back to you as soon as we possibly can. We don’t want to leave out anybody but we also need to make sure that we actually can get things done and will not be sidetracked. It’s only 3 days after all.
We will soon publish our initial list of topics so you can see what we have in mind and take the opportunity to make suggestions or give feedback.
Possibly related posts:
6 comments
I can’t attend (maybe if somebody else pays), but I’d like to add a topic to the agenda: Build.
Summary: The question is, “What about Next-Gen Qmake, technology, languages, and build handling”.
I’ve read the last threads on this topic a zillion times (there’s a lot of information there):
Since this is a couple years later, I’m concluding the “answer” is QtCreator. It’s an interesting twist as both an IDE and a “project manager” (I use it and like it). However, it doesn’t answer the build-specific issues, expanding into serious Configuration Management for non-trivial heterogeneous asset bases.
I like qmake because it’s so simple. However, it doesn’t always scale for complex things, or for very large collections of very simple things.
I ended up writing my own — C++ multi-threaded engine (using QThread), no config files, automatic “discovery” of workspace, spidering of all header dependencies, auto-determination of Qt modules based on Qt header inclusion (which are added to the link line), and scons-like “auto-moc” where Q_OBJECT in the header (or cpp) triggers the “moc” step. My goal was “no project files” and “no manual build maintenance when suddenly deriving a class from QObject”.
It’s not distribution-viable yet, but it’s close (I wrote it for personal reasons to handle my many projects). I’m mostly interested in where the Trolls are going with their own project/workspace/config-management build world. I’m sure it’s somewhat coupled to QtCreator, but the Q_OBJECT/moc build step is sufficiently significant IMHO that it would be nice to have a better tools infrastructure for (very large) projects/config management.
And, IMHO, this issue will be increasingly significant since the forward-looking direction seems to be greater modularization and configuration-management/versioning of the Qt code base (a direction I support). Further, this issue is increasingly significant with the expanse in cross-platform targeting, such as for different mobile devices (with their own weird build-and-deployment steps) in addition to the (cross-platform) desktop, and with the added layer of new technologies like QML that introduce their own resource bundling/deployment issues.
Will there be a public agenda before-or-after this meeting? (Just curious.)
Here are the links that were stripped:
http://labs.qt.nokia.com/2009/10/12/to-make-or-not-to-make-qmake-and-beyond/
http://labs.qt.nokia.com/2009/10/14/to-make-or-not-to-make-qmake-and-beyond-redux/
Sorry, the links were stripped and any follow-up posts to present the links are stripped — (weird).
I was referencing the Trolls’ last great threads on “build” from October 14 and October 15, 2009, “To Make, or not to make — QMake and beyond” (and the “Redux” that followed the next day).
There’s a lot of great stuff in those threads.
Post with links are held back for moderation due to 90% of them being spam. So just wait a little bit for a moderator to look into that.
@charley: tried CMAKE yet?
@jospoortvliet — yes, and I agree with the comments in the threads: CMake is powerful and scales (perhaps even the “most powerful” and “most scalie”), but has its own idiosyncrasies and specialized knowledge required to use effectively. Since I’m lazy, I wanted something with more heuristics and auto-determination (I have many hundreds of projects — many are small command-line utilities that share an overlapping code base for different domains/libraries, and project file maintenance was quite painful).
So, for my needs, my little utility literally generates exported *.vcproj/*.sln files with qmake-like “moc” handling without any “input” files since I glob the file system and spider the contents (I’m mostly Qt Win-Commercial on MSVS2008). Actually, at present, I don’t have any “configuration” files either — I auto-detect the “latest” Qt installation, and other installed tools and use “standardized defaults” (again because my laziness knows no bounds).
Then, because I figured out just how *bad* the MSVS *is* for *build* (fine as an IDE, terrible for a build engine, which Microsoft agrees is not its purpose), I’m in the process of implementing build engines to build directly in “build-farm” capacity (but will still kick out *.vcproj/*.vsln because those are handy for debugging in the IDE).
Of course, to be distribution-viable, I’m sure I’d *have* to provide user-input (user-control) of settings/configs/tools. I just haven’t gotten there yet. I’m actually a bit surprised how far I could get without those things — I really didn’t think I’d get even this far.
)
Comments on this entry are closed.