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