On 01/11/2018 00:29, Marcel Hollerbach wrote: > > > On 10/31/18 10:35 AM, Carsten Haitzler (The Rasterman) wrote: >> On Tue, 30 Oct 2018 12:45:34 +0100 Marcel Hollerbach <m...@bu5hm4n.de> >> said: >> >>> >>> >>> On 10/30/18 10:11 AM, Xavi Artigas wrote: >>>> I don't know what I'm talking about now, but I think Mike suggested >>>> that >>>> the examples repo could be a submodule of the efl repo, which could be >>>> checked out and built when "make examples" was called? Is that an >>>> option? >>>> >>>> In this way we have the trees separated, with a much lighter efl, while >>>> still having the convenience of "make examples". >>>> >>> >>> That is possible. (With meson :)) >> >> possible with autofoo too - it's not just meson :)... but why does a >> lighter >> tree matter? when you have the git tree you get the whole history so >> if it ever >> WAS in the tree... you still clone it (unless its a shallow clone - >> another >> story). if building of examples isn't the default then it's not going >> to be >> tested as much as people are not aware of it being an option etc. etc. >> - yes. >> it adds to the build time, but with benefit. unlike making -Werror >> default >> which can lead to build failure due to causes outside of tree (like >> system/dependency headers causing warnings thus build errors), this >> would have >> build errors that are a result of efl's breaking something... :) >> > > I actually don't really know where to start right now why a lighter tree > is better, from efl.git POV: > > 1) The API is probebly more used in tests then in the examples (if not > then we are in much bigger trouble) > 2) The API is checked anyways in the tests, thus this is just useless > wasted compile time > 3) Our examples simply don't build. check out the ephysics stuff :) > 4) We are talking about the efl.git repository, i would try to keep > software in there that works. Everything else looks dubious. > > from the examples.git POV: > > 1) someone searching for examples of efl probely does not want to fight > trough the jungle that we call our efl.git repository > 2) its way easier to get your own software out of the example if you can > have a look at the buildtool and cnp solutions out there. The efl > build-system is giant, you will likely never find any usefull > information there without wasting a lot of time > 3) Compiling against the installed version of efl is different from > compiling against something in-tree. Header wise, and dependency wise. > 4) Take a look at the ecore-con examples, they partly have used stuff > from config.h that is generated from efl.git, there is no logical > seperation between the configuration of the examples and the > configuration of efl, that makes understanding a single example super hard. > > TLDR;: > So all in all. Can we stop adding replies to this thread that impose no > objection nor agreement, but rather just continue... ? :) > > Greetings, > bu5hm4n >
An objection would be currently distro's build and test the examples (well we did when they worked) if they were in a separate tree I probably wouldn't bother packaging them anymore, i'm guessing others would be the same. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
