Re: [gentoo-dev] [PATCH 1/3] Generate python depstrings in python-r1 (updated).
On 20 September 2012 05:43, Michał Górny wrote:
> I've renamed PYTHON_DEPEND to avoid confusion with python.eclass.
> ---
> gx86/eclass/python-distutils-ng.eclass | 20 ++-
> gx86/eclass/python-r1.eclass | 35
> --
> 2 files changed, 35 insertions(+), 20 deletions(-)
>
> diff --git a/gx86/eclass/python-distutils-ng.eclass
> b/gx86/eclass/python-distutils-ng.eclass
> index 5df965c..34717aa 100644
> --- a/gx86/eclass/python-distutils-ng.eclass
> +++ b/gx86/eclass/python-distutils-ng.eclass
> @@ -74,24 +74,8 @@ _python-distutils-ng_get_binary_for_implementation() {
> esac
> }
>
> -for impl in ${PYTHON_COMPAT[@]}; do
> - dep_str="${impl/_/.}"
> - case "${dep_str}" in
> - python?.?)
> - dep_str="dev-lang/python:${dep_str: -3}" ;;
> - jython?.?)
> - dep_str="dev-java/jython:${dep_str: -3}" ;;
> - pypy?.?)
> - dep_str="dev-python/pypy:${dep_str: -3}" ;;
> - *)
> - die "Unsupported implementation: ${impl}" ;;
> - esac
> - dep_str="python_targets_${impl}? ( ${dep_str} )"
> -
> - RDEPEND="${RDEPEND} ${dep_str}"
> - DEPEND="${DEPEND} ${dep_str}"
> - unset dep_str
> -done
> +RDEPEND=${PYTHON_DEPS}
> +DEPEND=${PYTHON_DEPS}
>
> _PACKAGE_SPECIFIC_S="${S#${WORKDIR}/}"
>
> diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
> index 18f9246..957db68 100644
> --- a/gx86/eclass/python-r1.eclass
> +++ b/gx86/eclass/python-r1.eclass
> @@ -40,14 +40,45 @@ _PYTHON_ALL_IMPLS=(
> # a package supports. It must be set before the `inherit' call.
> # The default is to enable all implementations.
> #
> -# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar, the
> eclass
> -# will implicitly convert it to an array.
> +# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar,
> +# the eclass will implicitly convert it to an array.
> : ${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}
>
> +# @ECLASS-VARIABLE: PYTHON_DEPS
> +# @DESCRIPTION:
> +# This is an eclass-generated Python dependency string for all
> +# implementations listed in PYTHON_COMPAT. It should be used
> +# in RDEPEND and/or DEPEND like:
> +#
> +# @CODE
> +# RDEPEND="${PYTHON_DEPS}
> +# dev-foo/mydep"
> +# DEPEND="${RDEPEND}"
> +# @CODE
> +
> PYTHON_COMPAT=( ${PYTHON_COMPAT[@]} )
>
> _python_set_globals() {
> IUSE=${PYTHON_COMPAT[@]/#/python_targets_}
> REQUIRED_USE="|| ( ${IUSE} )"
> +
> + PYTHON_DEPS=
> + local i
> + for i in ${PYTHON_COMPAT[@]}; do
> + local d
> + case ${i} in
> + python*)
> + d='dev-lang/python';;
> + jython*)
> + d='dev-java/jython';;
> + pypy*)
> + d='dev-python/pypy';;
> + *)
> + die "Invalid implementation: ${i}"
> + esac
> +
> + local v=${i##*[a-z]}
> + PYTHON_DEPS+=" python_targets_${i}? ( ${d}:${v/_/.} )"
> + done
> }
> _python_set_globals
> --
> 1.7.12
>
>
This patchset looks good to me.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] supporting static-libs
On Thursday 06 of September 2012 10:18:34 Brian Harring wrote:
> On Mon, Sep 03, 2012 at 10:54:15PM +0200, Maciej Mrozowski wrote:
> > On Tuesday 28 of August 2012 02:15:40 hasufell wrote:
> > > Is there a reason not to support static-libs in an ebuild if the
> > > package supports it?
> > >
> > > It seems some developers don't care about this option. What's the
> > > gentoo policy on this? Isn't this actually a bug?
> >
> > A little remark.
> > For CMake controlled buildsystem (as you're coming here from latest dev-
> > games/simgear), there's no automatic way of building both static and
> > shared libs (simgear allows to choose just one).
> > This is why I removed static libs support that you proposed for dev-
> > games/simgear (similar to ruby eclass abi handling - manually calling
> > phases twice to build package 1st as shared, 2nd time as static).
> > This is what I called "not worth the effort" in private discussion with
> > you, not quite "I don't care for static libs" :)
>
> Guessing in the worst case, you can do a double compile to get around
> this, no? And yes, that's freaking horrible, just verifying cmake
> isn't doing something special that blocks it.
Not sure why they would need to block it, one build dir for static, second one
for shared. All safely separated (still stinks as a hack).
> Is upstream doing anything about this, or is it not on their
> radar/list-of-things-they-care-about ?
Off the radar.
CMake provides equivalent of '--enable-static --disable-shared' and '--
disable-static --enable-shared' by the means of BUIlLD_SHARED_LIBS and not
specifying linkage when defining library:
add_library(foo src1 src2)
It doesn't automatically provide both at the same time however. CMake is
cross-platform (meaning it support different generators: GNU Make, NMake,
Visual Studio Project, XCode etc) so their main audience aren't "distros",
also on Windows for instance when shared .dll is created, also import .lib is
created. If static .lib was to be created as well, they would need to have
separate build subdir for it (and a bit more complex library resolution
algorithm).
Still, if developer bothers enough to provide them both, he can easily
implement it in buildsystem with explicitly given linkage (and separate target
names):
set(foo_SRC src1 src2)
add_library(foo SHARED ${foo_SRC})
if (ENABLE_STATIC)
add_library(foo_static STATIC ${foo_SRC})
endif ()
That being said I can understand why it's off the radar - technically
everything is already available, likely not worth the effort and in many cases
building both static/shared is actually not needed.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
El jue, 20-09-2012 a las 14:23 -0400, Ian Stakenvicius escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 20/09/12 02:12 PM, Michael Mol wrote: > > On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos > > wrote: > >> El jue, 20-09-2012 a las 10:14 -0400, Ian Stakenvicius escribió: > >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > >>> > >>> On 20/09/12 09:52 AM, Ciaran McCreesh wrote: > On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius > wrote: > > PMS may not need to be fixed, just the spec > > PMS is the spec, and it doesn't need fixing, since it > accurately reflects the situation we're dealing with. > > >>> > >>> Sorry, I misread PMS as PMs (portage, paludis, etc). > >>> > >>> And, for support to be official for ebuilds or eclasses to > >>> query IUSE (or other globals) within phase functions, then the > >>> 'spec' (PMS) is probably all that needs to be 'fixed'. Right? > >>> > >>> So, in EAPI=6, we propose something that'll make it official > >>> (ie a querying function; or ensure that PMs can provide these > >>> variables along with their proper 'effective' values, or their > >>> in-ebuild 'explicit' values, or whatever it is we want to say > >>> can be relied upon, to the environment). > >>> > >> > >> The problem of waiting for eapi6 to specify CURRENT behavior is > >> that we don't know how much time will need to wait until it's > >> approved (as I think eapi5 cannot include this "extra" function > >> as was approved some hours ago). Other option would be to fast > >> release some kind of eapi5.1 adding this... but, again, I think > >> we are discussing about something that could be resolved as > >> simply as specifying current behavior for all existing eapis (as > >> we are in fact doing in the tree) and rely on new eapis for > >> future hypothetical changes on it. > > > > The key question is: How would you formally describe the current > > behavior? > > > > I think someone already noted it's not reliable behavior in all > > places. > > > > I think we'd need an audit of what current behaviour is and then > define based on that. Possibly removing cases where the 'expected' > behaviour isn't occurring (ie, bugs that just aren't being caught). > > I'm biased, so to me just auditing what portage does would be good > enough. :D But probably the other PMs should be audited to before > 'official' behaviour should be described for PMS. > Will ask to portage people then to know what is current behavior signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: method of checking for cross compilation from ebuild functions
On 09/20/2012 10:34 AM, Ambroz Bizjak wrote: > The question now is, how should this method for checking > --crosscompile be implemented? In particular, we have two options: > > - Environment variable. If so, how to call it? Possible names are > CROSSCOMPILE, GENTOO_CROSSCOMPILE, PORTAGE_CROSSCOMPILE, > ECROSSCOMPILE... For more generic names (CROSSCOMPILE) it needs to be > taken into account that they may inadvertently affect packages. > However environment vars have the benefit that it's easy to pass them > through programs and scripts. > > - Internal function, similar to "use". Probably "is_crosscompile". > This may look nicer and reduces the risk of collisions. Since it's just a boolean flag, we could have a special "crosscompile" USE flag for this, so that the use() function could be used like we currently use it for the "test" USE flag. The flag would be forced on or off based on your configuration, similar to the "test" flag [1], so there wouldn't be any danger of the flag being accidentally enabled or disabled. The flag could be bound to FEATURES=crosscompile, or some other package manager configuration variable. Note that if we add a --crosscompile option to emerge, then we'll also have to add it to the ebuid(1) command, so maybe it's better to forgo the commandline option and just toggle it with a configuration variable like FEATURES=crosscompile. Also, it's conceivable that you could drop the CROSS_HDEPEND variable, in favor of HDEPEND="crosscompile? ( foo )" syntax (somewhat in alignment with Brian Harring's DEPENDENCIES proposal). [1] https://bugs.gentoo.org/show_bug.cgi?id=373209 -- Thanks, Zac
Re: [gentoo-dev] Lastrites for emboss.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/09/12 11:02 AM, Ian Stakenvicius wrote: > Since emboss.eclass is not used by anything in the tree (possibly > for some time) , is outdated (seems EAPI=1'ish) and generally just > cruft, It would be good to clean it. Removal in 30 days unless > anybody objects. > > Rescinded; i confused emboss.eclass with embassy.eclass , which apparently is still used. Sorry for the spam. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBcgs4ACgkQ2ugaI38ACPAMDgD/VCv2QQjtkt9CburG33djbOEp UdRapH2bfHPmooHbbA0A/RKxLVNfHGsBe8giOXok0g03Y7wDUYmpzzjy1wOHJ5Up =v1rA -END PGP SIGNATURE-
[gentoo-dev] Lastrites for emboss.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Since emboss.eclass is not used by anything in the tree (possibly for some time) , is outdated (seems EAPI=1'ish) and generally just cruft, It would be good to clean it. Removal in 30 days unless anybody objects. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBcgaMACgkQ2ugaI38ACPDwVQD+KsWjKfAwOgMDfk+7efQuFb15 /6E+m7YzuPrDqzyRfzAA/i/Xvw2xM9YxApyV+p62GL91vvdjVnYcLNRgQpznAcDW =w9iF -END PGP SIGNATURE-
