On Sun, 17 Jun 2012 11:43:30 +0200 Hans de Graaff <gra...@gentoo.org> wrote:
> On Sun, 2012-06-17 at 09:26 +0200, Michał Górny wrote: > > > I'm attaching a reStructuredText version of the spec. You can view > > it rendered as a gist[1]. But please keep the replies on the list, > > rather than forking the gist. > > I don't like the approach taken in 6. I'd rather state that there > should not be file collisions between the dynamic slots. We already > handle things this way in ruby (with a common 'all' and specific > version builds). That is impossible for most of the build systems. If Ruby has a nice ability to split between building common and ABI-specific stuff, that's great. But Python doesn't have one. Bindings built using other languages don't have that either. The usual way of handling that is through letting all the ABIs install to the same image, and then installing whatever got merged as a result. The spec practically suggests the same yet split in time. Shortly saying, we can't do that or we will be stuck installing everything by hand, which will practically make this idea useless. > For 9c I can't see us limiting users to a single ruby implementation > by default (the only current exception is www-apache/passenger), so a > combined ||() block makes no sense to me. I think it is better to be > explicit here and express the real situation with multiple ||() blocks > if needed. I think you misunderstand the concept of combined block. It was mostly supposed to be useful when a single package provides bindings for multiple languages, so that a single build would involve building bindings for one ABI of one language. Multiple blocks would involve building bindings for both one Python ABI and one Ruby ABI at a time which means scary results. That probably even won't work, so splitting it is the only alternative to one big block. > Finally, I don't expect ruby to use this unless we can ensure that > this works with our current ebuilds without changes. I'm fine with > supporting some code in the eclass to determine which mechanism to > use in which way, but we won't be spending huge amounts of time > switching to yet another system. To me the perceived benefits aren't > big enough. I'm trying hard to make this as painless as possible but I can't guarantee single ebuilds (uncommon cases) wouldn't need changes. However, I'm trying hard to ensure that majority would be clearly handled by eclasses. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
