[ENHANCEMENT] cmake - add options for selecting what projects to build

[ethindp]

Add options for selecting what projects to build

Library

None

Enhancement

CMake options

Description

It would be nice to add options to pick which projects we want. For example, I might only need xtd.core but I might have my own drawing/forms/testing framework. Right now, I have no choice but to build everything.

[gammasoft71]

Hi @ethindp,

First of all, thank you for your interest in xtd.

Your request is perfectly legitimate and has already been considered in the past. In fact, early versions of xtd did provide options to selectively build certain projects. However, this approach was eventually removed after real-world usage revealed several structural issues.

Although xtd libraries do not have cyclic dependencies and each one has a clearly defined responsibility, they are not independent modules. xtd is designed as a layered framework, where higher-level components rely on lower-level ones in a strict hierarchy:

• xtd.core.native : No dependency
• xtd.drawing.native : Depends on xtd.core.native
• xtd.forms.native : Depends on xtd.drawing.native
• xtd.core.native.{x} : Depends on xtd.core.native
• xtd.drawing.native.{y} : Depends on xtd.drawing.native
• xtd.forms.native.{y} : Depends on xtd.forms.native
• xtd.core : Depends on xtd.core.native and xtd.core.native.{x}
• xtd.drawing : Depends on xtd.core, xtd.drawing.native and xtd.drawing.native.{y}
• xtd.forms : Depends on xtd.drawing, xtd.forms.native and xtd.forms.native.{y}
• xtd.tunit : Depends on xtd.core

See the xtd libraries hierarchy for more information.

The complexity increases further when considering unit tests:

• xtd.core.unit_tests : Depends on xtd.core and xtd.core.tunit
• xtd.drawing.unit_tests : Depends on xtd.drawing and xtd.core.tunit
• xtd.forms.unit_tests : Depends on xtd.forms and xtd.core.tunit
• xtd.tunit.unit_tests : Depends on xtd.core.tunit

And even more so with xtd tools:

• demangler : Depends on xtd.core
• guidgen : Depends on xtd.core
• guidgen-gui : Depends on xtd.forms
• keycodes : Depends on xtd.forms
• set_environment_variable : Depends on xtd.core
• set_path : Depends on xtd.core
• sleepfor : Depends on xtd.core
• xtdc : Depends on xtd.core
• xtdc-gui : Depends on xtd.forms

Allowing arbitrary selection of projects to build quickly leads to:

• invalid or unsupported build combinations,
• fragile and hard-to-maintain CMake logic,
• partial installations with missing runtime resources,
• and increased maintenance and support burden.

For these reasons, xtd currently favors a consistent and coherent build model rather than fine-grained project selection.

That said, the idea is not dismissed outright. Any future solution would need to be carefully designed (for example, using well-defined build profiles rather than per-project switches) to preserve the integrity of the framework and its installation process.

Regards,
Gammasoft

[gammasoft71]

As a possible compromise, one approach that could be explored in the future would be the use of well-defined build profiles instead of per-project switches, for example:

• XTD_BUILD_PROFILE=core
  Builds xtd.core, required native layers, and core-related tools.

• XTD_BUILD_PROFILE=drawing
  Builds xtd.core and xtd.drawing (core is implicitly required).

• XTD_BUILD_PROFILE=full (default)
  Builds the complete xtd framework.

This kind of profile-based configuration would avoid invalid build combinations and keep the dependency graph, tests, tools, and installation process consistent.

[ethindp]

Hi there,

The reason I suggested this is because it would be nice if I could only depend on xtd.core for instance, should I not need xtd.drawing or xtd.forms or anything else we decide to add in future.

[gammasoft71]

I understand your request and that is why the only viable solution will be to do it in the form of a profile as defined above 😄.
Thank you for your request.