Skip to content

Conversation

IlitriumNumerus
Copy link

Add support for the mx compiler tool used by GraalVM. I plan to create the ebuild for GraalVM as well, so this PR is the first step.
This is my first ebuild, I would appreciate if you could give me some advice and tips !

@stkw0
Copy link
Contributor

stkw0 commented Aug 18, 2025

Thank you for the PR.

Having live-ebuilds only is discouraged. Given that upstream tags versions, you can grab the tar.gz for the latest version instead.
About the ebuild itself, you should rely on distutils-r1 for the installation. You can search inspiration in other dev-python/ ebuilds or the guide at https://projects.gentoo.org/python/guide/distutils.html
Lastly, we don't currently merge PR for new packages. While we appreciate receiving PR as a way to review the ebuilds before they are added, to add it to the repository you should register at GURU as explained in https://wiki.gentoo.org/wiki/Project:GURU/Information_for_Contributors

@IlitriumNumerus
Copy link
Author

Thanks for your feedback !
I replaced the live-ebuilds by the latest tags versions (for major version 6 and 7) and I used the python-single-r1 eclass (distutils not fitting this package). Could you review the new ebuilds ?
I've also opened an access request.

@stkw0
Copy link
Contributor

stkw0 commented Aug 20, 2025

Awesome! It looks much more clean now.
I will ask for more reviews because I am unsure if it is correct to install java code as a part of a python package but it seems a bit of a special case.

SITE_PKG="$(python_get_sitedir)/${PN}"
python_moduleinto ${SITE_PKG}
python_domodule *
chmod 0755 "${D}/${SITE_PKG}/mx" || die "Failed to chmod mx executable"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The upstream code isn't well set up for "proper" installation, but it's absolutely not sensible to install the entire git repository into sitedir/mx/.

This also then results in sitedir/mx/mx being a bash script that tries to run sitedir/mx/mx.py using several different versions of python, but doesn't respect Gentoo's EPYTHON which means that PYTHON_DEPS` is accomplishing nothing. :(

I would recommend instead installing src/mx as a module, and writing your own simple python script to install to /usr/bin that simply imports the module directly.

Please also figure out which data files actually need to be installed. It may make sense to install them to /usr/share/mx and patch the application itself to find the resources there instead of relative to __file__.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took me quite some time to figure out this mess (the way modules were done prior version 7 were really messed up and version 7 also had to deal with backwards compatibility) but now it should be all good.

@IlitriumNumerus
Copy link
Author

Any review for this PR would be appreciated.

Working on GraalVM's ebuild, I need some advice concerning dependency management. GraalVM's components require a lot of dependencies, listed in a suite.py file for each component. Some of the dependencies are in the gentoo overlay, while others are not. The ones being in the gentoo overlay are often outdated versions not present anymore in the overlay. One other aspect of this problem is that mx downloads itself the dependencies during build and store them in its own cache in ~/.mx, which causes obvious issues of sandboxing. So here are my questions :

  • Should I use system-wise dependencies ? If so, then I would need to work on a lot of additional ebuild. I would also need to bring back old versions of these dependencies, would that be okay ? This solution would be the cleanest but also would require a lot of work.
  • If I use system-wise dependencies, I face another issue, mx will try to look inside its own cache folder. There are 2 solutions : either I need to patch each component suite.py and provide a system-path, or I could also populate the cache with the system dependencies, which would be much easier.
  • If I don't use system-wise dependencies, then maybe I could somehow download the dependencies using mx in the src_prepare phase and populate the cache ? Then in the src_install phase I could delete the cache.

Having to deal with a custom build tool with its own dependency management for my first time ever writing an ebuild is difficult, so any help would be appreciated !

@stkw0
Copy link
Contributor

stkw0 commented Sep 17, 2025

I think it would be best to use system-wise dependencies, in general. For the cases you would need to bring back old version then it can be better to download those.
I would like to help more, but I don't have too much experience with Java nor ever used mx. If you have doubts you can ask in the IRC channel of #gentoo-guru or if it's something very specific about ebuild developemnt in #gentoo-dev-help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants