[gentoo-dev] new old eclass - wxwidgets.eclass

[gentoo-dev] new old eclass - wxwidgets.eclass

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

since everyone is getting into the reviewing mood, i thought it
would be a good time to get some opinions on the wxwidgets 
eclass rewrite i've done.

it's pretty simple and i hope the docs make it self-explanatory.
a couple things:

- is the stuff in global scope kosher?  i've seen other eclasses do
similar, but i want to be sure.  the reason for the looping is because
i figure calling built_with_use in global would get me hung.

- wxGTK-2.8 will drop the unicode USE flag since it only builds the unicode
libraries now (ie. no more ansi).  thus the reason the `check_wxuse unicode`
calls are conditional on WX_GTK_VER=2.6.

- the lack of pink ponies troubles me.  but how much is too much?

-- 
                  fonts / wxWindows / gcc-porting / treecleaners
  9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

[-- Attachment #2: wxwidgets.eclass --]
[-- Type: text/plain, Size: 6867 bytes --]

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

#
#	NOTE - WORK IN PROGRESS

# @ECLASS:			wxwidgets.eclass
# @MAINTAINER:
#  dirtyepic@gentoo.org
#  wxwindows@gentoo.org
# @BLURB:			Manages build configuration for wxGTK-using packages.
# @DESCRIPTION:
#  The wxGTK libraries come in several different possible configurations
#  (release/debug, ansi/unicode, etc.), most of which can be installed
#  side-by-side.  The purpose of this eclass is to give ebuilds the ability to
#  specify what particular flavour they require to build against without
#  interfering with the user-set system configuration.
#
#  Ebuilds that use wxGTK must inherit this eclass.  Otherwise the system
#  default will be used, which would be anything the user set it to.
#
#  Ebuilds are also required set the global variable WX_GTK_VER, containing the
#  wxGTK SLOT the ebuild requires.
#
#
#  Simple Usage:
#
#   inherit wxwidgets
#   DEPEND="=x11-libs/wxGTK-2.6*"
#   WX_GTK_VER="2.6"
#
#  That's it.  The eclass will select a sane default configuration to use.  In
#  wxGTK-2.6 the default is ansi.  In wxGTK-2.8 and later it's unicode.  These
#  are the defaults because they are always guaranteed to exist.  (Note: we lock
#  the DEPEND to the needed SLOT to prevent another SLOT from fulfilling the
#  dependency.)
#
#  You'll often find yourself in need of a bit more control.  For that see the
#  need-wxwidgets function below.

inherit eutils flag-o-matic multilib

# We do this globally so ebuilds can get sane defaults just by inheriting.  They
# can be overridden with need-wxwidgets later if need be.

if [[ -n ${WX_GTK_VER} ]]; then
	if [[ ${WX_GTK_VER} == 2.6 ]]; then
		wxchar="ansi"
	elif [[ ${WX_GTK_VER} == 2.8 ]]; then
		wxchar="unicode"
	else
		:
	fi

	for wxtoolkit in gtk2 base; do
		debug-print "global outer loop - wxtoolkit is ${wxtoolkit}"
		for wxdebug in release debug; do
			debug-print "global inner loop - wxdebug is ${wxdebug}"
			wxconf="${wxtoolkit}-${wxchar}-${wxdebug}-${WX_GTK_VER}"
			debug-print "testing for config ${wxconf}"
			[[ -f /usr/$(get_libdir)/wx/config/${wxconf} ]] || continue
			debug-print "found config ${wxconf} - setting WX_CONFIG"
			WX_CONFIG="/usr/$(get_libdir)/wx/config/${wxconf}"
			# TODO: needed for the wx-config wrapper
			#WX_ECLASS_CONFIG="${WX_CONFIG}"
			break
		done
		[[ -n ${WX_CONFIG} ]] && break
	done
	[[ -n ${WX_CONFIG} ]] && export WX_CONFIG #WX_ECLASS_CONFIG
else
	:
fi


# @FUNCTION:		need-wxwidgets
# @USAGE:			<configuration>
# @DESCRIPTION:
#  need-wxwidgets is called with one argument, the wxGTK configuration to use.
#
#  Available configurations are:
#
#		ansi
#		unicode
#		base-ansi
#		base-unicode
#
#  Note that in >=wxGTK-2.8, only the unicode versions are available.  The
#  eclass will automatically map ansi to unicode if WX_GTK_VER is set to 2.8 or
#  later.
#
#  There are two other configurations, gtk2 and base, which correspond with ansi
#  and base-ansi.  They are around for historical reasons and shouldn't be used
#  by new ebuilds.
#
#  This function will set the variable WX_CONFIG to the path of the wx-config
#  script to use.  In most cases you shouldn't have to use it since the
#  /usr/bin/wx-config wrapper points to ${WX_CONFIG} when called from portage.

need-wxwidgets() {
	debug-print-function $FUNCNAME $*

	local wxtoolkit wxchar wxdebug wxconf
	append-flags -fno-strict-aliasing

	[[ -n ${WX_GTK_VER} ]] \
		|| _wxerror "WX_GTK_VER must be set before calling"

	if [[ ${WX_GTK_VER} != 2.6 \
	   && ${WX_GTK_VER} != 2.8 ]]; then
		_wxerror "Invalid WX_GTK_VER: ${WX_GTK_VER} - must be set to a valid SLOT"
	fi

	debug-print "WX_GTK_VER is ${WX_GTK_VER}"

	case $1 in
		ansi)
			debug-print-section ansi
			if [[ ${WX_GTK_VER} == 2.6 ]]; then
				wxchar="ansi"
			else
				wxchar="unicode"
			fi
			check_wxuse X
			;;
		unicode)
			debug-print-section unicode
			check_wxuse X
			[[ ${WX_GTK_VER} == 2.6 ]] && check_wxuse unicode
			wxchar="unicode"
			;;
		base-ansi)
			debug-print-section base-ansi
			if [[ ${WX_GTK_VER} == 2.6 ]]; then
				wxchar="ansi"
			else
				wxchar="unicode"
			fi
			;;
		base-unicode)
			debug-print-section base-unicode
			[[ ${WX_GTK_VER} == 2.6 ]] && check_wxuse unicode
			wxchar="unicode"
			;;
		# backwards compatibility
		gtk2)
			debug-print-section gtk2
			if [[ ${WX_GTK_VER} == 2.6 ]]; then
				wxchar="ansi"
			else
				wxchar="unicode"
			fi
			check_wxuse X
			;;
		base)
			debug-print-section base
			if [[ ${WX_GTK_VER} == 2.6 ]]; then
				wxchar="ansi"
			else
				wxchar="unicode"
			fi
			;;
		*)
			_wxerror "called with invalid argument: $1"
			;;
	esac

	debug-print "wxchar is ${wxchar}"

	# since we're no longer in global scope we call built_with_use instead of
	# all the crazy looping

	# base can be provided by both gtk2 and base installations
	if $(built_with_use =x11-libs/wxGTK-${WX_GTK_VER}* X); then
		wxtoolkit="gtk2"
	else
		wxtoolkit="base"
	fi

	debug-print "wxtoolkit is ${wxtoolkit}"

	# debug or release?
	if $(built_with_use =x11-libs/wxGTK-${WX_GTK_VER}* debug); then
		wxdebug="debug"
	else
		wxdebug="release"
	fi

	debug-print "wxdebug is ${wxdebug}"

	# put it all together
	wxconf="${wxtoolkit}-${wxchar}-${wxdebug}-${WX_GTK_VER}"

	debug-print "wxconf is ${wxconf}"

	# if this doesn't work, something is seriously screwed
	if [[ ! -f /usr/$(get_libdir)/wx/config/${wxconf} ]]; then
		_wxerror "Failed to find configuration ${wxconf}"
	fi

	debug-print "Found config ${wxconf} - setting WX_CONFIG"

	# This is exported as some configure scripts will check for its presence in
	# the environment.
	export WX_CONFIG="/usr/$(get_libdir)/wx/config/${wxconf}"
	# Some more for good measure (seen in the wild)
	export WXCONFIG="${WX_CONFIG}"
	export WX_CONFIG_NAME="${wxconf}"

	debug-print "WX_CONFIG is ${WX_CONFIG}"

	# TODO: Used by the wx-config wrapper
	#export WX_ECLASS_CONFIG="${WX_CONFIG}"

	echo
	ewarn "Requested:        ${1} ${WX_GTK_VER}"
	ewarn "Using:            ${wxconf}"
	echo
}


