On Wed, Sep 11, 2013 at 2:32 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Tue, 10 Sep 2013 22:02:02 +0200 Côme BERNIGAUD <come.bernig...@laposte.net> > 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. -- Cedric BAIL ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
