Autotools Project Manager, part 4: Moving from Gitorious to Gerrit.

After the first code review from the Qt Creator team, and due to the new Nokia changes related to open governance, this project has been migrated from Gitorious to Gerrit. This migration has blocked the development of the project more than expected, mainly due to the bureaucratic processes involved, but now things are back to normal, and after a second review it seems that we are closer to seeing the plugin become part of Qt Creator.

Also two great pieces of news. The first, is that the configure.ac file is now highlighted in the autotools project. Credit goes to Friedrich W. H. Kossebau, who pointed me to the right place and person in order to make this happen. The second, is that Mathias Hasselmann  has come up with a great idea: a script for converting devhelp books into Qt help collections.

As you see, all good news! Now, let's go on making Qt Creator rock!

Update: Since there is no way to have even read access to Gerrit unless one has an account in their Qt Bug Tracker Jira system, I will go on keeping the Gitorious repository up to date with all the changes. Enjoy!

Autotools Project Manager, part 3: The Merge Request

During the Desktop Summit 2011, I had the chance to meet some of the guys working on the Qt Creator (QTC) team. I took advantage of this opportunity and talked to them about the AutotoolsProjectManager plugin. After some discussion, among other things about the lack of available documentation and the intention of making a merge request (MR), I was invited to visit the Nokia office in Berlin. So, last week, I had a very interesting and productive evening there and got to talk to some of the developers, Tobias Hunger, Daniel Molkentin and Oswald Buddenhagen, as well as to Leena Miettinen (in charge of the Qt tools documentation), all of who I have to thank for their patience and the time they took to help me. After the visit and their great advice, I had some homework to do (fix some code style issues, add the documentation and code completion…) to get the plugin prepared for the MR. Now, it is finally available in gitorious, waiting to be reviewed by the QTC team! Let's keep fingers crossed!

Autotools Project Manager, part 2: The Plugin.

During the last past weeks, as I already announced and as part of my trainee program at Openismus GmbH, I have been working on a plugin for autotools support to be used with Qt Creator. The project is still in an early state of development, but already offers some nice features and is ready for its first release.

What can the plugin do?

• Load an autotools project and work with it in QTC.
• Syntax highlighting for Makefile.am files.
• Automatic project tree update if the Makefile.am or configure.ac file is changed.
• Configuration of build steps (autogen, autoreconf, make and configure).
• Build and run an autotools project from within QTC.
• Automatic code completion.

Some ideas for the future:

• Add syntax highlighting for the configure.ac file.
• Detect whether autogen.sh runs configure, and allow the user to configure that, to avoid a second configure run.
• Improve the parser. Autotools can generate several/different types of binares, libraries or other kind of targets. The current parser, checks for bin_PROGRAM binaries. If the output produces one of them, the parsing will be successful, if there are more, the parsing will not be successful. This should be changed to a more *Anjuta like* Makefile.am parsing style, which takes into account the existence of multiple outputs among other complex things. In the meantime, and as a suggestion of the Qt Creator's developers, I am using a ProjectExplorer::CustomExecutableRunConfiguration, which allows the user to choose which executable he/she wants to run, in case there is any.

How to use the plugin:

• Download the project from gitorious.
• Follow the README file for installation instructions.
• See that the plugin is recognized and loaded by Qt-Creator, by selecting Help -> About Plugins in QTC. The AutotoolsProjectManager plugin should be listed as part of the Build System plugins.
• Open an autotools project in Qt-Creator, using File -> Open File or Project... In the prompted dialog-box, select the Makefile.am from your project. This is the only way a user can use the autotools plugin. Thus, a Makefile.am must always exist before hand. 
• The first time an autotools project is opened with Qt-Creator, a dialog-box pops up and the user will be able to select the build directory. Qt-Creator then puts a .user file in the directory so it doesn't need to ask again. Only in-source building is working right now.
• After clicking on the Finish button of the Autotools Wizard, Qt-Creator should show the project's tree structure at the left side hand. The root node should show the project name and all project files should be listed and editable from there. 
• At this point, building and running the application should work. This will execute autogen.sh or autoreconf, configure and make. The first time, when running the application, a dialog will ask you to choose the executable's location, then, QTC will remember it for the following times. Ideally, this will be changed in the future, to be done in a more automated way.
• When selecting Projects->Build Settings from Qt-Creator on the left side bar, notice the typical autotools build steps (autogen.sh/autoreconf, configure, make). You may configure some parameters such as adding new configure parameters or changing the build directory (though, as I mentiond before, only in-source building is working at the moment).

As always, all comments and feedback is very welcome. Have fun!

Autotools Project Manager, part 1: Understanding QtCreator's Project Explorer