# @FUNCTION:		check_wxuse
# @USAGE:			<USE flag>
# @DESCRIPTION:
#  Provides a consistant way to check if wxGTK was built with a particular USE
#  flag enabled.

check_wxuse() {
	debug-print-function $FUNCNAME $*

	[[ -n ${WX_GTK_VER} ]] \
		|| _wxerror "WX_GTK_VER must be set before calling"


	ebegin "Checking wxGTK-${WX_GTK_VER} for ${1} support"
	if $(built_with_use =x11-libs/wxGTK-${WX_GTK_VER}* ${1}); then
		eend 0
	else
		eend 1
		echo
		eerror "${FUNCNAME} - You have requested functionality that requires ${1} support to"
		eerror "have been built into x11-libs/wxGTK."
		eerror
		eerror "Please re-merge =x11-libs/wxGTK-${WX_GTK_VER}* with the ${1} USE flag enabled."
		die "Missing USE flags."
	fi
}


# internal error function
# TODO - make pretties
_wxerror() {
	echo
	eerror "${1}"
	echo
	die "${1}"
}

Re: [gentoo-dev] new old eclass - wxwidgets.eclass

[Donnie Berkholz]

On 21:14 Mon 24 Sep     , Ryan Hill wrote:
> - is the stuff in global scope kosher?  i've seen other eclasses do
> similar, but i want to be sure.  the reason for the looping is because
> i figure calling built_with_use in global would get me hung.

