On 08/05/15 10:53, Cedric BAIL wrote: > On Fri, May 8, 2015 at 11:41 AM, Tom Hacohen <[email protected]> wrote: >> On 08/05/15 10:36, Cedric BAIL wrote: >>> On Thu, May 7, 2015 at 4:10 PM, Tom Hacohen <[email protected]> wrote: >>>> This is a bad idea and not flexible. We've already been talking about it >>>> in private, too bad that it has been pushed like that. >>>> >>>> The thing is, this is very inflexible and has to be manually updated. It >>>> doesn't let you do things like testing specific sub modules like >>>> "textblock", which can be done by calling the test suite, and it needs >>>> to be manually updated. It's quite simple to do it nicely (already >>>> suggested it in private) with a simple (automatic) ./check.sh script. >>> >>> I still think you are wrong ! The current tests suite provide all the >>> flexibility you need as Srivardan pointed out and it is trivial to do >>> your check.sh once we have make check-build. Still yours is not as >>> flexible, as you can't run multiple check at once. Also the next patch >>> that would improve the overall system would provide the support for a >>> fnmatch rules, something along the line of EFL_TESTS="*text*" and that >>> would just run in all efl tests suite only things that are related to >>> text. >>> >>> I am not dismissing what you are asking for. check.sh would be at >>> least useful to you, but it won't provide what I am looking for, a >>> fast check covering an entire topic (I usually care more about >>> coverage than just one small tests case as when I do change something >>> it usually has side effect in random place). That's pretty much >>> orthogonal. >> >> I'm not really that set on check.sh. I'm just concerned about having to > > Well, check.sh will just be an helper that set environment variable so > you don't need to remember them. I am sure it will be useful ;-) > >> manually update make check-*. I had no idea about the env vars, they do >> provide the flexibility we need. However then, we don't need make >> check-evas any more, do we? We can just filter with the env vars... > > The idea behind make check-evas and friends is that you could do 'make > check-evas check-edje' in one go. Added in the filter stuff and we > would have a way to do tests coverage on one larger area. As in the > long term we are going to merge elementary and more library in, I > think it makes sense to handle that this way. > >> All I'm saying is that make is not flexible at all, trying to force make >> into dealing with it sounds like a dead end, or at least, a painful route. > > The Makefile.am change where pretty straigh forward and are an > absolute triviality to maintain. Did you look at the patch ?
Yes, of course I have, but it is still manual update. I hate repeating myself (i.e manually updating things). :( -- Tom. ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
