On Sun, 31 Jul 2011 20:05:50 -0400 Mike Blumenkrantz <m...@zentific.com> wrote:
> On Sun, 31 Jul 2011 19:40:55 -0400 > Christopher Michael <cpmicha...@comcast.net> wrote: > > > On 07/31/2011 07:35 PM, Mike Blumenkrantz wrote: > > > On Sun, 31 Jul 2011 19:32:46 -0400 > > > Christopher Michael<cpmicha...@comcast.net> wrote: > > > > > >> On 07/31/2011 07:29 PM, Mike Blumenkrantz wrote: > > >>> On Sun, 31 Jul 2011 19:16:35 -0400 > > >>> Christopher Michael<cpmicha...@comcast.net> wrote: > > >>> > > >>>> On 07/30/2011 06:36 PM, Boris Faure wrote: > > >>>>> On Tue, Jul 12, 2011 at 01:10, Christopher Michael > > >>>>> <cpmicha...@comcast.net> wrote: > > >>>>> […] > > >>>>>> 2) It may not build on your system (tho it builds on all > > >>>>>> boxes I have tried so far). > > >>>>> > > >>>>> It doesn't build on my boxes (gentoo and arch linux > > >>>>> up-to-date). > > >>>> I find that very strange since all of the initial development > > >>>> that I did was on a gentoo box. If I had to guess, I would say > > >>>> you are using ACCEPT_KEYWORDS=~x86 to pull in masked > > >>>> packages...In which case, you are pulling in a development > > >>>> version of XCB and yes it will not build against that. > > >>>> > > >>>>> I've got xcb 1.7 and it introduced a split up of xcb-util. > > >>>>> I've attached a patch to make ecore_xcb compatible with xcb > > >>>>> 1.7. I haven't committed it since it would break your setup. > > >>>> While I appreciate the work/effort that went into your patch, > > >>>> I cannot put it in svn because that would break building for > > >>>> normal distros that use 'current' versions of xcb, not > > >>>> 'bleeding edge' versions. Most normal distros are still > > >>>> shipping 0.3.6 version of the XCB libraries. When they start > > >>>> shipping 0.3.8 by default, then I will gladly put this in svn, > > >>>> but until then, it Cannot go in because while it may fix > > >>>> building for your 'bleeding edge' setup, it breaks building > > >>>> for everyone else :( > > >>>> > > >>>> dh > > >>>> > > >>> IMO you may want to consider doing something like I have done > > >>> with eeze and libmount: provide 2 versions of the relevant > > >>> files with autoconf detection to determine which one actually > > >>> gets compiled. This way you can support the legacy (0.3.6) > > >>> version as well as the current (0.3.8) version, and everyone > > >>> wins. > > >>> > > >> Yea, that's a thought...except that 0.3.6 is not legacy, it's the > > >> 'current' version :) 0.3.8 is a 'development' version :) > > >> > > >> dh > > >> > > > Unless they're coming out with 0.3.6.1, 0.3.6.2, 0.3.6.3, etc, > > > 0.3.6 is legacy :P > > > > > Well, call it whatever you want to. I am too damn tired to argue > > symantics. The point is, until standard distros start shipping > > 0.3.8 by default, then we have to build against 0.3.6. End of > > discussion. > > > > dh > > > whoa calm down there angrypants, I was just kidding around. let me > know if you need/want a review of autoconf stuff :) What ever most distros were shipping *last year* is "current", coz that's what most people will actually have. Anything else is bleeding edge, fine for developers, power users, and others that like living on the edge, but wont work for normal users. Supporting both is great, supporting "current" only is good. Supporting "bleeding edge" only is bad. And no, it does not matter that what we are making is bleeding edge. :-P -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
