On Mon, Oct 19, 2015 at 2:28 PM, Alexis Ballier <[email protected]> wrote: > > However, as you say, putting it in cmake-utils needs to be properly > thought so that it doesn't conflict with other eclasses: Hence the need > to properly define what eclasses should call eapply_user and apply > patches and what should not. >
That is my main concern. Maybe a package uses cmake and ant. Patches could affect either. With an automagic design you might have to run half of each src_configure, then apply patches, then run the other half of each src_configure. > Your initial argument was very convincing, but under those conditions, > it seems way much saner to make eapply_user idempotent and be done. > (and maybe in addition require informally that eapply_user is called > after applying patches, but that'd fall under good practices rather > than rules) The only danger here is that later phase functions to run would be operating on already-patched sources, when they expect to be running on unpatched sources. I imagine that usually wouldn't be a problem, but it of course could be one. I do get your analogy to eapply_user not being in the default phase function. This all falls into that general category of correctness vs convenience. It is more convenient if you can just call eapply_user at a suboptimal point and not have to mess with your ebuilds. The same argument could be made for running all the inherited eclass phase functions and not just one of them. The issue is that this can break in lots of hard-to-predict ways. I'd rather see things refactored to deal with this in a more sane manner. That actually makes me wonder if the better solution is to add another phase - such as src_postprepare or something like that, where you'd run autotools or whatever. If that were done then you could also make hasufell happy by just having the PM do the patching after src_prepare. Maybe that can go in EAPI7. :) -- Rich
