Autotools Project Manager, part 5: [current status MERGED]

After all the work, I can already announce and celebrate, that the plugin for giving Qt Creator support for autotools projects, has been merged today into Qt Creator! I could not have finished my time at Openismus GmbH and series of posts related to the plugin in a better way. I am very happy of the result and hope it will be helpful for those who love autotools. Enjoy and see you soon!

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 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!