On Fri, 2 Nov 2018 15:14:01 +0100 Xavi Artigas <xavierarti...@gmail.com> said:
> 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. ok - you mean more specifically he submitted a patch for review to do it.. .it hasn't actually been done and made it to master :) right? > 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 > -- ------------- 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
