A service to open source is a service to mankind.

Anjuta Design Goals

  • Simple and Usable user interface – simplicity over features.
  • Integrate and promote free software development tools and methods
  • Scalability – plugins work under no assumption of project size.
  • Extensibility – easy additions of new things.
  • Flexibility – isolate functions into independent plugins.

Building Anjuta From Source

Building anjuta from sources is recommended if you want to help develop anjuta or if you want to test blendig-edge features. Otherwise it is recommended to use the packages provided by your distribution.

Up to date build instructions

Are you a library or project maintainer?

Then you are looking to provide users of your library or project to use Anjuta for development. To do this Anjuta provides several means to make it easy.

You can start by creating a template for your library. Follow this simple tutorial to create project templates (no programming needed). You can either distribute the templates yourself or you can submit it to Anjuta bugzilla for inclusion in our next release.

Then if you need more advanced stuffs to use your project, you can create plugins to do them. Follow this nice tutorial to create anjuta plugins. Or you can pick up one of existing plugins and start adapting it for your project. Plugins have to be distributed separately since they are quite specific to your project. You can see some good examples of how it is done in Poky SDK pluginMaemo pluginMoblin plugin etc.

We are always listening if you need anything in Anjuta for plugins to work. So, feel free to ask for it in our mailing list.

Things to do in Anjuta

So, you got Anjuta from git and now want to contribute? There are always plenty of things to do in Anjuta. Check out this wiki for new and fresh ideas. There are also plenty of interesting bugs to fix.

And there are always some cool tools available, be it little command-line tools, or a full blown applications, that are awaiting to be integrated in Anjuta. This is where you can help write new plugins. You can read more details on how to write plugins in API documentation. Or you can contribute to existing anjuta related projects to further their development. Check out theprojects page for list of such projects. Some of them really will appreciate your help.

If you are good in writing, you can also help us expand and update our documentations. Users manual, faq and tutorials are all part of documentation available in anjuta source tree. Documentation is part of the source, so you need to get it from git in usual manner (see side pane for existing documentations).

All anjuta devs hang out in irc.gimp.net #anjuta channel. Catch us for a little chat or if you have some questions to get answered. You can also join our development mailing list anjuta-devel-list@gnome.org if you want to participate in our discussions.

Anjuta Releases

Anjuta follows GNOME release cycles, which is a timeboxed schedule. Check out upcoming events for any pending annoucements or releases. The full release calender can be found here. Releasing procedure follows as described here. Checkout our roadmap for interesting upcoming features.

Packaging Anjuta

If you are packaging Anjuta for a distro, there are couple of things to keep in mind. Anjuta is available in 2 different release, core and extras. Both need to be packaged. Anjuta extras contains some important plugins which were origninally part of core Anjuta, but separated at some point to allow easier maintenance.

Anjuta plugins have lot of wild dependencies, and many plugins are actually built only when their dependencies are satisfied. Distro packaging would need to satisfy all dependencies to ensure all plugins are built. However, this creates the problem that anjuta or anjuta-extras would flatly depend on everything and can be intimidating for varied users who may be only interested in certain kind of development (e.g. C developer may not be interested in python dependencies)

To avoid this, it is possible that anjuta plugins are packaged separately, particularly those that require unrelated and heavy dependencies. Any plugin can be separately packaged, All the plugins reside in anjuta/plugins/ in source tree (both anjuta and anjuta-extras). Each subdir under this can be packaged separately, but only pick heavy and isolated plugins for separate packaging.

It is important to keep the plugin package names consistent. Ideally, they should be called anjuta-plugin-*. This will also allow Anjuta to find additional plugins for installation on user’s request (once we finish some basic plugins finding and installation feature). If in doubt, please ask in our mailing list what plugins are best packaged separately.

Thanks for packaging Anjuta. We are always looking forward to active and regular distro releases.

See Also


Anjuta project was started in 27th Dec 1999. To learn more about its history visit the first archived anjuta website