> 	for wxtoolkit in gtk2 base; do
> 		debug-print "global outer loop - wxtoolkit is ${wxtoolkit}"
> 		for wxdebug in release debug; do
> 			debug-print "global inner loop - wxdebug is ${wxdebug}"
> 			wxconf="${wxtoolkit}-${wxchar}-${wxdebug}-${WX_GTK_VER}"
> 			debug-print "testing for config ${wxconf}"
> 			[[ -f /usr/$(get_libdir)/wx/config/${wxconf} ]] || continue

Checking for existence of files in global scope?

> 			debug-print "found config ${wxconf} - setting WX_CONFIG"
> 			WX_CONFIG="/usr/$(get_libdir)/wx/config/${wxconf}"
> 			# TODO: needed for the wx-config wrapper
> 			#WX_ECLASS_CONFIG="${WX_CONFIG}"
> 			break
> 		done
> 		[[ -n ${WX_CONFIG} ]] && break
> 	done
> 	[[ -n ${WX_CONFIG} ]] && export WX_CONFIG #WX_ECLASS_CONFIG

OK, so let me try to follow the logic of preferences here:

1. gtk2-release
2. gtk2-debug
3. base-release
4. base-debug

Does that mean they can't get a debug setup if the release one is found? 
Does a debug build only produce debug and not release?

> else
> 	:
> fi

What's up with the 'else' here?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: new old eclass - wxwidgets.eclass

[Ryan Hill]

