Re: [gentoo-dev] [RFC] qt5-build.eclass
Dnia 2014-08-17, o godz. 20:38:18
Davide Pesavento p...@gentoo.org napisał(a):
# @FUNCTION: qt5-build_src_unpack
# @DESCRIPTION:
# Unpacks the sources.
qt5-build_src_unpack() {
if [[ $(gcc-major-version) -lt 4 ]] || [[ $(gcc-major-version) -eq 4
$(gcc-minor-version) -lt 5 ]]; then
ewarn
ewarn Using a GCC version lower than 4.5 is not supported.
ewarn
fi
if [[ ${PN} == qtwebkit ]]; then
eshopts_push -s extglob
if is-flagq '-g?(gdb)?([1-9])'; then
Wouldn't that be equivalent to '-g[^0]'? And I think this would
actually work without extglob.
ewarn
ewarn You have enabled debug info (probably have -g or
-ggdb in your CFLAGS/CXXFLAGS).
ewarn You may experience really long compilation times
and/or increased memory usage.
ewarn If compilation fails, please try removing
-g/-ggdb before reporting a bug.
ewarn For more info check out
https://bugs.gentoo.org/307861;
ewarn
fi
eshopts_pop
fi
case ${QT5_BUILD_TYPE} in
live)git-r3_src_unpack ;;
release) default ;;
esac
}
# @FUNCTION: qt5-build_src_prepare
# @DESCRIPTION:
# Prepares the sources before the configure phase.
qt5-build_src_prepare() {
qt5_prepare_env
if [[ ${QT5_MODULE} == qtbase ]]; then
# Avoid unnecessary qmake recompilations
sed -i -re s|^if true;.*(\[
'\!').*($outpath/bin/qmake\.*)|if \1 -e \2 then| \
configure || die sed failed (skip qmake bootstrap)
Any chance for something more readable? :) Like a inline patch.
# Respect CC, CXX, *FLAGS, MAKEOPTS and EXTRA_EMAKE when
bootstrapping qmake
sed -i -e /outpath\/qmake\.*\\$MAKE\)/ s:): \
${MAKEOPTS} ${EXTRA_EMAKE} 'CC=$(tc-getCC)'
'CXX=$(tc-getCXX)' \
'QMAKE_CFLAGS=${CFLAGS}' 'QMAKE_CXXFLAGS=${CXXFLAGS}'
'QMAKE_LFLAGS=${LDFLAGS}': \
-e '/$CFG_RELEASE_QMAKE/,/^\s\+fi$/ d' \
configure || die sed failed (respect env for qmake
build)
Ditto ;).
sed -i -e '/^CPPFLAGS\s*=/ s/-g //' \
qmake/Makefile.unix || die sed failed (CPPFLAGS for
qmake build)
# Respect CXX in {bsymbolic_functions,fvisibility,precomp}.test
sed -i -e /^QMAKE_CONF_COMPILER=/ s:=.*:=\$(tc-getCXX)\: \
configure || die sed failed (QMAKE_CONF_COMPILER)
# Respect toolchain and flags in config.tests
find config.tests/unix -name '*.test' -type f -print0 \
| xargs -0 sed -i -e '/bin\/qmake/ s/-nocache //' \
|| die sed failed (config.tests)
find ... -exec sed ... {} +
fi
if [[ ${PN} != qtcore ]]; then
qt5_symlink_tools_to_build_dir
fi
# apply patches
[[ ${PATCHES[@]} ]] epatch ${PATCHES[@]}
epatch_user
}
[...]
# @FUNCTION: qt5-build_src_install
# @DESCRIPTION:
# Performs the actual installation of target directories.
qt5-build_src_install() {
qt5_foreach_target_subdir emake INSTALL_ROOT=${D} install
if [[ ${PN} == qtcore ]]; then
pushd ${QT5_BUILD_DIR} /dev/null || die
einfo Running emake INSTALL_ROOT=${D}
install_{mkspecs,qmake,syncqt}
You can put that command-line in an array or set to argv.
emake INSTALL_ROOT=${D} install_{mkspecs,qmake,syncqt}
popd /dev/null || die
# install an empty Gentoo/gentoo-qconfig.h in ${D}
# so that it's placed under package manager control
${T}/gentoo-qconfig.h
(
insinto ${QT5_HEADERDIR#${EPREFIX}}/Gentoo
doins ${T}/gentoo-qconfig.h
)
# include gentoo-qconfig.h at the beginning of QtCore/qconfig.h
sed -i -e '1a#include Gentoo/gentoo-qconfig.h\n' \
${D}${QT5_HEADERDIR}/QtCore/qconfig.h \
|| die sed failed (qconfig.h)
fi
qt5_install_module_qconfigs
prune_libtool_files
}
[...]
# @FUNCTION: qt5_base_configure
# @INTERNAL
# @DESCRIPTION:
# Runs ./configure for modules belonging to qtbase.
qt5_base_configure() {
# setup toolchain variables used by configure
tc-export CC CXX RANLIB STRIP
export LD=$(tc-getCXX)
# configure arguments
local conf=(
# installation paths
-prefix ${QT5_PREFIX}
-bindir ${QT5_BINDIR}
-headerdir ${QT5_HEADERDIR}
-libdir ${QT5_LIBDIR}
-archdatadir ${QT5_ARCHDATADIR}
Re: [gentoo-dev] [RFC] qt5-build.eclass
Michał Górny:
sed -i -e '/^CPPFLAGS\s*=/ s/-g //' \
qmake/Makefile.unix || die sed failed (CPPFLAGS for
qmake build)
# Respect CXX in {bsymbolic_functions,fvisibility,precomp}.test
sed -i -e /^QMAKE_CONF_COMPILER=/ s:=.*:=\$(tc-getCXX)\: \
configure || die sed failed (QMAKE_CONF_COMPILER)
# Respect toolchain and flags in config.tests
find config.tests/unix -name '*.test' -type f -print0 \
| xargs -0 sed -i -e '/bin\/qmake/ s/-nocache //' \
|| die sed failed (config.tests)
find ... -exec sed ... {} +
Unless you really need it please use -execdir instead, since -exec is
insecure. Afais it should work both ways here.
Re: [gentoo-dev] Fw: reviewboard and its bugs
I originally responded to another thread. Here is what I said: I gave this a try some time ago and was bummed down by some things. I dont like nodejs enough, and npm devs seems to not care about centrally/globally installed packages. There are some npm packages that have to be modified so they can work when globally installed and it gets boring after a while. npm packages tend to be really small so one package can have a really high number of deps. If anybody is interested in this, check out my repo with npm packages[0] and a really simple g-npm tool[1] to generate ebuilds for them. These tools might be outdated cause I don't use nodejs anymore and I dont care much about it. Feel free to ping me if you have questions. Cheers, [0] https://github.com/neurogeek/gentoo-overlay (I might have something more recent somewhere) [1] https://github.com/neurogeek/g-npm On Tue, Aug 19, 2014 at 11:50 PM, Tim Boudreau niftin...@gmail.com wrote: FWIW, I suspect npm is here to stay, and it has a facility for installing system-wide utilities; and NodeJS is both usable and convenient for system-level scripting which has no connection to webapps, and has the ability to build native code that integrates with NodeJS code as well. IMO, it would be pretty insane to write packages that duplicate npm packages; support within portage for installing things with it makes more sense. I've occasionally toyed with the idea of a webapp that exposes packages in npm as ebuilds and generates the required metadata on the fly, so anything in the npm repository would simply *be* a Gentoo package. Not sure the idea is viable, but it might be. If that existed, and then some known-stable subset of packages for which system-wide installation is appropriate could be mirrored in the portage tree, that would probably be ideal. -Tim On Tue, Aug 19, 2014 at 8:48 PM, IAN DELANEY del...@iinet.com.au wrote: Begin forwarded message: Date: Wed, 20 Aug 2014 08:45:21 +0800 From: IAN DELANEY idel...@gentoo.org To: gentoo-pyt...@lists.gentoo.org Subject: reviewboard and its bugs cancel the gentoo-python@lists, was intended for gentoo-dev@lists The package reviewboard has reached a stage of warranting this submission to the ML. A simple search of reviewboard in bugzilla lists a few 'user submitted' bugs and no less than 3 sec bugs. This package I added initially because interest was expressed mainly by my final mentor and the other (prior) co-maintainer. Because of changes to reviewboard upstream, we need a new eclass and category to cater to certain js packages. Now wishing to re-write all I have already written in the bugs, in summary, reviewboard has become unworkable by the developers of reviewboard itself going down the path of nodejs. Enter npm. npm was an unknown to me until Djblets and django-pipeline ebuilds failed due to the absence of UglifyJS and some related js deps. On being informed of ebuilds for this and related deps in the overlay of neurogeek, I discovered they required npm which it seems comes in nodejs. The response drawn by fellow devs over npm is in my limited experience unprecedented. The overall reaction was leave it and don't go there. What became apparent from the ebulds in neurogeek's overlay was that these deps didn't lend themselves well to writing ebuilds for them for portage. In the overlay there is in fact an npm eclass to overseer their installation into the system. After some somewhat reluctant discussion of npm in irc, it has at least been suggested that the use of nodejs' UglifyJS in django-pipeline could be patched out to relieve us all of any reliance or involvement of npm to install these js oriented deps. That has not ofcourse been attempted or tested and allows for the probability of breaking Djblets and or reviewboard which I suspect has been written by reviewboard developers to explicitly depend on and call these deps. The decision it seems isn't whether to allows npm into portage, it already comes with nodejs correct me if I misunderstand. The question is whether to support this npm installing packages into a gentoo system by ebuilds essentially outside of portage. This requires an eclass and it has been suggested a whole new category for portage under which to categorise these npm type packages. Such an eclass has already been written, however, that it has never been added to portage along with js style packages in the overlay, to me at least, strongly suggests the author always had reservations with its addition. There is ofcourse the alternative; to write ebuilds to install these packages without npm involvement. This would still require an eclass anyway. Either way, nodejs and java script are totally outside the realm of pythonic packages and are therefore outside my realm of knowledge and experience. Reviewboard developers have essentially created a huge dilemma for users of reviewboard in gentoo by going
Re: [gentoo-dev] Fw: reviewboard and its bugs
On Wed, Aug 20, 2014 at 11:08 AM, Jesus Rivero (Neurogeek) neurog...@gentoo.org wrote: I originally responded to another thread. Here is what I said: I gave this a try some time ago and was bummed down by some things. I dont like nodejs enough, and npm devs seems to not care about centrally/globally installed packages. There are some npm packages that have to be modified so they can work when globally installed and it gets boring after a while. npm packages tend to be really small so one package can have a really high number of deps. For NodeJS, the first-class thing is web applications, and as far as their concerned, the best practice is, if your application uses a library, it should have its own copy of it. And, for web applications, that *does* guarantee that you know what version of everything you're deploying, and allows an application to have dependencies which themselves have conflicting dependencies - which helps ensure deployment is uncomplicated and you know what you're deploying. However, globally installed packages are supported, and are increasingly important as people discover NodeJS is useful for things that are not web-application related. So it seems like something that's not going away, and sooner or later package managers will have to deal with it. If anybody is interested in this, check out my repo with npm packages[0] and a really simple g-npm tool[1] to generate ebuilds for them. These tools might be outdated cause I don't use nodejs anymore and I dont care much about it. g-npm looks interesting. -Tim
