I am afraid in the middle of this discussion Mike's message has gone unnoticed. He already did this move 2 months ago: https://phab.enlightenment.org/D6880 His patch removed the examples from the efl tree, including makefiles and CI. The examples in their new location already have makefiles. The task is still pending review.
Marcel, can any of that work still be used? Xavi On Fri, 2 Nov 2018 at 14:35, Carsten Haitzler <ras...@rasterman.com> wrote: > On Thu, 1 Nov 2018 10:45:15 +0100 Marcel Hollerbach <m...@bu5hm4n.de> > said: > > > > > > > On 11/1/18 9:37 AM, Carsten Haitzler (The Rasterman) wrote: > > > On Wed, 31 Oct 2018 14:59:51 +0100 Marcel Hollerbach <m...@bu5hm4n.de> > said: > > > > > >> > > >> > > >> 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) > > > > > > more tests == better. :) examples will almost definitely use api in > > > different ways. we don't have a full complete test suite of every > api... so > > > examples out of tree removes a build test at least. > > > > Now you switched from API testing to behaviour testing ... Which implies > > that you will need to run every single examples that we have every time > > no - i still mean api. they would pass different enums, use differing > api's to > the tests we have as tests we have do not cover 100% of api - not even > close. > they cover a small fraction of efl's api. > > > you patch something, while remembering every single way of working. That > > are about 650 executables ... :). Don't get me wrong, but assuming that > > nope. didn't mean to run them all. :) just compile them. > > > this is *done* by someone is just plainly wrong. Noone does that, and > > the number of executables that are not doing anything but spitting out > > errors is probebly proving this point. (Examples: everything in regards > > of evas-3d, evas-object-manipulation, evas-textblock-obstacles renders > > text over and over again) > > > > >> 2) The API is checked anyways in the tests, thus this is just useless > > >> wasted compile time > > > > > > certainly only a percentage of our api is tested in tests... a > smallish one. > > > > Mhmm quickly checking API coverage with and without examples build is > > proving that you are wrong with this, the only APIs that are not used in > > tests is the evas-3d stuff. > > at least as far as our test are concerned (test suites) ethumb has no > tests - it > only has examples. same with ephysics. the elementary examples arfe > definitely > more plentiful than tests. elm_win_activate(), elm_win_lower(), > elm_win_borderless_get(), elm_win_borderless_set(), > elm_win_shaped_get()... in > fact the elm win test uses an incredibly small number of api's vs the > example. > yes - sure. we have elementary_test testing almost all of these though, but > relying on the test suites to cover all of our api i don't think flies > right > now. that is my point. removing examples removes > > > >> 3) Our examples simply don't build. check out the ephysics stuff :) > > > > > > that's bad - so moving things that don't build somewhere else will fix > > > that? :) > > > > No - but it proves my point that having them in tree is pointless > > because noone tests them :) > > true - so maybe they should build by default... :) > > > >> 4) We are talking about the efl.git repository, i would try to keep > > >> software in there that works. Everything else looks dubious. > > > > > > that is true, but perhaps the examples should be fixed, not removed? :) > > > > They should be fixed since a long time - and it does not happen, if it > > happens now then they are located alongside our other examples (and as > > shown below, more usefull to the user) > > > > > > > >> 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 > > > > > > they have to now fight to FIND another repo too. maybe if you wanted it > > > easier move examples out of src into the top level? so you lone and > there > > > is an examples dir right in front of you when you run ls.... i'm pretty > > > sure making it another repo is harder to find examples than this... :) > > > > ANOTHER repository, that is called examples.git, thats unpossible to > > find, and noone will ever imagen that there are examples in the > > examples.git repository ... :) Are you serious ? (And your point with > > no - i'm saying that someone who is looking for efl examples probably is > looking for the examples in a split out package or in the efl package > installed, or they go grab the efl src and look at the tree - they are less > likely to find the examples git repo vs the efl one or whats packaged as > part > of the efl build (as simotek just said). :) > > > having them in the root directory - yes, take a look at > > > https://git.enlightenment.org/tools/examples.git/tree/?h=devs/bu5hm4n/examples > ) > > > > >> 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 > > > > > > every example could be an autofoo style subproject with its own > configure.ac > > > -or same kind of thing with meson so an example can be taken as a > project > > > skeleton. when it';s in our out of tree/repo doesn't make a difference > > > here. if its an out of tree examples repo with a single big build then > it's > > > the same - a big set of build files to wade through for a small single > > > "app" you want. it's just how you structure the build rather than what > > > trees things are in. :) > > > > > > > Could be - but it is not, and as long as this is the case 3) hits. > > > > >> 3) Compiling against the installed version of efl is different from > > >> compiling against something in-tree. Header wise, and dependency wise. > > > > > > indeed that is true. it's also a problem for us with running things > like > > > edje_cc, eolian_gen etc. from within our tree when we build. we have > special > > > casing of module handling just for when running in the tree. if our > tree > > > resembled the installation pretty much exactly... then life would be > far > > > simpler. :) > > > > > >> 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. > > > > > > this is true and they should not do that. but that is orthogonal to > being > > > in or out of tree. :) > > > > No its not - having it intree gives you the possibility of doing that, > > having it out of tree simply does not. > > they could happily use some local duplicate of the autoconf checks and > config.h > in examples when they don't need to at all. moving the examples over means > removing the ifdefs anyway and that work can be done without moving them > over > to achieve the same goal. that's why i call is orthogonal. the ifdefs are > not > needed to live in-tree. most should never have been there. some are just > ifdefs > to show examples specific things if efl compiled them. > > > >> TLDR;: > > >> So all in all. Can we stop adding replies to this thread that impose > no > > >> objection nor agreement, but rather just continue... ? :) > > > > > > maybe you didn't see that i'm saying there are downsides to moving the > > > examples out of tree and i highly suspect they will just bitrot in the > > > examples tree and now provide less value in checking if we break stuff. > > > especially anything that touched so/interfaces will rot fast. > > > > > > > I saw that you are saying that there are downsides, but I also see that > > every argument for a downside is basically invalid :) > > i would disagree. but ok - move them out and in 2 years form now let's see > if > they still compile. they shall have bitrotted i bet by then. > > > We can easily counter the bitrotting with having them in CI ... so we > > always know its state, and can revert neccessary commits :) > > good luck with that. > > > > if they are just moved out as-is then broken examples that don't build > are > > > still broken. they need fixing anyway. i agree that having broken > stuff is > > > bad > > > - isn't fixing that a better idea? :) yes - compiling a bunch of > examples > > > takes more time. as does running test suites and compiling those. QA > takes > > > time. that can be handled via build options to have a fast path build > or a > > > "add all the QA bits" option etc. ... :) > > > > Yeah - see > > > https://git.enlightenment.org/tools/examples.git/tree/?h=devs/bu5hm4n/examples > > > > Its basically sorting and fixing what is there - and searching for > > resources that are missing for some time. I see absolutly no value in > > fixing those things in-tree, where its not understandable how the > > examples are assembled. > > Those things should be usefull and obvious to new users ... which is IMO > > better in the form you can see them there. > > build system specifics honestly are not something a scope that an example > is > showing off. it's a necessary evil. there are already docs on the autofoo > setup > needed to use efl and it's the same regardless of what you write. drop in > whatever example file u like as the src file and it would work (except some > that do edje_cc etc. - just need templates/samples for that too). > > but ok- remove them... let the bitrot come. > > > > > > >> Greetings, > > >> bu5hm4n > > >> > > >>>>> Xavi > > >>>>> > > >>>>> On Tue, 30 Oct 2018 at 02:02, Carsten Haitzler < > ras...@rasterman.com> > > >>>>> wrote: > > >>>>> > > >>>>>> On Mon, 29 Oct 2018 19:18:06 +0100 Marcel Hollerbach < > m...@bu5hm4n.de> > > >>>>>> said: > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On 10/29/18 7:08 PM, Carsten Haitzler (The Rasterman) wrote: > > >>>>>>>> On Mon, 29 Oct 2018 18:02:58 +0100 Marcel Hollerbach > > >>>>>>>> <m...@bu5hm4n.de> > > >>>>>> said: > > >>>>>>>> > > >>>>>>>>> Hello, > > >>>>>>>>> > > >>>>>>>>> A while ago the examples from the efl.git repository were > migrated > > >>>>>>>>> to examples.git [1]. However - right now the examples in the > > >>>>>>>>> efl.git are still there. Is it okay for everyone that we will > > >>>>>>>>> remove those > > >>>>>> examples > > >>>>>>>>> from the main efl.git repository but have them in the > examples.git ? > > >>>>>>>>> > > >>>>>>>>> Greetings, > > >>>>>>>>> bu5hm4n > > >>>>>>>>> > > >>>>>>>>> [1]:https://git.enlightenment.org/tools/examples.git/ > > >>>>>>>> > > >>>>>>>> hmmm - these acted as nice build checks. having them out of the > efl > > >>>>>> tree > > >>>>>>>> makes that no longer be in sync... :/ > > >>>>>>> > > >>>>>>> This is true. However, those examples have been broken before, > even if > > >>>>>>> in-tree, they don't build per default. Also they only check for > API > > >>>>>>> breaks, no behaviour changes etc, those API breaks will(at > least) be > > >>>>>>> found by the ABI-checker. And last but not least, the > examples.git > > >>>>>>> repository can still be build on CI. > > >>>>>> > > >>>>>> catching api/abi breaks via compilation when they happen as you > build > > >>>>>> is nicer > > >>>>>> than the abi checker at release time though... :) > > >>>>>> > > >>>> > > >>>> You don't catch them right now via compilation either, as those are > not > > >>>> compiled per default. So what i am suggesting is that we simply > hook up > > >>>> the examples in the CI and build them there. This will additionally > also > > >>>> catch installtion errors. > > >>>> > > >>>>>>> Greetings, > > >>>>>>> bu5hm4n > > >>>>>>> > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> 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" > > >>>>>> -------------- Carsten Haitzler - ras...@rasterman.com > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> enlightenment-devel mailing list > > >>>>>> enlightenment-devel@lists.sourceforge.net > > >>>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >>>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> enlightenment-devel mailing list > > >>>>> enlightenment-devel@lists.sourceforge.net > > >>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >>>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> enlightenment-devel mailing list > > >>>> enlightenment-devel@lists.sourceforge.net > > >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >>>> > > >>> > > >>> > > >> > > >> > > >> _______________________________________________ > > >> enlightenment-devel mailing list > > >> enlightenment-devel@lists.sourceforge.net > > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >> > > > > > > > > > > > > _______________________________________________ > > 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" -------------- > Carsten Haitzler - ras...@rasterman.com > > > > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
