Skip to content

Quick Start

Egor Pugin edited this page Feb 5, 2019 · 17 revisions

Package Management

SW uses packages paths to uniquely identify projects on the web. Project path is similar to Java packages. Version is appended to it.

It contains:

  1. Namespace: org
  2. User name: username
  3. Path to target:

Allowed namespaces are:

  • org - organization's public projects with open (free) software license.
  • com - organization's projects with commercial license.
  • pub - user's public projects.
  • pvt - user's private projects.

version - is a semver-like version.

Build process

SW uses configuration files to describe build process (Build).

Build contains several solutions (Solution). Each Solution is responsible for exactly one configuration. For example, x86+dll+Release or arm64+static+Debug (plus sign is used only for this document).

Solution consists of targets, projects and directories. Each object might include any other object.

SW uses multipass approach if it needs to build more than one solution. (Unlike CMake that is telled which options go to what configuration during single pass.)

It is possible to use different frontends to describe build. Main frontend is called sw as well as the program and uses C++ code directly. Current secondary frontend is cppan YAML frontend used in first version of the program.



HINT: run sw create project to force sw to create first config and generate an IDE project for you.

To start your first build configuration, create a file called sw.cpp.

// this is our 'main' build function signature
// function accepts current Solution
void build(Solution &s)
    // add non copyable target to Solution of type Executable with name 'mytarget'
    auto &t = s.addTarget<Executable>("mytarget");
    t += "src/main.cpp"; // add our first source file
    // t += "dependency.path"_dep; // add needed dependency

SW uses the latest current standard available - C++17.

To control your build (add definitions, dependencies, link libraries) sw uses user-defined literals. For more help on this, see Examples:

t += "MY_DEFINITION"_def;
t += "ws2_32.lib"_lib;
t += "src"_idir;

Now create src/main.cpp file with contents you want.

Run sw build to perform build or sw generate to generate IDE project.


To provide control on properies visibility, one might use following target members:

t.Private += ...; // equals to t += ...;
t.Protected += ...; // available only for this target and current project members
t.Public += ...; // available for this target and all downstream users
t.Inheritance += ...; // available only for all downstream users

Underlying implementation uses three bits to describe inheritance.

  • 1 - This target T
  • 2 - This project P (excluding T)
  • 3 - All other projects A (excluding P and T)

This gives 7 different inheritance modes (excluding 000) and you could use them all!

More than one configuration

To create additional configs you might add them on command line or write into configuration. Add following code to your sw.cpp:

// configure signature
// Note that it accepts whole build, not a single solution!
void configure(Build &b)
    auto &s1 = b.addSolution(); // add first solution
    s1.Settings.Native.LibrariesType = LibraryType::Static;
    s1.Settings.Native.ConfigurationType = ConfigurationType::ReleaseWithDebugInformation;

    auto &s2 = b.addSolution(); // add first solution
    s2.Settings.Native.LibrariesType = LibraryType::Shared;
    s2.Settings.Native.ConfigurationType = ConfigurationType::Debug;


    // following code can be used for advanced toolchain configuration
    if (b.isConfigSelected("cygwin2macos"))
        b.loadModule("utils/cc/cygwin2macos.cpp").call<void(Solution&)>("configure", b);
    else if (b.isConfigSelected("win2macos"))
        b.loadModule("utils/cc/win2macos.cpp").call<void(Solution&)>("configure", b);

In this function you could provide full custom toolchain to use (compilers, linkers, librarians etc.). Extended configs can be found here:


You can’t perform that action at this time.