On Thu, 19 Jan 2017 12:32:30 -0200 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> On Tue, Jan 17, 2017 at 10:08 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Tue, 17 Jan 2017 12:24:58 -0200 Gustavo Sverzut Barbieri > > <barbi...@gmail.com> said: > > > >> On Tue, Jan 17, 2017 at 11:56 AM, Carsten Haitzler <ras...@rasterman.com> > >> wrote: > >> > On Tue, 17 Jan 2017 11:25:06 -0200 Gustavo Sverzut Barbieri > >> > <barbi...@gmail.com> said: > >> > > >> >> On Mon, Jan 16, 2017 at 10:04 PM, Carsten Haitzler > >> >> <ras...@rasterman.com> wrote: > >> >> > On Mon, 16 Jan 2017 16:15:40 -0200 Gustavo Sverzut Barbieri > >> >> > <barbi...@gmail.com> said: > >> >> > > >> >> >> On Mon, Jan 16, 2017 at 3:41 PM, <marcel-hollerb...@t-online.de> > >> >> >> wrote: > >> >> >> > On Mon, Jan 16, 2017 at 12:05:29PM -0200, Gustavo Sverzut Barbieri > >> >> >> > wrote: > >> >> >> >> On Mon, Jan 16, 2017 at 6:55 AM, <marcel-hollerb...@t-online.de> > >> >> >> >> wrote: > >> >> >> >> > Hello, > >> >> >> >> > > >> >> >> >> > On Mon, Jan 16, 2017 at 01:26:28PM +1030, Simon Lees wrote: > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> On 01/16/2017 01:00 PM, Carsten Haitzler (The Rasterman) wrote: > >> >> >> >> >> > I'm going to bring this up as it's highly controversial... > >> >> >> >> >> > and not everyone is going to be happy, but doing NOTHING is > >> >> >> >> >> > worse. > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > I propose that whatever we come up with should support at > >> >> >> >> >> > minimum the following build system "features": > >> >> >> >> >> > > >> >> >> >> >> > * configure --prefix=XXX > >> >> >> >> >> > * configure --bindir=XXX > >> >> >> >> >> > * configure --sysconfdir=XXX > >> >> >> >> >> > * configure --libdir=XXX > >> >> >> >> >> > * configure --includedir=XXX > >> >> >> >> >> > * configure --datadir=XXX > >> >> >> >> >> > * configure --localedir=XXX > >> >> >> >> >> > * configure --mandir=XXX > >> >> >> >> >> > * configure --docdir=XXX > >> >> >> >> >> > * at least all the relevant configure features we added for > >> >> >> >> >> > efl > >> >> >> >> >> > * make (from any dir/subdir) > >> >> >> >> >> > * make install > >> >> >> >> >> > * make uninstall > >> >> >> >> >> > * make DESTDIR=xxx > >> >> >> >> >> > * make dist > >> >> >> >> >> > * make distcheck > >> >> >> >> >> > * make check > >> >> >> >> >> > * cross-compiling (--host=XXX --build=XXX) > >> >> >> >> >> > * gettext support > >> >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> I'm feeling lazy but the output of openSUSE's cmake rpm macro > >> >> >> >> >> is the following and will answer some questions, cmake doesn't > >> >> >> >> >> support make dist out of the box, you could write a custom one > >> >> >> >> >> or use something called cpack (i've never used it), most > >> >> >> >> >> projects just do a clean checkout and tar it up and ship the > >> >> >> >> >> tarball. "make check" can be done with a custom command in > >> >> >> >> >> cmake, cross compiling is also certainly supported. > >> >> >> >> > > >> >> >> >> > Just to clarify things a bit here: > >> >> >> >> > > >> >> >> >> > - cpack is quite easy you add a bit of configuration to your > >> >> >> >> > CMakeLists.txt and you have make package, this will then > >> >> >> >> > generate all the packages you have configured, those can be > >> >> >> >> > source-packages or directly a debian packages (just needs to be > >> >> >> >> > configured. > >> >> >> >> > >> >> >> >> cpack is kinda of annoying and I don't see it as being any good > >> >> >> >> for projects that already have a public git repository. As with > >> >> >> >> automake, it's easy for developers to forget files and tarballs > >> >> >> >> can't 'make dist' anyway. > >> >> >> >> > >> >> >> >> IMO it's much simpler and more reliable to simple translate 'make > >> >> >> >> dist' to 'git archive' and require that to be executed from > >> >> >> >> within a git repository. We can even offer a 'make clone' that > >> >> >> >> will 'git clone' the current tag/commit and setup the non-GIT > >> >> >> >> folder as a GIT one. Or ignore that, since developers are > >> >> >> >> supposed to work on GIT anyways. > >> >> >> >> > >> >> >> >> > >> >> >> >> > - there is the test target, which is somehow what check is in > >> >> >> >> > efl. So if its okay to use a different target name, you dont > >> >> >> >> > even need a custom command. > >> >> >> >> > >> >> >> >> all systems support some kind of 'make check' since they can > >> >> >> >> manage dependencies and execute commands -- all that is needed. > >> >> >> >> > >> >> >> >> the actual tests are written by us on top of 'check' library. > >> >> >> > > >> >> >> > The message was not 'this is possible with cmake' it was more that > >> >> >> > there is 1:1 the same utility (build a executable, call add_test), > >> >> >> > so there is no need for custom commands that generate the test > >> >> >> > results or something like that. So the quote '"make check" can be > >> >> >> > done' with a custom command in cmake', that sounds like there is no > >> >> >> > test util, is wrong. > >> >> >> > >> >> >> got it. > >> >> >> > >> >> >> anyway, cmake is nice overall, not the best to handle configure > >> >> >> dependencies* (kconfig shines there), but we can do those manually in > >> >> >> cmake as we do in autoconf. Given multiple cmake backends, the ninja > >> >> >> x make is handled transparently... > >> >> >> > >> >> >> * google tells me that cmake's best effort is to use > >> >> >> https://cmake.org/cmake/help/v3.6/module/CMakeDependentOption.html#module:CMakeDependentOption > >> >> >> which i miles away behind kconfig > >> >> > > >> >> > indeed kconfig would be better for ... options... BUT shouldn't we > >> >> > have fewer options with simpler sets of permutations as much as we > >> >> > can? :) so it matters less? > >> >> > >> >> not sure it's that feasible, seeing that pain now with the project to > >> >> run efl+webkit on a small armv6, some stuff is too heavy. If we had > >> >> ways to disable parts and still have reasonable dependencies, then it > >> >> would reduce the permutation options. > >> > > >> > in what way? simply installing dependencies? just the amount of thngs > >> > installed? > >> > >> in our case we had to force some efl modules to be disabled, as well > >> as their deps. things like efreet, eldbus... > > > > and so you have some extra stuff on disk and to compile... where is the > > issue? we still maintain the ifdefs because we used to have them. as a > > result, for example, recently i was going over out evas loading infra and > > realized the efreet mime magic should really be used to pick the loader to > > use. have an explicit mimetype list and use the mime magic data and parser > > to avoid "try every loader until 1 succeeds" as it's be hugely more > > efficient ... but i can't because efreet is not an evas dependency and > > separate and so i went "ahh shit". so our code is as a result worse because > > of all the separation and splitting. > > > > so you have some extra stuff on disk? and? some stuff to compile. it's not > > like efreet+eldbus is 50% of your compilation time... ? > > not just disk, but memory. We had a case of efreet being loaded and > initialized (with all dirty pages that results) because of 2 calls > that basically getenv("XDG_.." and provide a default if unset. > > since webkit itself is a super-memory hog, removing those, eio, eeze > and even ecore-file we managed to free some memory to run the JS that > was resulting in OOM. > > however I agree with your point that the burden shouldn't be on the > EFL developers... but allowing me to easily do that is a bonus :-) oh sure. i do get that. there has to be a balance. between what can be maintained and developed easily with fewer issues and what is efficient. if we had fewer .so's the dirty pages would be far less of a problem as they would merge across the .so's and whole pages where there are maybe 64 or 128bytes of "stuff" now can collapse together. we'd save a few hundred kb of them per process if we merged more efl libs. i think that efreet itself really needs a redesign with os portability in mind not just an "xdg implementation" and i think we should make efreet really a thin layer to get to an "on disk database of stuff" plus a bit of "standards env var handling" and not a hell of a lot more. :) move the standards off into "importers" or such... :) > > also whats is the cost to 99% of people with efl to try and cater to 1% who > > want some ultra-custom thing? it hurts our performance. it also hurts > > development speed, maintainability and more... when you have too many > > options you just never get to test a of them. do they even build? and if > > they build do they work - even basically? the more you have, the worse this > > is. > > i know that, remember I was one of those pushing to remove efl options > when we did the merge. I still keep that position, but allowing people > to disable with few changes would be nice. sure. we just have to be careful of going too crazy on the options. > like the m4 macros for efl lib and internal dependencies... with > super-small configure.ac you can turn a mandatory library into > conditional and everything is handled. my current thoughts are more along the lines of "conditionally compile in implementations but keep api's" if we do things like this so if you have to handle a NULL return anyway ... a compile out impl just always returns NULL... :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
