There are many cases that a patch should be prefixified before applied. The new function eprefixify_patch achieves this. Reproducible: Always
Created attachment 434936 [details, diff] prefix.eclass.patch
Hmmm, I guess the only "win" here is not to have to specify the actualy files being patched? I think your description should mention the patches are applied too. Performance suggestion: vectorise the thing, so: - cp all patches at once to ${T}/tmpspace - eprefixify all patches at once in ${T}/tmpspace - epatch all patches at once from ${T}/tmpspace Other than that, got for it on -dev ML.
Created attachment 437630 [details, diff] prefix.eclass.patch epatch is too special. Instead a wrapper to any ebuild helper functions will provide nice syntax sugar. In addition, heuristics are added to cover some trivial eprefixify cases.
Created attachment 439182 [details, diff] prefix.patch Guys, what do you think?
I see what you're trying to do, but I'm wondering whether it isn't going the wrong way. Like for instance eselect now has built-in eprefix support in its install, we should aim for the same approach with most packages. Can you give an estimation about how many ebuilds will use this functionality?
(In reply to Fabian Groffen from comment #5) > I see what you're trying to do, but I'm wondering whether it isn't going the > wrong way. Like for instance eselect now has built-in eprefix support in > its install, we should aim for the same approach with most packages. Yeah. eselect is what we can control. Aiming for a perfect Prefix support is feasible. The same applies to other gentoo-born packages, like OpenRC. > Can you give an estimation about how many ebuilds will use this > functionality? I think at least 30% of the ebuilds can benefit from this functionality. For example www-client/w3m I worked on today. It has /usr /usr/local/lib /usr/lib /usr/lib64, etc. hard-coded in configure (via acinclude.m4), which is very common. Any library dependence has to be manually specified with econf --with-foo=${EPREFIX}/usr. But if we use the heuristics to prefixify acinclude.m4. The (prefixified) default paths work again. Lines of code to support Prefix decreases, which makes the merge of Prefix to gx86 less intrusive. The logics are shifted from ebuilds to prefix.eclass.
hi Fabian, is this update reasonable? There seems to be no objections from gentoo-dev.
Well, I'm not a fan of the fuzzy auto-replacement, but that's because I can see it go wrong sometimes. How about the following: - split out the autoreplacement stuff, e.g. keep eprefixy as-is, it replaces the @...@ thing and that's it - make the autoreplacement function work with a default param, which can be overridden (the -e opt) such that when the default is too greedy, it can be adjusted, reusing the magic of the function Idea is that it seems wrong to me to need both replacement of @...@, and autoreplacement, so this way we make it explicit. I also believe that eprefixify is a safer option than the autoreplacements, so nicer from that point of view too. I personally feel fprefixify is a too ugly hack, but if you deem it very useful (for the time being?) then ok, and you could have it run both eprefixify as well as the new function which does the autoreplacement, so you get the behaviour you get right now.
Created attachment 440934 [details, diff] prefix.patch > Well, I'm not a fan of the fuzzy auto-replacement, but that's because I can see it go wrong sometimes. Yeah, so I made it customizable. > How about the following: > - split out the autoreplacement stuff, e.g. keep eprefixy as-is, it replaces the @...@ thing and that's it Done > - make the autoreplacement function work with a default param, which can be overridden (the -e opt) such that when the default is too greedy, it can be adjusted, reusing the magic of the function > Idea is that it seems wrong to me to need both replacement of @...@, and autoreplacement, so this way we make it explicit. I also believe that eprefixify is a safer option than the autoreplacements, so nicer from that point of view too. Okay. I split out hperfixify for the heuristics. I also added another option -w for the line matches to prevent from the default to be too greedy. > I personally feel fprefixify is a too ugly hack, but if you deem it very useful (for the time being?) then ok, and you could have it run both eprefixify as well as the new function which does the autoreplacement, so you get the behaviour you get right now. Yeah, it's ugly. I would like to replace it with prefixify_ro, to copy a read-only file to ${T} and prefixify. What do you think?
Ok, I like this approach much more. Thanks!
In tree with some minor changes. Thanks https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ecdc2eb2332e