Donnie Berkholz wrote:
> On 21:14 Mon 24 Sep     , Ryan Hill wrote:
>> - is the stuff in global scope kosher?  i've seen other eclasses do
>> similar, but i want to be sure.  the reason for the looping is because
>> i figure calling built_with_use in global would get me hung.
> 
>> 	for wxtoolkit in gtk2 base; do
>> 		debug-print "global outer loop - wxtoolkit is ${wxtoolkit}"
>> 		for wxdebug in release debug; do
>> 			debug-print "global inner loop - wxdebug is ${wxdebug}"
>> 			wxconf="${wxtoolkit}-${wxchar}-${wxdebug}-${WX_GTK_VER}"
>> 			debug-print "testing for config ${wxconf}"
>> 			[[ -f /usr/$(get_libdir)/wx/config/${wxconf} ]] || continue
> 
> Checking for existence of files in global scope?

Yeah.  These config files work like pkg-config, in that calling, say, 
`gtk2-unicode-release-2.8 --libs` outputs the linker flags needed to link
to those libraries.  We need a way to know what config scripts are available.
This is the least expensive way i could think of, a minimum of one and max of
four stat calls.

I'm also going to drop the debug-prints here as there's too much overhead.
 
>> 			debug-print "found config ${wxconf} - setting WX_CONFIG"
>> 			WX_CONFIG="/usr/$(get_libdir)/wx/config/${wxconf}"
>> 			# TODO: needed for the wx-config wrapper
>> 			#WX_ECLASS_CONFIG="${WX_CONFIG}"
>> 			break
>> 		done
>> 		[[ -n ${WX_CONFIG} ]] && break
>> 	done
>> 	[[ -n ${WX_CONFIG} ]] && export WX_CONFIG #WX_ECLASS_CONFIG
> 
> OK, so let me try to follow the logic of preferences here:
> 
> 1. gtk2-release
> 2. gtk2-debug
> 3. base-release
> 4. base-debug
> 
> Does that mean they can't get a debug setup if the release one is found? 
> Does a debug build only produce debug and not release?

True.  For example the 2.6 ebuild will install one of gtk2-ansi-release-2.6 or 
gtk2-ansi-debug-2.6 depending on the debug USE flag.  With USE="-X" it installs
base-ansi-release-2.6 or base-ansi-debug-2.6.  gtk2 builds provide both the gtk2
and base libraries so are preferred over plain base.

It technically possible to install debug and release builds side-by-side.  In 
fact, the previous version of this eclass was designed around it.  Some invasive
hackery was needed to pull it off though, and we decided not to support it.

>> else
>> 	:
>> fi
> 
> What's up with the 'else' here?

oops, leftover from debugging.  i had an echo in there, then replaced it with 
a no-op and forgot to remove it completely.

> 
> Thanks,
> Donnie

Thanks for taking the time to look at it.

-- 
                  fonts / wxWindows / gcc-porting / treecleaners
  9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new old eclass - wxwidgets.eclass

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 3647 bytes --]

Hello,

On E, 2007-09-24 at 21:14 -0600, Ryan Hill wrote:
> since everyone is getting into the reviewing mood, i thought it
> would be a good time to get some opinions on the wxwidgets 
> eclass rewrite i've done.


I figured I'd reply to the old review request on the list instead of
doing this privately, so here we go.

The notes are based on the latest eclass located at
http://overlays.gentoo.org/dev/dirtyepic/browser/eclass/wxwidgets.eclass
at current revision 6:

* I just assume the documentation markup for the new way of doing eclass
documenting is good. The documentation text itself seems mostly good, if
maybe not so professional. Some nitpicking:

** Ebuilds are also required set the global -> s/required/required to/?

** The description gives the impression we support installation of
release/debug side-by-side - don't think this is true. Maybe we should
think about a way for users to be able to set their own wx-config to a
debug build, but have the system USE flag dependent. Hmm... Maybe I
should revise my stance on debug + release co-existance in some form

** Once 2.8 is in, we should update the simple usage example to that

** With EAPI=1 SLOT depends can be used now, but as wx is always with a
version and SLOT matching a way that * wildcard can be used, it's fine
to not require things to use EAPI=1 indeed I'd say. Just noting.

** In simple usage example I would rather refer to RDEPEND, not DEPEND,
or both


