Re: [gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass

2013-02-26 Thread Michał Górny
On Tue, 12 Feb 2013 18:42:28 +0100
""Paweł Hajdan, Jr.""  wrote:

> On 2/11/13 11:14 PM, Michał Górny wrote:
> > My patches introduce a single wrapper with argv-as-parameter syntax.
> > That is, the fore-mentioned example would look like:
> > 
> > virtualx run_tests --foo
> 
> Maybe we can just adapt Ubuntu's (I think) xvfb-run? More
> standardization == profit.

That's probably a good idea. However, I just stepped up here to
replace the ugly API with something better. I think the actual eclass
maintainers should have the final word here.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass

2013-02-13 Thread Gilles Dartiguelongue
Le lundi 11 février 2013 à 23:48 +0100, Diego Elio Pettenò a écrit :
> I'd say, "Go for it!"
> 
> But on the other hand I wonder if it might make sense to have
> something more generic, so that one only has to call something in a
> way such as
> 
> virtualx_setup
> run_tests --foo
> virtualx_cleanup

This sounds nice but is imho but can be elaborated later on.


-- 
Gilles Dartiguelongue 
Gentoo




Re: [gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass

2013-02-12 Thread Paweł Hajdan, Jr.
On 2/11/13 11:14 PM, Michał Górny wrote:
> My patches introduce a single wrapper with argv-as-parameter syntax.
> That is, the fore-mentioned example would look like:
> 
>   virtualx run_tests --foo

Maybe we can just adapt Ubuntu's (I think) xvfb-run? More
standardization == profit.

Thank you for working on this!

Paweł




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass

2013-02-11 Thread Andreas K. Huettel
Am Montag, 11. Februar 2013, 23:14:38 schrieb Michał Górny:
> 
> What are your thoughts?

Same as Diego I like the general idea, but an even more generic framework 
might make sense. Say test dbus session, say setting up some test file 
structure, ...

Oh, and one more thing... please before you commit anything talk to the kde 
guys... we inherit virtualx.eclass everywhere via kde4-*.eclass so we can 
easily use it (and many many kde packages need it for the tests). Changes in 
virtualx.eclass already broke many kde packages once...

[IMHO I'd say it's perfectly fine if you determine the best way to go without 
specific kde regression testing, but before it goes in we'd like to have a 
chance to adapt our eclasses...]


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass

2013-02-11 Thread Diego Elio Pettenò
I'd say, "Go for it!"

But on the other hand I wonder if it might make sense to have
something more generic, so that one only has to call something in a
way such as

virtualx_setup
run_tests --foo
virtualx_cleanup

The reason why I'm wondering this is that we need some more "virtual
environments" for testing purposes, really: so many packages need a
D-Bus session (and I'd rather have them using a test session than a
system one!), and at least in Ruby world we often need a database
(sometimes more than one)...
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/


On Mon, Feb 11, 2013 at 11:14 PM, Michał Górny  wrote:
> Hello, fellow developers,
>
> The current virtualx.eclass API is a bit insane. It seems a bit like
> stacking of a few next APIs, mostly designed to quickly run 'make
> check', then extended to general functions.
>
> For example running a function 'run_tests' with parameter '--foo' would
> look like:
>
> VIRTUALX_COMMAND=run_tests virtualmake --foo
>
> which is really awful, considering that '--foo' is a parameter to
> 'run_tests' and not virtualmake.
>
> My patches introduce a single wrapper with argv-as-parameter syntax.
> That is, the fore-mentioned example would look like:
>
> virtualx run_tests --foo
>
> Depending on the maintainer decisions and your feedback, I believe that
> even all the X* short-hand functions could be deprecated. They are a bit
> shorter:
>
> Xemake check
>
> vs:
>
> virtualx emake check
>
> but I don't think that's much of a difference.
>
> What are your thoughts?
>
>



[gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass

2013-02-11 Thread Michał Górny
Hello, fellow developers,

The current virtualx.eclass API is a bit insane. It seems a bit like
stacking of a few next APIs, mostly designed to quickly run 'make
check', then extended to general functions.

For example running a function 'run_tests' with parameter '--foo' would
look like:

VIRTUALX_COMMAND=run_tests virtualmake --foo

which is really awful, considering that '--foo' is a parameter to
'run_tests' and not virtualmake.

My patches introduce a single wrapper with argv-as-parameter syntax.
That is, the fore-mentioned example would look like:

virtualx run_tests --foo

Depending on the maintainer decisions and your feedback, I believe that
even all the X* short-hand functions could be deprecated. They are a bit
shorter:

Xemake check

vs:

virtualx emake check

but I don't think that's much of a difference.

What are your thoughts?