On 11/09/13 15:12, Gustavo Sverzut Barbieri wrote: > On Tue, Sep 10, 2013 at 10:21 PM, Cedric BAIL <[email protected]> wrote: >> On Wed, Sep 11, 2013 at 2:32 AM, Carsten Haitzler <[email protected]> >> wrote: >>> On Tue, 10 Sep 2013 22:02:02 +0200 Côme BERNIGAUD >>> <[email protected]> >>> said: >>> >>>> Le 09/09/2013 15:43, Tom Hacohen a écrit : >>>>> On 03/09/13 22:25, Côme BERNIGAUD wrote: >>>>>> Hello, >>>>>> >>>>>> I saw that there is a new component named EO in the EFLs. >>>>>> EO is already a library, it stands for «Evolving Objects» : >>>>>> http://eodev.sourceforge.net/ >>>>>> >>>>>> This is causing trouble, at least for one file: >>>>>> /usr/lib/pkgconfig/eo.pc is the pkgconfig for evolving objects, which is >>>>>> already used by several projects over the past years. >>>>>> >>>>>> So it might be a good thing if you could rename at least this file. >>>>>> >>>>>> Côme >>>>>> >>>>>> PS: The problem was found when trying to install the AUR package efl-git >>>>>> on ArchLinux, but I'm pretty sure this file is from upstream. >>>>> >>>>> Unfortunately it's really annoying to change it. After discussing it >>>>> on IRC and thinking about all the pain involved, we decided not to >>>>> change anything. >>>>> >>>>> We don't want to change the library name itself, that is, we like eo. >>>>> Changing just the pc file creates a lot of issues with our build >>>>> system which does a lot of things automatically and assumes a specific >>>>> template to be followed. >>>>> libXX.so, XX.pc and etc. >>>> That is a very sad decision. It means people won't be able to install >>>> both EO and the EFL… >>>> The filename eo.pc was already used since several years by EO, it's >>>> childish to just ignore that and take the same name. >>>> You should indeed use a pattern like efl/xx.pc or efl_xx.pc because if >>>> you intend to keep using two-letters names, you'll find a lot of them >>>> are already in use. >>>> >>>> Someone was also anxious about eo.h names or such, I just checked, and >>>> libeo is also using: >>>> /usr/include/eo folder >>>> /usr/share/eo folder >>>> /usr/lib/libeo.a file >>>> /usr/lib/libeo.so file >>>> >>>> Which might also conflict with your EO thing (I did not check, just >>>> thought these files might conflict) >>> >>> the libeo.so/a and include dirs will conflict. >>> >>> here is the problem. all of efl follow a pattern. the configure and >>> makefiles >>> all use macros to define the pc, include etc. etc. etc. stuff as they all >>> follow the same design pattern - the same template and same standard. >>> making eo >>> different is a pain in the butt and is going to lead to a bunch of >>> exceptions >>> and "not following the design pattern" which leads to problems with >>> packaging >>> or otherwise maintenance. >>> >>> so our choice is change eo to something else (and making it short was a >>> primary >>> goal, and e_ is already taken by ... e so we'd have to go changing 100,000+ >>> lines of code in e to avoid it), so we have eo... eob is longer etc. as is >>> eobj >>> etc. >>> >>> it's not childish - it's not being ignored, it's just that the alternative >>> solutions are unpalatable. we'd have to go over 500,000 lines of code and >>> change them to use something other than eo_ and EO_ etc. etc. to change the >>> lib >>> namespace... >>> >>> the decision is not made lightly or childishly. it's simply going to have >>> to be >>> a conflict :( at least for now. one day we will merge a lot of efl into >>> libefl.so and likely includes will move into an efl subdir, have an efl.pc >>> etc. >>> etc. so the conflict will eventually go away, but that day is not today. >>> that >>> day is efl 2.0 and its still years off. eo is one of those migration path >>> elements on the way there - it's unifying our object model and putting in >>> the >>> basics to improve our interfaces. CHANGING efl to use efl subdirs for pc >>> files >>> already creates an api break and that MEANS efl 2.0 and we are not breaking >>> api >>> for a minimum of 5 years following efl 1.0 releases. that's a level of >>> stability i wanted to keep and i'm not backing down on that as backing down >>> means developers can't trust in stability and every time we violate that >>> trust >>> we prove that we are unable to give them a base to build on. thus my desire >>> for >>> a 5 year "guaranntee". even beyond those 5 years there will likely be an efl >>> 1.x compat layer that is on top of the efl 2 stuff (just like we do today >>> with >>> eo already and existing efl). >>> >>> so it's not childish, it's a decision that you may not like, and it means >>> there >>> is a conflict, and that will stay, but the number of people ACTUALLY >>> affected >>> by the conflict i believe will be very small. at least until efl 2 ... as >>> above. >> >> Maybe a stupid idea, but do we still need an eo.pc ? Why not just an >> efl.pc for all the new library that never went released outside of EFL >> ? That would solve the problem and the distribution can rename the >> library or put it somewhere else as long as efl.pc, it would be fine. > > problem is how you filter libraries from efl.pc you want to link. Say > you wrote a single daemon using only eina, then you'd be linking with > eo/evas... everything from efl.pc? > >
Second problem, as we've said, it's not just the pc file that conflicts. -- Tom. ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
