-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support dist
#877
Comments
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. |
But I want definitely to distribute original sources (and if generators available to regenerate prebuilt srcs). |
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. |
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. |
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 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. |
Another point in favor: https://blogs.gnome.org/despinosa/2016/10/10/vala-and-reproducibility/ |
A quick experiment on how to create tarballs with custom actions is here. It roughly does the following:
|
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. |
@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. |
From this issue.
|
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):
This will require some work, but will be nice to have.
The text was updated successfully, but these errors were encountered: