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? -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (19) 9225-2202 Contact: http://www.gustavobarbieri.com.br/contact ------------------------------------------------------------------------------ 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
