ninja/meson

[dhewg]

This adds ninja/meson as host as well as target packages.

ninja.mk/meson.mk are provided for packages to use these tools, see the comments there how to use it.

libmpdclient/mpc are switched over from the gross autotools hack to meson. No further changes, but this should unblock updating the packages as well as sound/mpd.

Tested on boneblack and cubieboard2 (where one meson cross file is created per target in the host staging dir).

not tested:

• c++ lib != libstdcpp done, ninja can only be built against libstdcpp
• meson builds where native tools are built and executed during the build most likely done, added support for host packages, which uses the same config

not done:

• ccache done, works

cc:
@br101 @ja-pa (earlier attempts openwrt/openwrt#2147 openwrt/openwrt#2312
@ynezz (handling the earlier attempts)
@diizzyy (using ninja with cmake)
@tstenner @lucize @flyn-org @neilwhelchel (building packages using meson)
@thess (libmpdclient/mpc/mpd maintainer)

[dhewg]

edit: resolved, issue was related to uclibc++.mk and TARGET_CXX_NOCACHE, but as it turns out, ninja can't be built against uClibc++

I'm unsure where the build failure comes from:

Package ninja is missing dependencies for the following libraries:
libstdc++.so.6

Seems to work on my end?

define Package/ninja
  ...
  DEPENDS:=$(CXX_DEPENDS)
endef

$ opkg info ninja
Package: ninja
Version: 1.9.0-1
Depends: libc, libstdcpp6
Status: install user installed
Architecture: arm_cortex-a7_neon-vfpv4
Installed-Time: 1569016828

[hnyman]

cc @thess who is the maintainer of the packages you propose to switch for meson build system introduced by this PR.

[ja-pa]

I feel that a better way would be to introduce switch to meson in separate PR.

[neheb]

I doubt uClibc++ can be used here. It's a C++98 library. C++11 or later is probably what's used.

[thess]

@ja-pa - agree. Adding/updating packages to use Ninja/Meson needs to be done separately.

@hnyman - Will be investigating mpd,etc. this week.

Any reason why Ninja/Meson devel tools shouldn't be either:
a) Host build system requirement and/or
b) Part of toolchain/SDK ala cmake.

[hnyman]

Any reason why Ninja/Meson devel tools shouldn't be either:
a) Host build system requirement and/or
b) Part of toolchain/SDK ala cmake.

scons was just recently removed from host tools and moved to packages feed by 7087efd and openwrt/openwrt@60eb0e8 authored by @ynezz , so I think that devs have differing opinions on the approach regarding additional build tools ...

[dhewg]

updated:

• update meson to 0.51.2
• use meson's "native file" feature for host builds to shorten cmdlines
• move libmpdclient/mpc commits to libmpdclient/mpc/mpd: update and build with meson #10052

[neheb]

I'm fairly confused on the issue of _HOST vs. _HOSTPKG. On IRC I've been told something equivalent to "_HOST should be used by packages in the tools/ directory".

If we look at this tree, including this PR, we get

git grep STAGING_DIR_HOST\) | wc -l
15

while _HOSTPKG has this:

git grep STAGING_DIR_HOSTPKG\) | wc -l
110

edit: From looking at the packages, softethervpn, iotivity, and *odbc are most likely in the wrong. No comment on the others.

[dhewg]

I got the a similar response on irc.

updated:

• switched to STAGING_DIR_HOSTPKG

[neheb]

ping @jow-

[dhewg]

updated:

