On Tue, 19 Aug 2008 23:31:17 +0530 Arun Raghavan <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > The benefit is that it's a logically separate action, and will avoid > > all the silliness of people repeatedly changing their minds about > > which phase should do the eautoreconf calls and so on. > > a) Is this really an issue for maintainers?
It's not a huge issue, any more than src_configure is. Equally, it's not expensive to implement. > b) Does it really matter? In the grand scheme of things, no. In the grand scheme of things, you only *need* a single src_ function. From a maintainer convenience perspective, however, src_prepare is marginally more useful than having a split src_configure. > c) So the flow will look like: > > ... > src_unpack > src_prepare > src_configure > src_compile > ... > > To me this seems like an unnecessary overgeneralisation. It's a better mapping of the things ebuilds do than the current set of functions. The logic is this: lots of ebuilds end up duplicating src_unpack (or, in future EAPIs, calling 'default') and then adding things to do preparation work. Experience suggests that the most common reason for overriding src_unpack is to do preparation work, not to change how things are unpacked. (Number-wise... For Exherbo, where the split's already been made, custom src_prepare functions are three times more common than custom src_unpack functions. And that figure's significantly lower than what Gentoo would see, because with exheres-0 'default' functions you don't need to write a src_prepare if you're merely applying patches.) > The *only* potential "benefit" I see here is that at some point of > time in the nebulous future, it might be possible to tell the PM to > always skip src_prepare in order to give a system where everything is > "vanilla". Such a system wouldn't be usable... Not all of Gentoo's patches are non-essential. -- Ciaran McCreesh
signature.asc
Description: PGP signature
