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
you patch something, while remembering every single way of working. That
are about 650 executables ... :). Don't get me wrong, but assuming that
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.
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 :)
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
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.
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 :)
We can easily counter the bitrotting with having them in CI ... so we
always know its state, and can revert neccessary commits :)
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.
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
