On Wed, 28 May 2014 06:21:18 +0200 Guillaume Friloux <[email protected]> said:
> On 14/05/28, Carsten Haitzler wrote: > > On Tue, 27 May 2014 16:36:47 +0200 Guillaume Friloux <[email protected]> > > said: > > > > hey man. calm down. > > > > you are trying to catch up on 2 years of development in one bang. yes it's > > painful. also note that the majority of people packaging/using efl need and > > WANT the gui. EFL was written FOR the purposes of building a window > > manager. it was split out from the wm binary because "hey some of these > > libs may be useful to other people", but the focus of EFL is gui. > > > > you CAN get what you want. build with everything - it only take like 2-5 > > minutes on a vaguely decent machine (including configure), and then: > I have quite some build targets, adding windows/osx in the next months, and > currently on BSD. I expect to see new deps as time comes. that'd be the same no matter what. the "every dep is auto selected" was nice for developers but it SUCKED for distribution - packages may or may not have a feature depending if the dep was installed at build time and this created far more problems than having it all automagic solved. so you'd have to deal with new deps regardless if its a single tree or maultiple. also ask stefan how much easier it is to do releases of efl now - having it merged means we can release more often because its far less work. the problem is you are ignoring all the upsides to what we did because it's different to your previous build setup and you need to adapt. > And as the focus is GUI, i cant get any guarantee that i will keep the > possibility to remove the GUI stuff in the future. correct. you can just hope. that doesn't change the fact that we could have done that with a split setup too - added gui things that are core. > What if one day any of you come and say "Hey, lets merge libs, it will be > better for us". I will be stuck, just like i have already been. we will merge libs. that's my plan for efl 2.0 - likely it'll be merged into 2 libs (maybe 3) libefl-core.so libefl-gfx.so and maybe libefl-etc.so. guess which does what? > When i decided to use EFL, one of its major point was its modularity, > it was all cool for me because i could just build what i needed, and everyone > by that time was happy about that, and claiming it would stay like that. and that modularity cost us a lot in terms of support from distributions and in complexity to build along with complaints. it was a nice theory, but in practice it fell over badly. do a survey of efl devs and ask them which is better. they will almost all say that a unified tree is better, and we likely want to merge even more. > > make DESTDIR=/tmp/myefl > > > > then delete the stuff in /tmp/myefl you don't want - and tar/package up that > > dir to distribute to your boxes. you only need the dependencies on your > > build box - not on all of the targets. this is why it wasn't considered a > > priority to have a special build profile like this as it can be done > > post-build. this is actually how most distributions build and package > > things - they build it all then split it up. you should give it a go. > If i do this (and i already did it for archlinux last year), this will be > something ill have to maintain constantly to handle changes. > Here is a PKGBUILD that was working at some time : > https://aur.archlinux.org/packages/ef/efl-server-git/PKGBUILD > Of course, its outdated now. you can ALSO just keep a list of files you DO want (files and dirs) and use that list to copy/tar just those and the subdirs, nuke the rest, then untar or move back in place. so you have 2 ways to do it. if you do it right, it's no different to keeping up with efl if we kept it as it was - as it was we'd add new things that would be on by default that you have to --disable and thus keep up somehow. try the "list only things to include" as that matches exactly the style of just selecting specific efl elements (eina, ecore, eet etc.) it's less work than having multiple pkgbuilds or equivalents and all the --enable/disable things. tar cf /tmp/files.tar \ $DESTDIR/path/to/dir \ $DESTDIR/path/to/file \ ... rm -rf $DESTDIR cd / tar xf /tmp/files.tar rm /tmp/files.tar (and then package up $DESTDIR as normal) easy. just list all the dirs/files you want to keep in the list. > > as for 1.7 maintenance - do you really think we have the manpower to do both > > development and move efl forward with the insane list of requests for > > features and other stuff, as well as maintain efl 1.1, 1.2, 1.7, 1.8, 1.9 > > AND 1.10? we don't even have branches for 1.7 and below in efl (elm has 1.7 > > and 1.0, but not efl)? have you send the patch review queue? it eternally > > gets bigger - we try and keep up. bugs - they don't go down, only up. take > > a look at wishlist priority bugs one day to truly see the backlog. do you > > think we have the luxury to support old versions of efl for years? we > > don't. i''m really sorry that this causes you to make some choices - > > package as above, which i assume you'll just reject out of principle, even > > if it perfectly does the job, simply with a bigger set of deps and maybe > > 1-2 mins of extra build time on just the build box, or spend some time and > > effort doing the work needed to support you - either stay on 1.7 and do > > your own long term support, or to do what YOU need to make current efl work > > better for you. scratch your own itch. > I know you cant maintain all the versions, but this is how i get stuck. > One of the possibilities i still have is to fork eina/eet/ecore/eio from > legacy as it is the latest usable version. so you know we can't do what you want us to do... but you complain bitterly anyway? dude! chill! :) > > you should calm down man. take it easy. there isn't some conspiracy to piss > > you off - in fact the efl tree merge has been nothing but positive > > responses from everyone EXCEPT you. packagers love it. we have fewer > > problems of efl builds that are poorly configured and missing features. > > individuals who track efl from git or tarballs have an easier time building > > and keeping up. doing the tree merge was a massive effort and took quite a > > while and having ultimate configurability wasn't something we can keep. in > > fact it's discouraged to stop there being broken efl builds. > I know theres not only me that got a problem with what has been done with > the build, but im not here to speak about others, im speaking about my case. so we keep making things worse for 90%+ of our users to keep 10% from having to adapt? you can adapt and have exactly what you want. see above. > > configure.ac is complicated because we still have a fair number of build > > options to support multilpe os's, older distributions missing dependencies > > etc. > > - if we forced everything as a dependency you'd complain too as now you > > would have precisely zero choice, and we'd lose support for bsd's, osx, > > windows, and distributions except the latest and greatest on the bleeding > > edge. you need to stand back and realize that efl is complex by its nature. > > this is an artifact of history. thus its build is complex. one day (efl 2) > > things will simplify and we'll merge libraries and thus reduce > > inter-dependencies, thus reducing build complexity (and code as well), but > > that's a slow march to that goal and there are other higher priorities > > until then. we can't do everything at once when everyone would like it. > Concerning windows, EFL isnt really usable. > freebsd guys stayed on 1.7, just like me. > What is the last elm version you saw run correctly on windows ? its probably > 1.7. The only case that really got better, is the linux desktop, even if it > seems that for debian it required a lot of work to get it done. 1.10 works on windows. pretty well. displays correctly and functions correctly at least for the elm tests i saw - it's running on jpeg's windows laptop just fine - he was messing with it in the last few weeks. freebsd - likely they should couldn't be bothered upgrading, but that's their problem. > If you use EFL for linux desktops, it seems it will continue to work, > otherwise, it is likely to be broken at any moment, because (imo) most of the > guys doesnt care. why? as above - strip out what you don't want from the install OR just list the things you DO want to keep and keep those. keep entire directories. all the modules and so on are installed in specific named directories - libs have specific names. nothing there has broken since efl 1.7 - we have ADDED new stuff in correct dirs, but not broken anything. > The reason that got throw to my face 1.5 years ago for removing the > possibility to disable the build of some libs was that one of the devs > supposedly had a friend that knew nothing to compilation and was having a > hard time building EFL, so it was better to put hard deps everywhere to ease > his work. Like if a guy that knows nothing to compilation should be building > instead of using packages. It was one of the best joke ever. this is actually true - especially of gnentoo and all its USE flags. idiots who think they are cool enable "xcb" use flags because someone told them xcb is faster and then they find certain features not working in e or efl because xcb support isnt there or it's iffy (xcb with opengl is impossible so we have a hack to keep xlib and then drop to xcb behind xlibs back - but some drivers are far from happy with this). the CONTINUAL questions of "what is the build order" from people REGARDLESS that we documented it on the website - they still keep asking. it is was a problem. now its gone. > > so calm down man. chill. stand back and see the forest from the trees. :) > > > > > Congratulations, e devs, you won at ruining my work. > > > > > > Since 1.5 years, i am stuck with 1.7 branch due to your crazy ideas. > > > Your first step as been to make me unable to disable the building of libs > > > i dont need, when merging tree (ALL of the GUI libs). > > > > > > Then, some of you told me to make a 'server' profile, which is stupid > > > because it is incompatible with building with the dev profile, for > > > exemple. > > > > > > What happenned next is that decision to only add security fixes to 1.7 > > > branch, no fixes at all. Bam! > > > > > > Luckilly, i was really busy, and then having my enterprise shutting down, > > > so i had no time to look at the madness. Since over 6 months, a bigger > > > enterprise bought us, and since yesterday, ive find some time to work on > > > migration to EFL 1.10. > > > > > > Needless to debate about how this configure.ac file is stupidly huge, and > > > far from KISS principles. After almost a day looking at how things are > > > now built, i started writting the server profile. It wasnt pretty (Oh > > > yeah, really not pretty), but it was working, until i removed ecore_evas > > > et and ecore_imf. What the fuck is wrong with you guys ? I cant even > > > build the doc because some guy thought it would be cool to have a C tool > > > automagically generating text previews, using ecore_evas! > > > > > > How far are you going in your ideas ? > > > I have been completely put apart from EFL, with everyone ignoring my > > > work, my needs. > > > > > > So i have understood, everything in EFL starting with a number of 1.8 or > > > upper is ONLY dedicated for GUI stuff. No one is supposed to use > > > eina/eio/eet/ecore separately. Even if i ended my work with server > > > profile, i know there will always be people to either remove or break it > > > (You removed it once, you can remove it always). As you seem to be able > > > to break anything the day you want, ignoring 'others', i better stop. > > > > > > I get it. > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) [email protected] > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
