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. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
