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. > 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. > 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? :) > 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? :) > 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... :) > 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. :) > 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. :) > 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. 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. ... :) > 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 > -- ------------- 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