• fix including ninja.mk from meson.mk if the package subdir depth != 2 (use MAKEFILE_LIST instead of CURDIR)
• add support for building host packages using meson (proper uninstall from hostpkg requires this patch https://patchwork.ozlabs.org/patch/1168833/ though, but it's doesn't break without it)

host builds were tested with 0001-XXX-meson-host-test.patch.txt

@thess did you give this a try yet?

[dhewg]

updated:

• create native/cross files for each package in [Host|Build]/Configure, as they may need to modify compiler flags (as e.g. nls.mk does)

[dhewg]

Here's a tree that includes #10043 #10113 and above mentioned host build test patch.
https://github.com/dhewg/packages/tree/meson

[thess]

I'm sorry I haven't paid enough attention these proposed changes. I am probably not going to have a chance to try/verify/review these packages in the near future. In fact, if someone else wants to take over maintainer-ship of MPD and friends, I have no objections. As it stands for the foreseeable future, my attention to these packages will be minimal if at all.

Dealing with packages requiring little used (at least here) build tools needs to be addressed so that packages like MPD can more forward without us having to maintain alternative builds (eg autotools). So... whatever you guys decide if fine with me.

[dhewg]

Oh... well, if noone steps forward I guess I can take over mpd related packages for a while.

How to we proceed with this MR? I'm happy with it, the foundation is there and it works nicely for me for #10052. For other packages we may need more features, but that can be dealt with as issues pop up.

Another candidate to test drive this glib2, since v2.59.0 is the last version supporting autotools. @tripolar did you try this yet to build newer versions using meson?

[neheb]

AFAIK the odd glib releases are unstable ones.

[dhewg]

updated:

• meson v0.52.0

[flyn-org]

I can update libsoup, grilo, and grilo-plugins once there exists an example of "porting" a package to use the project's Meson-based build.

@neheb, glib2 2.59 is indeed a development version, but the subsequent 2.60 and 2.62 series also use Meson.

[dhewg]

@flyn-org have a look at devel/meson/meson.mk from this MR: .84d7a51#diff-398d125edadb8ea15ae979ed80f5258e
There're also a few packages I ported in this tree https://github.com/dhewg/packages/commits/meson

[neheb]

Actually...why does the target build depend on the host build?

[dhewg]

Actually...why does the target build depend on the host build?

Ninja is built using itself. It has a --bootstrap option to build a minimal version of itself which then builds the final binary. This is what the host built does. The target build then uses the host binary to cross compile for the target without the bootstrap option.

[dhewg]

Edit: wrong issue, idiotic github login redirected to the wrong one

[neheb]

codeload should not be used directly. The normal release tarball listed under releases is preferred.

[dhewg]

Ok, I switched meson to that, but the ninja releases are different it seems. The link on the github releases redirects to codeload (curl "https://github.com/ninja-build/ninja/archive/v1.9.0.tar.gz"|xxd) and that fails to download, so I kept codeload there.

[neheb]

That seems bizarre. Note that https://github.com/ninja-build/ninja/archive/v1.9.0/ninja-1.9.0.tar.gz works. Well, it redirects to that codeload link. I'd just leave it.

[neheb]

Let's just get this in here. No point in delaying.

[dhewg]

Nice, thanks!

[flyn-org]

Fantastic! This allows us to update a number of packages in OpenWrt that have been awaiting Meson, e.g., #10433.

Thank you to everyone involved, especially @dhewg and also @br101 and @ja-pa for their earlier work. Discussion and work continued for over a year---I am grateful for the persistence displayed to get this done.

[dangowrt]

Somehow CMake is not detected by Meson when trying to build libinput-1.14.3 :(

CMake binary for MachineChoice.HOST is not cached
CMake binary missing from cross or native file, or env var undefined.
Found CMake: NO
No CMake binary for machine MachineChoice.HOST not found. Giving up.

[dhewg]

What do you need cmake for? As far as I understand, it's used as a fallback if a dependency is not found via pkg-config. Does libinput have a dependency without pkg-config support?

[BKPepe]

What about to add it to openwrt-19.07 branch?

[neheb]

No opposition from me. That being said, nothing in 19.07 requires it currently.

In other news, I opened up an issue regarding uClibc++: ninja-build/ninja#1684

It's only the hash map feature that's the problem.