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... ? 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 wouldn't care about trying to speed up a build 5% or 10%. only developers care (or gentoo users but they shall be ignored for the purposes of this argument as they CHOOSE to rebuild everything on their OS. so their problem - they get to suffer as devs do). years ago i would try some new thing in the evas gl engine module and it'd be 10 seconds total between save and me seeing a result. now with a machine 4-5 times as fast it's 1 minute. same with eina. add an new api. wait 3-4 minutes. it USED to be sub 10 seconds. this is just exacerbated on a slow arm machine into 10's of minutes or hours. > the patches to disable those code are simple, sometimes just -DXXX as > the code had the conditions in place (#ifdef), but people (including > me!) disabled that from the configure.ac > > > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Mobile: +55 (16) 99354-9890 > -- ------------- 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
