Support `dist`

[ignatenkobrain]

In #823 there is some work to make meson executable like one file. After all it would be nice to have target which will bundle current meson to the zip app, run all generators and make archive with all that stuff.

In the beginning I was thinking that it's completely useless, but advantages are (for some cases):

• No need to have meson installed (and have it with some updated version), only python
• No need to have generators installed (like swig, cython), it will be prepared during dist

This will require some work, but will be nice to have.

[arteymix]

The only flaw I see is the lack of a portable backend for compiling the code. Otherwise, I think it's fair to expect the user to have its own Ninja or Visual Studio pre-installed.

As a plus for Vala, you could dist the C sources and get rid of that dependency.

[ignatenkobrain]

As a plus for Vala, you could dist the C sources and get rid of that dependency.

But I want definitely to distribute original sources (and if generators available to regenerate prebuilt srcs).

[jpakkane]

As a plus for Vala, you could dist the C sources and get rid of that dependency.

This has been proposed a few times, and the answer is always no. It complexifies things a lot for no real gain. Installing a compiler is either trivial or very easy. Meson only works from source, it will not ship intermediate files.

[TingPing]

Installing a compiler is either trivial or very easy.

Well, in theory. Vala has multiple incompatible versions though and on occasion old versions are broken. If you generate the C with the modern known good version it can compile basically anywhere and behave as expected.

[arteymix]

What we need is not really a dist facility (although it could be a handy target), but more a manner of generating files into the source tree.

If we can do that conveniently, then we just need to check for the availability of the required tools to regenerate them and commit them into the project. Vala does this to ship bindings with vapigen .

In the case of Igor, having an option for targets to generate output back into sources would do the job:

if swig.found()
    # generate from scratch
    custom_target('swig', command: [swig, ...] input: [...], output: [...], 
                  dist: true) # or any other name
else
    # reuse existing bindings
endif

Other use cases would be to generate stuff that require a very occult (maybe non-free or non-portable) tool.

This way we preserve the build-from-source approach with the possibility of pre-generating specific sources with Meson. No target necessary, just annotate what is going back into sources.

Vala is a bad example because it's built into Meson: the change would be really difficult to introduce. However, I would really like to see a way to generate the C sources along and ship everything together in releases. If you have to compiler, nice, otherwise GCC suffice.

[TingPing]

Another point in favor: https://blogs.gnome.org/despinosa/2016/10/10/vala-and-reproducibility/

[jpakkane]

A quick experiment on how to create tarballs with custom actions is here. It roughly does the following:

• create a fresh git checkout to a new dir, delete Git files
• copy extra files into the checkout
• delete specified files from the checkout
• run specified custom scripts
• package the result into zip + tar.xz

[nacho]

A very reasonable case here would be to support Windows builds. You usually want to build the gtk stack once, store those binaries somewhere i.e on s3 and use them on your repo to build your project. Clearly you do not want to include those binaries directly on your git repository otherwise the repository will explode in size and we also know well that git is not the best at handling binary files.

Instead once you generate the final tarball you want the tarball to include those binaries, since the final user of the tarball might not have permission to access the binary storage. For this I propose a way to add files to the final tarball i.e something like git archive + some files.

[TingPing]

@nacho That sounds a bit beyond the scope of this, it sounds like you want packaging for final releases while this is about distributing source.

[jpakkane]

From this issue.

As requested, here is what we currently do with autotools in Nautilus:
pack the code (included submodules) into a tar with the project version in configure/meson.build
extract the tar and build
execute tests
And I think that's it. Our current simple script for packing the code is https://git.gnome.org/browse/nautilus/tree/make_release.sh
for packing submodules there is also https://github.com/meitar/git-archive-all.sh but it's GPL3 and we are GPL2, so we cannot use it.