Hello, I recently developed an interest on porting this project to the FreeBSD tree, however the repository does not have any stable releases I can use to download tarballs from. I suggest if possible creating an stable release following semantic versioning, to ease porting efforts where cloning the latest commit is not viable.
Thank you,
Daniel.
On 10/30/21 8:16 AM, Daniel Pérez wrote:
> Hello, I recently developed an interest on porting this project to> the FreeBSD tree, however the repository does not have any stable> releases I can use to download tarballs from. I suggest if possible> creating an stable release following semantic versioning, to ease> porting efforts where cloning the latest commit is not viable.
As a matter of curiosity, what do you want to use it for? I would be
hesitant to call muon stable, since among various other TODO topics is
adding an installation functionality.
That's something fairly central to the goal of reimplementing and
providing an alternative to the reference meson.
I would expect ~lattis to wait until at least then to tag a stable
release, since that would be the point when muon can first achieve the
status of completely replacing meson as the build tool (for at least
some projects).
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
Muon certainly is not stable yet, but it can be useful. Actually, muon
already fully implements all of what I *personally* used meson for
(building a few personal projects). I think that muon could definitely
be packaged/released before it is 100% feature complete with meson
(which probably will never happen anyway), but I'm not sure it is at
that stage yet.
Something I'm not sure about is how to determine when muon is at the
release stage. Perhaps being able to install projects is a good
milestone. I would personally also like to see all applicable tests
from meson's `test cases/common` pass. I'm worried if muon is released
with too little functionality, people will write it off too quickly.
Stone
Replying here after seeing [#67].
I'm looking into packaging muon for Debian, and all the issues found
while packaging (i.e. the bootstrap phase ignoring {CPP,LD}FLAGS and
some minor typos) have been already fixed.
The only issue left is not something that can be fixed here, and is the
fact that the "muon" name is already used by [another package], KDE
Muon, for both the package name and /usr/bin/muon.
I've briefly [discussed] this conflict on the debian-devel mailing
list, and the only possible solution would be to ask the Qt/KDE package
maintainers to rename the current /usr/bin/muon to something else,
possibly muon-kde, as the program is likely launched by a .desktop file
as it is a graphical application.
The current "muon" package name will likely rename the same, so the
muon build system would need to be packaged under a different name.
What would you prefer? muon-build, muon-meson, something else?
muon-build as been [suggested] by another Debian dev, as "muon-build
seems more consistent with its own domain name muon.build, the
reference meson implementation's domain name mesonbuild.com, and their
shared dependency ninja being packaged as ninja-build".
I'll do my best to avoid renaming the muon binary itself, but in the
worst case it'll have the same name as the package.
[#67]: https://todo.sr.ht/~lattis/muon/67
[another package]: https://packages.debian.org/testing/muon
[discussed]: https://lists.debian.org/debian-devel/2022/08/msg00166.html
[suggested]: https://lists.debian.org/debian-devel/2022/08/msg00145.html
--
OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49
I think if the package name "muon" is not available, then we should
follow the precedent on [repology] and the [AUR] and call it "muon-meson".
> I'll do my best to avoid renaming the muon binary itself, but in the worst> case it'll have the same name as the package.
That would be acceptable. I probably should have researched the name
muon more before deciding on it!
[repology]: https://repology.org/project/muon-meson
[AUR]: https://aur.archlinux.org/packages/muon-meson-git
--
Stone