* Perhaps we should take care of setting the wxGTK DEPEND and RDEPEND
ourselves based on a WX_GTK_VER in ebuilds global scope? Might cause
problems for things using wx conditionally for some optional GUI.
Talking of which, it seems it already relies on global scope - does that
work fine with conditional wx usage? need-wxwidgets for that, I guess?
What's the view on eclasses touching DEPEND/RDEPEND these days, anyway?

* Taking care of DEPEND and RDEPEND in the eclass itself could allow us
to migrate things over to wxBase package in the future without any
ebuild migration work, once we fix upstream configure.in to work with a
system provided wxBase libraries and not have file collisions. However
this probably requires a global variable for base-ansi/base-unicode
passing instead of a need-wxwidgets function for that to be possible to
work out

* I hate any unconditional compiler flags workarounds, such as
"append-flags -fno-strict-aliasing". I have some long pending upstream
work to do to simply fix it in that one header where it makes noise and
once that finally gets resolved (or maybe it already is in 2.8), we have
no reason to keep passing this, as to my knowledge it also means less
optimization chances for gcc. Do we have a plan on how to get rid of
that CFLAGS append once the user is dealing with a wx library that has
this fixed?
At least this isn't the configure argument mess we used to have in
wxlib.eclass where you'd get some important class configured out just
because it was broken in an old version :)

* Are you sure we want to ewarn unconditionally on all need-wxwidgets
function calls?

* What's with the TODO on _wxerror() and the function?

The previous points encompass mostly only things noted while going over
the code - I have yet to look at it with a logic and interaction sense.
I figured I'll get this current list off my hands before I get sunk into
work.


Many many thanks for pushing wxGTK forwards while I'm occupied with
work, gnome stuff... and procrastinating

-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] new old eclass - wxwidgets.eclass

[Ryan Hill]

Mart Raudsepp wrote:
> Hello,
> 
> On E, 2007-09-24 at 21:14 -0600, Ryan Hill wrote:
>> since everyone is getting into the reviewing mood, i thought it
>> would be a good time to get some opinions on the wxwidgets 
>> eclass rewrite i've done.
> 
> 
> I figured I'd reply to the old review request on the list instead of
> doing this privately, so here we go.
> 
> The notes are based on the latest eclass located at
> http://overlays.gentoo.org/dev/dirtyepic/browser/eclass/wxwidgets.eclass
> at current revision 6:
> 
> * I just assume the documentation markup for the new way of doing eclass
> documenting is good. The documentation text itself seems mostly good, if
> maybe not so professional. Some nitpicking:

Bah, professionalism is for professionals. ;)
 
> ** Ebuilds are also required set the global -> s/required/required to/?

Yep.
 
> ** The description gives the impression we support installation of
> release/debug side-by-side - don't think this is true. Maybe we should
> think about a way for users to be able to set their own wx-config to a
> debug build, but have the system USE flag dependent. Hmm... Maybe I
> should revise my stance on debug + release co-existance in some form

This is basically what I had previously (though much uglier).  I figured
we might want to rethink it later so I made it simple to re-add again if
we want.  For now though I'd just like to get this out to the public.
 
> ** Once 2.8 is in, we should update the simple usage example to that

For sure.
 
> ** With EAPI=1 SLOT depends can be used now, but as wx is always with a
> version and SLOT matching a way that * wildcard can be used, it's fine
> to not require things to use EAPI=1 indeed I'd say. Just noting.

With EAPI=1 we can also do something like

DEPEND=">=x11-libs/wxGTK-2.6.2:2.6"

which neatly solves our issue with needing a minimum version in a SLOT.

I'll make a note of this in the documentation.
 
> ** In simple usage example I would rather refer to RDEPEND, not DEPEND,
> or both

Hmm?  RDEPEND defaults to DEPEND if not defined but not the other way
around.  I will refer to both though since wxGTK does definitely need
to be in RDEPEND for proper binpkgs.

