On Mon, 16 Jan 2017 12:05:29 -0200 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> 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. i would agree here. taking the "hand rolled makefile + sh" example - this would just be a custom "dist" target that would simply use git archive and create a tarball with the correct version in its filename. a "distcheck" target would rely on the dist target, then unpack that same tarball, cd into it, do a build and install to a test directory, then clean it all up when done (with any error along the way stopping it). it'd be a few lines of make rules realistically. > > > - 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. i wasn't meaning it had to be literally "make check" but an equivalent that builds the tests in-tree and then runs them reporting results. HOW we accomplish this is a good question. i'd go for a: make install DESTDIR=./tests/install export LD_LIBRARY_PATH=./tests/install/lib export PATH=./tests/install/bin:$PATH make tests ./tests/bin/testharness.sh ie literally install efl in the tests tree so efl is running "as it normally would or should as a relocatable library/binary set an then use it in preference to anything else on the system to run tests" > > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Mobile: +55 (16) 99354-9890 > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- 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
