Bug#712610: RFS: meson/0.4.1-22-gea3e8f1-1 [ITP]

On Thu, Jun 20, 2013 at 12:43 AM, Jakub Wilk <jwilk@debian.org> wrote:

Thanks for your comments. I have uploaded a new version to mentors.

How was .orig.tar generated? There's neither get-orig-source target nor README.source that would explain it...

Is there a reason you based the Debian package on a VCS snapshot instead of a released version?

I'm also the upstream developer. The tar.gz is just a tarball of the Git commit listed. After the release of 0.4.1 I started working on improving the code to be suitable for distro inclusion. The goal is to commit all source changes to trunk immediately and keep as few quilt patches as possible. When all raised issues have been fixed, I'll create a new release (probably 0.5.0) and then base the final package on that.

What does "high-productivity" in the package description mean?

Meson aims to:

- be fast (no-op build time for 10 000 files less than 1 second)

- be simple and easy to use

- provide native support for modern features and tools

As an example, let's look at coverage reports. Getting them working in CMake or autotools usually involves finding a third party script file and adding it as part of your build steps. Since different packages use different scripts, there is no consistency and the steps needed may be completely different.

To get coverage reports in Meson, you just say "enable coverage" when first configuring your source and then run the coverage target (which always has the same name). No code needs to be written or copypasted to make it work. Meson tries to give the developers the tools they need and then get out of their way as much as possible.

d/copyright should refer to the /usr/share/common-licenses/Apache-2.0 file; see Policy §12.5.

Fixed.

The package FTBFS if built twice in a row:
| dpkg-source -b meson-0.4.1-22-gea3e8f1
| dpkg-source: info: using source format `3.0 (quilt)'
| dpkg-source: info: building meson using existing ./meson_0.4.1-22-gea3e8f1.orig.tar.gz
| dpkg-source: error: cannot represent change to work area/.ninja_deps: binary file contents changed

This is due to the fact that unstable has a newer version of Ninja. The older version I have been using does not create this file. Fixed.

Please honour DEB_BUILD_OPTIONS=nocheck; see Policy §4.9.1.

Fixed.

Python modules should be byte-compiled. You probably want to use dh_python3 for this purpose.

I tried to make this work, but failed. No matter how I invoke dh_python3 it just won't create the bytecode files. Maybe an issue with paths?

You should depend on python3-ply.yacc-X.Y, where X.Y is tabversion from you parsetab.py. Unfortunately there's no tool to generate this dependency automatically. (Such tool would be trivial to implement, because there is already dh_python-ply for Python 2.)

I did not do anything to this yet, since it is unclear what the best solution would be.

"-tt" is a no-op in Python 3.

Removed, thanks.

'wrapper to run tests with (e.g. valgrind' - an unmatched left parenthesis creates an unresolved tension that will stay with you all day.

Fixed.

The manual page is not very helpful.

It has now been expanded.

symbolextractor should probably gain support for kFreeBSD and Hurd.

On platforms which symbolextractor does not handle, Meson falls back to the default behavior, which is always relinking. I don't know how this functionality should be implemented on those platforms, but if someone tells me I'll be glad to add it.

Do I understand correctly that meson will always use ccache if it is installed? That sounds like a bad design.

It's a bit more complex than that:

- if the user specifies a compiler (i.e. with CC/CXX envvar) then Meson won't wrap it with CCache

- the the user does not specify a compiler and CCache is installed, it is used

get_library_dirs() is broken on most Debian architectures. It's also broken if the compiler's architecture is not native.

Yes, but in my defense there's a comment stating that it is probably broken. ;-)

I really don't know what is the correct cross-architecture, cross-distro way to do this. At the moment Meson only supports native builds, cross compilation support will be added in the future.

Lintian emits:

I: meson source: quilt-patch-missing-description explicit33.patch
I: meson source: quilt-patch-missing-description noqt5.patch
I: meson source: debian-watch-file-is-missing
P: meson: no-homepage-field

Fixed.

E: meson: python-script-but-no-python-dep usr/share/meson-0.5.0-research/backends.py
...
E: meson: python-script-but-no-python-dep usr/share/meson-0.5.0-research/symbolextractor.py

(I suppose python-script-but-no-python-dep is emitted because of "#!/usr/bin/env python3" shebang without "python3" dependency.)

If so, then this should fix itself once Python 3.3 becomes the default.

Thanks,