It has already been more than one year since Peter Penz created a plugin for autotools support to be used with Qt Creator. In the meantime, Qt Creator developers have been busy, and having fun, rewriting several parts of the code, which, on the one hand, leads to nicer, improved interfaces, but on the other hand, to API breaks. So, it was time to "update" (redo) his work, and this is what I am currently working on.

For a trainee with a year’s experience, this is a more than challenging task: no experience developing for Qt Creator or with plugins, nor much experience with autotools, no documentation at all... In the beginning, I did not know how to start, nor if I could actually get something done at all, but then, with the help of the wisdom and patience of Peter Penz, David King and some of the Qt Creator guys, Tobias Hunger and Daniel Molkentin, things started to develop.

There is no documentation on how to develop a plugin for Qt Creator, so I had to spend a lot of time reading Qt Creator's code, in order to understand which bits I would need and how they were related. As I already said, this was very time consuming, so I have decided to write a series of posts, of which this is the first, to share what I learnt with you, and maybe save you some time in the future. As always, this is not meant to be a guide or tutorial; this is just what I did and how I understood it. I would be happy if this helps you deal with the huge monster that is Qt Creator, or even if I get some feedback on things which might be wrong :)).

Understanding some basics:
Qt Creator is a plugin loader and all its functionality is implemented in plugins. A very basic Qt Creator plugin has three different parts:

1. .pro file, which is the project file.
2. .pluginspec.in file, that provides some information about the plugin.
3. projectplugin files, with the implementation of the ExtensionSystem::IPlugin interface in a class.

Also, to give support for a new project type — in our case, the autotools project — we need to implement some interfaces in the ProjectExplorer plugin, which is what I am going to focus on in this post.

The ProjectExplorer plugin
The ProjectExplorer plugin is a set of classes and interfaces that make up the project management system in Qt Creator. Its architecture is detailed in the chart, and explained in the following lines:

The Project (ProjectExplorer::Project) is the whole project itself, and it is always associated with a MIME type (specified in an .mimetypes.xml file), which defines the kind of file the project will be indentifed by, when the project is opened in Qt Creator.

The ProjectExplorer::Project class loads the project and embeds it into the QtCreator project tree. Every project supports one or more Targets (ProjectExplorer::Target), which are the target environments for which the developer wants to build the project (desktop, Symbian devices and
MeeGo, among others).

A Target can have several BuildConfigurations (ProjectExplorer::BuildConfiguration), DeployConfigurations (ProjectExplorer::DeployConfiguration) and RunConfigurations (ProjectExplorer::RunConfigurations).

A BuildConfiguration (for example, release or debug) represents all that is needed to build the project for the target. Each BuildConfiguration currently has two BuildStepLists (ProjectExplorer::BuildStepList), which are a set of instructions to run. The first list is used to build, and the second one to clean up. The BuildStepLists contain BuildSteps (ProjectExplorer::BuildStep), which are the steps that need to be executed ("make", "make clean", etc.).

A DeployConfiguration contains a BuildStepList, and is used to deploy the aforementioned BuildConfiguration output into the right place for later execution by the RunConfiguration.

A RunConfiguration defines what needs to be run: usually the program that was built before. It could also be some set of unit tests, a script, some existing application which is used to test a library that was just built, etc.

You can also get an overview of what a generic plugin should implement by looking at the genericprojectmanager plugin example in the qt-creator/src/plugins/genericprojectmanager directory.

Have fun!

Back from "Qt Developer Days 2010".

As I said in my previous post, I spent last week in Munich attending the "Qt Developer Days" and it was pretty interesting. 

Monday:
Was focused on training, so as newbie in the Qt world that I am, I attended the Essential's track which gave me an overview on the topic and woke up my interest in the language even more. I just found Qt Creator a fascinating tool together with the integration of Qt Designer. Qt Assistant and its brilliant examples is not less in this family. 

Tuesday and Wednesday:
I was able to attend the technical track. From all the talks, the ones that definitely captivated my attention, were those based on Qt Quick. Qt Quick (Qt User Interface Creation Kit) is a technology for creating UI's in a very fast way, using the declarative language QML, which allows the developer the usage of Javascript too. It is very useful for creating prototypes specially, although Mobile apps, and small desktop ones are a goal of this technology too. I am not sure if complex desktop applications are, but let's keep our eyes wide open...

Not all was learning and working. We managed to enjoy some food, beer and music from the area at Donisl's and on Wednesday evening, we managed to meet Murray for dinner and have a look to the Munich offices. Very nice!!

This week I will start my new mini-project on Qt and post about it very soon.

Thanks for reading!

Qt Developer Days 2010.

Next week I will be in Munich for the "Qt Developer Days". I will be attending the "Qt Essentials"  track and I presume it is going to be quite interesting and one of the best ways for doing my first steps in the Qt world. I am very happy that Murray asked us to go.

I will post again when I am back!.