FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 08-22-2010, 09:32 PM
Tomáš Chvátal
 
Default New eclass: scons.eclass

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 22.8.2010 23:18, Mike Frysinger napsal(a):
> On Sunday, August 22, 2010 17:10:32 Tomáš Chvátal wrote:
>> Dne 22.8.2010 23:06, Mike Frysinger napsal(a):
>>>> scons_use()
>>>
>>> keep the use_xxx style ... so rename it to "use_scons()"
>>
>> Hmm we use
>> cmake-utils_use_*
>>
>> i think use_cmake-utils-*
>>
>> also if renamed to cmake_use-* it would look more sane than use_cmake-*
>>
>> but if we make agreement other way we can replace it in cmake utils
>> quite easily
>
> changing eclass style to match the older-than-PMS style sounds more feasible.
> so i'd go with use_cmake-xxx.
> -mike
Do we have some poll capabilites only for devs? Something on forums?

We can do either way and provide backcompat -> not so hard So i would
leave decision to the peepz.

I dont care whether i use cmake-utils_use_enable or use_cmake_enable

Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxxl1sACgkQHB6c3gNBRYcxqQCcDkf2REdWYu LUy1/e5OsgUJzd
EsQAnihzaLyq+Jgf+g6kR0O8Y9kDw5Zh
=wjUC
-----END PGP SIGNATURE-----
 
Old 08-22-2010, 10:03 PM
Mike Frysinger
 
Default New eclass: scons.eclass

On Sunday, August 22, 2010 17:32:11 Tomáš Chvátal wrote:
> Dne 22.8.2010 23:18, Mike Frysinger napsal(a):
> > On Sunday, August 22, 2010 17:10:32 Tomáš Chvátal wrote:
> >> Dne 22.8.2010 23:06, Mike Frysinger napsal(a):
> >>>> scons_use()
> >>>
> >>> keep the use_xxx style ... so rename it to "use_scons()"
> >>
> >> Hmm we use
> >> cmake-utils_use_*
> >>
> >> i think use_cmake-utils-*
> >>
> >> also if renamed to cmake_use-* it would look more sane than use_cmake-*
> >>
> >> but if we make agreement other way we can replace it in cmake utils
> >> quite easily
> >
> > changing eclass style to match the older-than-PMS style sounds more
> > feasible. so i'd go with use_cmake-xxx.
>
> Do we have some poll capabilites only for devs? Something on forums?

i think we only have the forums

> We can do either way and provide backcompat -> not so hard So i would
> leave decision to the peepz.
>
> I dont care whether i use cmake-utils_use_enable or use_cmake_enable

so we're clear, lemme phrase it this way: use_enable/use_with/use_xxx isnt
changing. whether you choose to rename the cmake eclasses to follow the
existing standard is up to you. personally, i think "use_cmake_enable" makes
the most sense (or dare i suggest "use_enable_cmake" ...).

transitional backwards compat shouldnt be hard. ewarn should dump to stderr
which means you should be able to use it in existing functions without
breaking people.
-mike
 
Old 08-23-2010, 03:11 PM
Michał Górny
 
Default New eclass: scons.eclass

On Sun, 22 Aug 2010 23:03:44 +0200
Maciej Mrozowski <reavertm@gmail.com> wrote:

> I'd suggest providing all src_* phases except src_unpack.

Providing a blank src_configure() would be fine but...

> Even src_prepare that calls base_src_prepare - to get PATCHES and
> epatch_user support - for simplicity requiring EAPI-2 as providing
> src_unpack in buildsystem eclasses is a bad design (like providing
> src_prepare in scm eclasses - this one is yet to be fixed).

Why would I do that? If an ebuild needs to use base_src_prepare(), why
can't it simply inherit the base eclass? Nothing buildsystem-specific
needs to be done in src_prepare() here.

And requiring EAPI=2 is even more pointless as SCons doesn't mostly
distinguish between 'configure' and 'build' phases.

> Also calling base_src_install in scons_src_install if possible would
> be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils,
> autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses.

Even more pointless. Although we can assume many of the SConstruct
files use the name 'install' for their 'install' target, we can't do
that for 'DESTDIR' or how a particular project calls it. Not to mention
some don't provide such a thing at all. Every SCons-based ebuild should
redefine src_install().

--
Best regards,
Michał Górny

<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>
 
Old 08-23-2010, 04:24 PM
Michał Górny
 
Default New eclass: scons.eclass

On Sun, 22 Aug 2010 20:39:23 +0200
Michał Górny <gentoo@mgorny.alt.pl> wrote:

The third revision, almost all suggestions applied. The ChangeLog:

151ddf2 Support passing a flag list to scons_clean_makeopts().
82a3ee7 Output the resulting flag list in scons_clean_makeopts()
instead of assigning it.
8062ec7 Provide a blank src_configure() for EAPI 2+.
33b4406 Drop default pkg_setup() -- no longer necessary.
44188e0 escons(): set SCONSOPTS implicitly if they are unset.
0f2ea92 Fix tests to use underscores in function names.
ccf1ef9 Introduce SCONSOPTS and use it instead of MAKEOPTS.
501ba41 Rename scons_use() to use_scons(), and the related vars.
681d73f Print the complete SCons command line in escons().
194e52e Use @DEFAULT-UNSET.
42aec9f Remove incorrect @CODE use.

Attaching the eclass r3 and a diff against r2.

--
Best regards,
Michał Górny

<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>
 
Old 08-23-2010, 04:39 PM
Mike Frysinger
 
Default New eclass: scons.eclass

On Monday, August 23, 2010 12:24:54 Michał Górny wrote:
> The third revision, almost all suggestions applied. The ChangeLog:

if there are suggestions you've actively ignored, those should be noted

> 44188e0 escons(): set SCONSOPTS implicitly if they are unset.
> ccf1ef9 Introduce SCONSOPTS and use it instead of MAKEOPTS.

i'm not sure caching the value and using it in between runs is a good idea.
unless you also cache the thing you're caching and compare it to make sure
your cache is no longer invalid.

i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every escons
invocation, make sure ${MAKEOPTS} hasnt changed in which case you need to
regenerate it. or just avoid the cache altogether and leave SCONSOPTS as a
hook specific to scons.
-mike
 
Old 08-23-2010, 05:16 PM
Michał Górny
 
Default New eclass: scons.eclass

On Mon, 23 Aug 2010 12:39:50 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Monday, August 23, 2010 12:24:54 Michał Górny wrote:
> > The third revision, almost all suggestions applied. The ChangeLog:
>
> if there are suggestions you've actively ignored, those should be
> noted

I've replied to the specific suggestions but if you want, here's a
short summary:
- stripping ! from varname in use_scons() suggestion (I don't see a
real point there as I replied you),
- src_prepare() calling base_src_prepare() (it is better to inherit
base within the specific ebuild),
- src_install() calling base_src_install() (the base.eclass
implementation calls make).

> i'm not sure caching the value and using it in between runs is a good
> idea. unless you also cache the thing you're caching and compare it
> to make sure your cache is no longer invalid.
>
> i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every escons
> invocation, make sure ${MAKEOPTS} hasnt changed in which case you
> need to regenerate it. or just avoid the cache altogether and leave
> SCONSOPTS as a hook specific to scons.

Can do, though I don't see a reason why anyone would mangle MAKEOPTS in
a middle of an ebuild using SCons.

PS Why don't your mails contain 'Reply-To' header like others do?

--
Best regards,
Michał Górny

<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>
 
Old 08-23-2010, 05:36 PM
Maciej Mrozowski
 
Default New eclass: scons.eclass

On Monday 23 of August 2010 17:11:47 Michał Górny wrote:
> On Sun, 22 Aug 2010 23:03:44 +0200
>
> Maciej Mrozowski <reavertm@gmail.com> wrote:
> > I'd suggest providing all src_* phases except src_unpack.
>
> Providing a blank src_configure() would be fine but...
>
> > Even src_prepare that calls base_src_prepare - to get PATCHES and
> > epatch_user support - for simplicity requiring EAPI-2 as providing
> > src_unpack in buildsystem eclasses is a bad design (like providing
> > src_prepare in scm eclasses - this one is yet to be fixed).
>
> Why would I do that? If an ebuild needs to use base_src_prepare(), why
> can't it simply inherit the base eclass? Nothing buildsystem-specific
> needs to be done in src_prepare() here.
> And requiring EAPI=2 is even more pointless as SCons doesn't mostly
> distinguish between 'configure' and 'build' phases.

Because if you're to provide src_prepare, for EAPI<2 you need to provide
src_unpack as well but it's wrong in buildsystem eclasses as I already pointed
out (since src_unpack:EAPI1 -> src_unpack:EAPI2 + src_prepare:EAPI2), and
requiring EAPI-2 allows you to avoid it.
If you don't care for PATCHES or user_patches and hence compliance with other
buildsystem eclasses, feel free.

> > Also calling base_src_install in scons_src_install if possible would
> > be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils,
> > autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses.
>
> Even more pointless. Although we can assume many of the SConstruct
> files use the name 'install' for their 'install' target, we can't do
> that for 'DESTDIR' or how a particular project calls it. Not to mention
> some don't provide such a thing at all. Every SCons-based ebuild should
> redefine src_install().

Like I said, if you don't care for consistency with the rest, feel free to
ignore.
If SCons is unpredictable, then don't provide *any* phases and only functions
and rename it to scons-utils to match its purpose (we're quite likely planning
to rename cmake-utils.eclass to cmake.eclass for said consistency,
unfortunately it was introduced in first place with such name and provided
phases).
What I hate is deliberately introduced inconsistency in ebuild API's.

