Meson, a new build system experiment using Ninja

[Jussi Pakkanen]

Hello

I have created a research experiment to examine what an optimal high level build system should be like. Since one of the hard requirements was speed, I naturally used Ninja as the backend.

The project is called Meson and it is located here: https://sourceforge.net/p/meson/

The system is not production ready yet, but here's what it can already do:

- extremely simple and expressive syntax using a DSL
- supports C and C++
- build executables and libraries, both shared and static
- shared library versioning
- Unix-type install with support for staged installs
- native support for precompiled headers, a first in general purpose free software build systems (that I know of, at least)
- config.h file generation
- supports external dependencies transparently using pkg-config
- no dependencies on unix internals or command line tools

- integrated unit testing system

I had not looked at Ninja's syntax until after I started working on the backend. It turned out to be quite a good match for the high level overview I had in Meson so writing the backend was straightforward. Thanks for all the hard work you have put into it.

[Elazar Leibovich]

Can you give a quick explanation how is meson different from gyp? Both seems similar in goals.

--
You received this message because you are subscribed to the Google Groups "ninja-build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Konstantin Tokarev]

19.02.2013, 03:30, "Jussi Pakkanen" <jpak...@gmail.com>:

> Hello
> I have created a research experiment to examine what an optimal high level build system should be like. Since one of the hard requirements was speed, I naturally used Ninja as the backend.
>

> The project is called Meson and it is located here:О©╫https://sourceforge.net/p/meson/

>
> The system is not production ready yet, but here's what it can already do:
>
> - extremely simple and expressive syntax using a DSL
> - supports C and C++
> - build executables and libraries, both shared and static
> - shared library versioning
> - Unix-type install with support for staged installs
> - native support for precompiled headers, a first in general purpose free software build systems (that I know of, at least)
> - config.h file generation
> - supports external dependencies transparently using pkg-config
> - no dependencies on unix internals or command line tools
> - integrated unit testing system
>
> I had not looked at Ninja's syntax until after I started working on the backend. It turned out to be quite a good match for the high level overview I had in Meson so writing the backend was straightforward. Thanks for all the hard work you have put into it.

Have you tried to use Premake[1]? It already supports everything you mention, except for unit testing, pkg-config and config.h (it is not difficult to add them, though), and is easily extensible by user with Lua code. This branch [2] has Ninja support. Also, there is Qt integration in works [3]

[1] http://industriousone.com/premake
[2] https://github.com/rgeary1/premake-dev-rgeary
[3] http://industriousone.com/topic/full-stack-qt-based-development-premake-available-download


--
Regards,
Konstantin

[Jussi Pakkanen]

tiistai, 19. helmikuuta 2013 4.19.05 UTC+2 Elazar Leibovich kirjoitti:

 

Can you give a quick explanation how is meson different from gyp? Both seems similar in goals.

 

Their goals are roughly similar, yes. However Gyp's web page has this in their overview description:

"Make the input format as reasonably general as possible without spending extra time trying to "get everything right," except where not doing so would likely lead Chromium to an eventual dead end. When in doubt, do what Chromium needs and don't worry about generalizing the solution."

In contrast, Meson's goal is specifically to "do it right". It should be a general purpose build system and not something tied to a single project.

[Jussi Pakkanen]

tiistai, 19. helmikuuta 2013 9.55.08 UTC+2 Konstantin Tokarev kirjoitti:

Have you tried to use Premake[1]? It already supports everything you mention, except for unit testing, pkg-config and config.h (it is not difficult to add them, though), and is easily extensible by user with Lua code. This branch [2] has Ninja support. Also, there is Qt integration in works [3]

I have looked at it. It seems very nice but it has the same slightly problematic design choice as SCons: it exposes an entire programming language in its definition. This makes it extremely hard to ensure everything is working reliably. As an example, Meson enforces that the build definition objects the user creates are immutable. This allows it to do optimizations it otherwise could not. If they were Python or Lua objects, this would be impossible, because users could change them after the fact.

The difference between the two approaches is actually very similar to the difference between Ninja and Make. Ninja's syntax is very simple to avoid complexity and gain speed. Meson's syntax is very simple to avoid complexity and gain robustness.

[Konstantin Tokarev]

19.02.2013, 12:31, "Jussi Pakkanen" <jpak...@gmail.com>:

> tiistai, 19. helmikuuta 2013 9.55.08 UTC+2 Konstantin Tokarev kirjoitti:
>> Have you tried to use Premake[1]? It already supports everything you mention, except for unit testing, pkg-config and config.h (it is not difficult to add them, though), and is easily extensible by user with Lua code. This branch [2] has Ninja support. Also, there is Qt integration in works [3]
>
> I have looked at it. It seems very nice but it has the same slightly problematic design choice as SCons: it exposes an entire programming language in its definition.

I think it's more like an advantage than an issue: if user needs to do something non-trivial (read: something that authour of build system didn't think about), he just does what he needs in the most staraightforward way using built-in general-purpose language and having access to all build system internals (e.g., get list of declared targets and their properties and do something with them). With "pure declarative" approach it can easily turn into mess, and you end up with shell scripts doing necessary work.

> This makes it extremely hard to ensure everything is working reliably. As an example, Meson enforces that the build definition objects the user creates are immutable. This allows it to do optimizations it otherwise could not. If they were Python or Lua objects, this would be impossible, because users could change them after the fact.
>
> The difference between the two approaches is actually very similar to the difference between Ninja and Make. Ninja's syntax is very simple to avoid complexity and gain speed. Meson's syntax is very simple to avoid complexity and gain robustness.

Difference is that Ninja is not an end-user tool, so it does not need to be convenient.


--
Regards,
Konstantin

[Richard Geary]

> I think it's more like an advantage than an issue: if user needs to do something non-trivial (read: something that authour of build system didn't think about)

I second that. The vast variety I've seen in build configurations & users' build requirements is amazing. IMO, the build system & build graph needs to react & interact with other tools & the operating environment. I can't predict everything they'll need, so a full scripting language is the best option. I want the users to write their scripts in a simple, readable, OS independent language like Lua, not bash scripts.

Ninja makes a fantastic pairing with Premake, it's been a big success at my firm. Thanks to everyone who has contributed to it!

--
Regards,
Konstantin