This pages tries to summarize problems and solutions around the build system (in broad sense) in Anjuta. Feel free to modify this page, to add your own ideas.

Problems

Currently we suffer of some design problem in the build system. These prevent some basic features:

  • Run the program with and without the debugger in a similar way [Done]
  • Check if the executable is up to date before running it [Done]
  • Rebuild the executable before running it (need a notification when command end) [Done]
  • Have an easy way to build program for debugging (with debugging information and without optimization) [Done]
  • Be able to build single files
  • Support for tuning the build system (be able to have a scratchbox plugin using the standard autotool build plugin)

Run Program [Done]

Improvements

There are 2 "stop program" menu items, one used when the program is run with the debugger and the other when the program is used without the debugger. Merging both function will be perhaps better ?

The valgrind plugin has a dialog box to run the program too, it will be better if it uses the same parameters dialog too.

Implementation

A new run plugin has been implemented and is currently in SVN trunk. It adds a Run Menu items including 3 commands:

  • Run program: Launch the program
  • Stop program: Kill the program (if one is running)
  • Parameters: Allow to set
    • Program name (could be outside project)
    • Working directory
    • Arguments
    • Additional environment variables
    • Use of the terminal plugin or not

The run command has been removed from the auto tool build plugin.

The debugger now uses the parameters dialog of the run plugin and puts the menu items starting and stopping the debugger in the same run menu.

Decision

It has been decided to put the run program function in its own plugin because it is a very basic function and should be available even if the debugger plugin is not loaded.

Proposals

The debug manager could implement the run program function and just have a check box to run the program with or without the debugger.

Start [Done]

The run program without the debugger is implemented in the auto tool build plugin and is in the Build menu. While the run program with the debugger is implemented in the debug manager plugin and is in the Debugger menu.

Both plugins display a similar to get the program name and various arguments.

Up to date check

Improvements

Implementation

None

Decision

We will add a new function to do this in IAnjutaBuildable interface. But as the other items will probably need some changes in this interface, we wait to get decision for all of them before doing this.

Proposals

We can use make -q to check if a target is up to date without building it. If it is not up to date, the next action will probably be to build it taking more time than just trying to build it in any case. But make -q is much faster than make alone, so the target is up to date it is faster to use such function. We can expect that most of the time, the target is up to date so this make sense.

Start

It's not possible. The only way to be sure that the target is up to date is to build it.

End of build notification

Improvements

Implementation

None

Decision

None

Proposals

There are several choices here. I have still not decided yet.

  1. Just add a callback function and an user data parameters to each asynchronous command. When the command is finished the callback function is called with the corresponding user data and some additional arguments (the error code returned by example).
    • + It is simple with few overhead.
      - You cannot unload the callback function nor free the user data until the command is finished.
      - You cannot cancel the command.

  2. You add only an user data parameter to each asynchronous command and you connect on a "exited" signal (on the plugin providing this command by example). When the command is finished the signal is emitted with the corresponding user data and some additional arguments. The signal handler need to check that the user data corresponds to the right command (it must be unique, a pointer on some user variables by example).
    • + Not much overhead.
      + It could be possible to cancel a command using as argument the user data which is unique.
      + You can unregister the signal if needed.
      - The user data must be unique.

    2.1. One variant of the previous idea. Instead of passing to the asynchronous command an user data parameter, it is possible to pass a GQuark. Then the signal will be emitted with this GQuark as detail argument. So only the corresponding handler will be called, the handler don't need to check anything.
    • + Same advantage than solution 2
      + making a GQuark unique is more obvious, you can pass 0 if you don't care.
      It seems the best solution for me.

  3. The asynchronous command returns a unique identifier and you connect on a "exited" signal. When the command is finished the signal is emitted with several arguments including the unique id. The signal handler need to check if the id corresponds.
    • + Not much overhead.
      + It could be possible to cancel a command using as argument the user data which is unique.
      + You can unregister the signal if needed.
      + It's working like this in the terminal plugin currently.
      - It could be possible that the signal is emitted before the caller get back the id. I think it's possible to handle this inside the command by re-emitting the signal in the main loop but it's not very nice.

  4. The asynchronous command does not start the command but creates a command object implementing a IAnjutaCommand interface. The caller connects on a "exited" signal of this object then calls the run function of IAnjutaCommand interface.
    • + The command can be canceled easily using a cancel function of the IAnjutaCommand interface.
      + The signal is provided directly by the command object, the handler is called only when needed.
      + You can destroy the object when not needed. The object should probably destroyed it itself when the command is finished. So, if the notification is not needed, the caller can just call the run function.
      - There is more overhead, each command needs to allocate a new GObject.
      - Make running a command a bit less obvious, you need to call compile (by example) and then run on the returned object.

    4.1 Instead of using an IAnjutaCommand interface, we can use a GObject class an override the run function. The already existing AnjutaCommand is very close but probably needs a few changes.

    4.2 As I say in the introduction, this problem (asynchronous command) is quite common in Anjuta. It will be useful to try to reuse the same solution as much as possible. By example AnjutaLauncher could derive from AnjutaCommand, the terminal or even the debugger plugin could use such interface too. Anyway, this will need a lots of changes, I don't think it's useful to change all this now, and we could find some unexpected problem with this approach but it could be a goal (like replacing gnome-vfs by gio).

