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.


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

Reply via email to