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