> * Perhaps we should take care of setting the wxGTK DEPEND and RDEPEND
> ourselves based on a WX_GTK_VER in ebuilds global scope? Might cause
> problems for things using wx conditionally for some optional GUI.
> Talking of which, it seems it already relies on global scope - does that
> work fine with conditional wx usage? need-wxwidgets for that, I guess?
> What's the view on eclasses touching DEPEND/RDEPEND these days, anyway?

I believe this would force everything with an optional wxwidgets USE flag
to require wxGTK.  I never really thought about how the global code affects
the conditional case until now, but considering that all it does is set a
variable if wxGTK is installed it would seem that it could take advantage
of it as well and only call need-wxwidgets if it needs something other than
the default.  Course calling need-wxwidgets is still a good idea.

> * Taking care of DEPEND and RDEPEND in the eclass itself could allow us
> to migrate things over to wxBase package in the future without any
> ebuild migration work, once we fix upstream configure.in to work with a
> system provided wxBase libraries and not have file collisions. However
> this probably requires a global variable for base-ansi/base-unicode
> passing instead of a need-wxwidgets function for that to be possible to
> work out

Yes, that would be a future goal.
 
> * I hate any unconditional compiler flags workarounds, such as
> "append-flags -fno-strict-aliasing". I have some long pending upstream
> work to do to simply fix it in that one header where it makes noise and
> once that finally gets resolved (or maybe it already is in 2.8), we have
> no reason to keep passing this, as to my knowledge it also means less
> optimization chances for gcc. Do we have a plan on how to get rid of
> that CFLAGS append once the user is dealing with a wx library that has
> this fixed?

I believe I added that due to an aliasing bug in the gcc-4.2.0 prerelease.
I think I've since gotten the patch applied to our GCC though so it
shouldn't be a problem to remove.  If we could silence that warning all the
better.

> At least this isn't the configure argument mess we used to have in
> wxlib.eclass where you'd get some important class configured out just
> because it was broken in an old version :)
> 
> * Are you sure we want to ewarn unconditionally on all need-wxwidgets
> function calls?

Right, that should be an einfo.  It was originally for debugging but I
found it to be pretty useful in practice.

> * What's with the TODO on _wxerror() and the function?

I thought a broken out error reporting function would save a bunch of
duplicated code, but I ended up with a lot fewer cases than I thought
I would.  I think I might just remove it.
 
> The previous points encompass mostly only things noted while going over
> the code - I have yet to look at it with a logic and interaction sense.
> I figured I'll get this current list off my hands before I get sunk into
> work.
> 
> 
> Many many thanks for pushing wxGTK forwards while I'm occupied with
> work, gnome stuff... and procrastinating

Thanks for looking at it.  I know you have a lot on your plate.

-- 
                  fonts / wxWindows / gcc-porting / treecleaners
  EFFD 380E 047A 4B51 D2BD  C64F 8AA8 8346 F9A4 0662 (0xF9A40662)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new old eclass - wxwidgets.eclass

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

> work fine with conditional wx usage? need-wxwidgets for that, I guess?

No, please. These need-foo()'s are crap, because too often people people do

need-foo 
DEPEND="another-dep"

resetting the to be stored dependencies to just "another-dep"...


Also top level function calls in ebuilds are dead ugly per se. Use 
NEED_WX="x.y" to be set before inheriting the eclass instead.


Carsten

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: new old eclass - wxwidgets.eclass

[Ryan Hill]

Ryan Hill wrote:

> since everyone is getting into the reviewing mood, i thought it
> would be a good time to get some opinions on the wxwidgets 
> eclass rewrite i've done.

Committed.  If anyone has any problems please let me know.


-- 
                  fonts / wxWindows / gcc-porting / treecleaners
  EFFD 380E 047A 4B51 D2BD  C64F 8AA8 8346 F9A4 0662 (0xF9A40662)

-- 
gentoo-dev@gentoo.org mailing list