Start

It's not possible to know when a build command is finished. It's not a problem when the build command is fired and forget. But it is a problem if the build command is triggered by the debugger plugin which need to start the debug only when the build is completed.

Debug configuration

Improvements

Implementation

None

Decision

None

Proposals

I think gnome build doesn't need any change, everything is using id which doesn't need to correspond to real file name.

I need to change IAnjutaProjectManager which is taking care of converting gnome build id into real uri.

I think I can add the following:

  • gboolean ianjuta_project_manager_set_build_directory (IAnjutaProjectManager *obj, const gchar *directory, GError **err);
  • const gchar * ianjuta_project_manager_get_build_directory (IAnjutaProjectManager *obj, GError **err);

I think this one is not necessary, I can use a anjuta shell variable "project_build_uri" like the already existing "project_root_uri". This value will be saved in anjuta session file.

  • GList * ianjuta_project_manager_list_build_directories (IAnjutaProjectManager *obj, GError **err);

This one could be useful but is a bit difficult to implement especially because as we use gnome-build. The project manager doesn't know how a build directory look like, so in order to implement this correctly we need to add some support in gnome build. By example a function checking if a directory could be a build directory.

Then, the build plugin will need a few change in order to take care of the "project_build_uri". I think only a few commands need changes like compile on the other hand build should work just fine.

Start

It is possible to build anjuta outside the source tree, just by creating a build directory and running configure from here. So autotool support this without trouble but then Anjuta is not able to find the targets.

Build single file

Improvements

Implementation

None

Decision

None

Proposals

If a file is opened in Anjuta which does not contain a Makefile/Makefile.am in the build directory associated with it, then also user must be able to compile it. When user chooses the "Build->Compile" option then :

  • He should be prompted with a dialog giving him different choices for compilation.
  • Program should be able to gather metadata of the different programming languages supported (C, C++, Vala, Python, Javascript) and compile the file according to the choice of the user.
  • The dialog for selecting compilation option should have a "don't ask me again" option and this option should be editable in the preferences.
  • Pressing OK should build the file according to the rules given.
  • There should also be an "Execute" feature which would launch the scripting engines for Python and Javascript where no compilation is required.

I think, it should be done using the new IAnjutaBuildable interface. It shouldn't be very difficult, will fulfill a common user request and will allow to check that the new interface could adapt to different build system.

Start

It is possible only if you have a make file (you don't need auto tool though). Then, it is possible to call the compiler using the tool plugin but in this case you don't have the parsing of the error messages. This has been requested several time by different users.

Adapt build system

Improvements

Implementation

None

Decision

None

Proposals

The solution used by maemo plugin is currently better. But, the problem is that such environment needs to tune sevral plugins. Now, the run plugin will probably need to be tuned and anyway the debugger plugin probably need something. I think it will be better to do it in the other way. I mean all plugin running command (build, run and debugger by example) know that they could have to tune a bit their command lines and check if a environment plugin is loaded. If yes, they can send their command to this plugin and get back a modified version that should work. Instead of using an interface, a scratchbox or maemo plugin could define some shell value in anjuta (by example run_program_prefix) to defined how to modified the command line. Then the build plugin could check these variables and adapt all its command line.

Start

The autotool stuff is already in one plugin the basic auto tool plugin which is loaded automatically by the project manager plugin based on the project kind. The support of scratchbox is done directly in this auto tool plugin. The maemo plugin use the ianjuta_buildable_set_command to overide the various commands.

Apps/Anjuta/Roadmap/BuildSystemCleanUp (last edited 2013-11-26 17:20:31 by WilliamJonMcCann)