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