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... 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 ------------------------------------------------------------------------------ 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
