Meta Projects

Problem

Working on projects with complex dependencies currently requires that the dependencies are in their final-form. This doesn't work well when you need to work on the dependencies too. For example, working on the Pitivi video editor also requires working on gstreamer components. Testing those components without an application is difficult.

Additionally, some of us working on upstream GNOME applications need to fix bugs in Gtk or GLib too. It would be convenient if we could do this as part of our normal development workflows and graft the dependencies together.

What prevents this currently is that our flatpak-builder pipeline is one-directional. You can only build dependencies up to the source module that is checked out for the user's project. This prevents having modules that build after your project (such as plugins, font packages, etc) as well as changing the contents of a dependent module.

Changing this pipeline will make things complex in terms of knowing which and when to rebuild modules.

We will need project systems to provide information about dependencies and that may come from different layers. For example, Flatpak dependencies may be defined from a manifest. Meson projects also contain information about dependencies (which may not be linked to the flatpak dependencies). Furthermore, git submodules themselves could be considered dependencies.

We probably want to model projects/metaprojects/subprojects within the project tree.

Goals

  1. Add support for projects of projects. Some IDEs call this a "Solution".
  2. Allow opening a sub-project in a new workbench but compile into shared location.
  3. Allow building projects that come after the primary project in flatpak manifest (such as plugins)
  4. Allow some control over dependencies (adding/removing)

Anti-Goals

  1. Avoid subprojects of subprojects

Affected Modules

  1. libide-projects
  2. libide-code
  3. libide-gui
  4. libide-terminal
  5. libide-foundry
  6. A project-tree IdeTreeAddin will need to be added (possibly in new projectui plugin)

  7. Many plugins, depending on the API changes

Interfaces

  1. Plugins need to be consulted on the available subprojects. So we need an interface that describes the meta-project hierarchy. IdeSubprojectProvider might be a good name suggestion. We might also want to limit this to a depth of 1 (ie: only one layer of subprojects, not subprojects of subprojects).

  2. Getting the build flags for a file may require consulting subprojects. We'll need a way to get the project which owns a particular file. Additionally a new build flags provider will probably be necessary (and remove it from IdeBuildSystem).

Risks

Implementation Details

Prior Art

Comments

Apps/Builder/ThreePointThirtyfive/MetaProjects (last edited 2019-09-19 01:38:45 by ChristianHergert)