--
regards
MM
 
Old 08-23-2010, 08:22 PM
Mike Frysinger
 
Default New eclass: scons.eclass

On Monday, August 23, 2010 13:16:38 Michał Górny wrote:
> On Mon, 23 Aug 2010 12:39:50 -0400 Mike Frysinger wrote:
> > i'm not sure caching the value and using it in between runs is a good
> > idea. unless you also cache the thing you're caching and compare it
> > to make sure your cache is no longer invalid.
> >
> > i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every escons
> > invocation, make sure ${MAKEOPTS} hasnt changed in which case you
> > need to regenerate it. or just avoid the cache altogether and leave
> > SCONSOPTS as a hook specific to scons.
>
> Can do, though I don't see a reason why anyone would mangle MAKEOPTS in
> a middle of an ebuild using SCons.

i agree, but you might as have it work properly in all cases instead of
flaking out randomly on ebuild authors. i think someone told me something
similar recently in a bug report about cvs.eclass ......

> PS Why don't your mails contain 'Reply-To' header like others do?

you can subscribe to a list but have delivery turned off
-mike
 
Old 08-23-2010, 11:02 PM
Michał Górny
 
Default New eclass: scons.eclass

On Mon, 23 Aug 2010 16:22:35 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Monday, August 23, 2010 13:16:38 Michał Górny wrote:
> > On Mon, 23 Aug 2010 12:39:50 -0400 Mike Frysinger wrote:
> > > i'm not sure caching the value and using it in between runs is a
> > > good idea. unless you also cache the thing you're caching and
> > > compare it to make sure your cache is no longer invalid.
> > >
> > > i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every
> > > escons invocation, make sure ${MAKEOPTS} hasnt changed in which
> > > case you need to regenerate it. or just avoid the cache
> > > altogether and leave SCONSOPTS as a hook specific to scons.
> >
> > Can do, though I don't see a reason why anyone would mangle
> > MAKEOPTS in a middle of an ebuild using SCons.
>
> i agree, but you might as have it work properly in all cases instead
> of flaking out randomly on ebuild authors.

We're hitting another corner case then. What if user modifies SCONSOPTS
in the middle of an ebuild? We could export another variable keeping
resulting SCONSOPTS and comparing it with the current SCONSOPTS -- but
what if the ebuild author randomly hit the same flags that resulted
from MAKEOPTS->SCONSOPTS conversion (and changed MAKEOPTS at the same
time)?

If we consider it like that, we end up with the idea that re-generating
SCONSOPTS every time escons() is called is the only feasible solution
-- but I don't really think it is worth to waste the time considering
it.

--
Best regards,
Michał Górny

<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>
 
Old 08-23-2010, 11:27 PM
Mike Frysinger
 
Default New eclass: scons.eclass

On Monday, August 23, 2010 19:02:21 Michał Górny wrote:
> On Mon, 23 Aug 2010 16:22:35 -0400 Mike Frysinger wrote:
> > On Monday, August 23, 2010 13:16:38 Michał Górny wrote:
> > > On Mon, 23 Aug 2010 12:39:50 -0400 Mike Frysinger wrote:
> > > > i'm not sure caching the value and using it in between runs is a
> > > > good idea. unless you also cache the thing you're caching and
> > > > compare it to make sure your cache is no longer invalid.
> > > >
> > > > i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every
> > > > escons invocation, make sure ${MAKEOPTS} hasnt changed in which
> > > > case you need to regenerate it. or just avoid the cache
> > > > altogether and leave SCONSOPTS as a hook specific to scons.
> > >
> > > Can do, though I don't see a reason why anyone would mangle
> > > MAKEOPTS in a middle of an ebuild using SCons.
> >
> > i agree, but you might as have it work properly in all cases instead
> > of flaking out randomly on ebuild authors.
>
> We're hitting another corner case then. What if user modifies SCONSOPTS
> in the middle of an ebuild? We could export another variable keeping
> resulting SCONSOPTS and comparing it with the current SCONSOPTS -- but
> what if the ebuild author randomly hit the same flags that resulted
> from MAKEOPTS->SCONSOPTS conversion (and changed MAKEOPTS at the same
> time)?
>
> If we consider it like that, we end up with the idea that re-generating
> SCONSOPTS every time escons() is called is the only feasible solution
> -- but I don't really think it is worth to waste the time considering
> it.

then keep it simple and separate:
escons() {
debug-print-function ${FUNCNAME} "${@}"

set -- scons $(scons_clean_makeopts) ${SCONSOPTS} ${EXTRA_ESCONS} "${@}"
echo "${@}" >&2
"${@}"
}

now you dont have to worry about changes between invocations and the developer
has a clear path -- if they need to force a serial build for example, they can
either append MAKEOPTS, SCONSOPTS, or pass it straight to escons. no cache
confusion or desync between the vars.
-mike
 

Thread Tools




All times are GMT. The time now is 07:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org