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 :) -- Mike Blumenkrantz Zentific: Coding in binary since '10. ------------------------------------------------------------------------------ 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-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
