[gentoo-dev] RFC: Virtual for awk implementation
Hi, recently I stumbled across a problem with mawk, which is apprearly Ubuntu's default awk interpreter. This brought the idea to my mind of adding a virtual for awk. Beside the fact that we already have 3 awk interpreters in gx86 (gawk, mawk and busybox awk), there are other ones like nawk and awka. I had some discussions with spanKY on that topic in bug #415689, which summarizes in the following: Advantages: - mawk is faster - useful for scientific purposes - busybox awk could replace gawk on minimal systems - more POSIX conform systems Disadvantages: - some awk code in the tree and portage is probably using GNU extensions without executing gawk explicitly - gray zone of Posix 1003.2 (e.g. substr() function and an index of 0) What we would need: - virtual/awk - app-admin/eselect-awk (version available in cj-overlay) and - testing and migration of existing packages using gawk <http://qa-reports.gentoo.org/output/genrdeps/rindex/sys-apps/gawk> and <http://qa-reports.gentoo.org/output/genrdeps/dindex/sys-apps/gawk> to name a few. I have tested mawk as default interpreter for a while on my x86 boxes and didn't observed any problems so far. Cheers, Christoph -- Christoph Junghans http://dev.gentoo.org/~ottxor/
[gentoo-dev] Re: RFC: Virtual for awk implementation
No objections and 2x +1, so I will commit virtual/awk to ~arch and app-admin/eselect-awk to ~arch & masked for testing. Please port packages to virtual/awk (if possible) and make bug reports block on the awk porting tracker (bug #418473). 2012/5/29 Christoph Junghans : > Hi, > > recently I stumbled across a problem with mawk, which is apprearly > Ubuntu's default awk interpreter. > This brought the idea to my mind of adding a virtual for awk. Beside > the fact that we already have 3 awk interpreters in gx86 (gawk, mawk > and busybox awk), there are other ones like nawk and awka. > > I had some discussions with spanKY on that topic in bug #415689, which > summarizes in the following: > > Advantages: > - mawk is faster - useful for scientific purposes > - busybox awk could replace gawk on minimal systems > - more POSIX conform systems > > Disadvantages: > - some awk code in the tree and portage is probably using GNU > extensions without executing gawk explicitly > - gray zone of Posix 1003.2 (e.g. substr() function and an index of 0) > > What we would need: > - virtual/awk > - app-admin/eselect-awk (version available in cj-overlay) > and > - testing and migration of existing packages using gawk > <http://qa-reports.gentoo.org/output/genrdeps/rindex/sys-apps/gawk> > and > <http://qa-reports.gentoo.org/output/genrdeps/dindex/sys-apps/gawk> > to name a few. > > I have tested mawk as default interpreter for a while on my x86 boxes > and didn't observed any problems so far. > > Cheers, > > Christoph > > -- > Christoph Junghans > http://dev.gentoo.org/~ottxor/ -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
2012/9/26 Mike Gilbert : > On Wed, Sep 26, 2012 at 5:59 PM, Michael Mol wrote: >> On Wed, Sep 26, 2012 at 5:49 PM, Chí-Thanh Christopher Nguyễn >> wrote: >>> Michael Mol schrieb: >>>> A few months ago, I filed bug 423651 to ask that bzip2 on the install >>>> media be replaced with >>>> pbzip2. >>> >>> If I understand correctly, pbzip2 depends on bzip2. So what you are >>> asking is that pbzip2 is preferred over bzip2 when both are installed, >>> and that pbzip2 is installed by default? >> >> pbzip2 uses libbzip2, which I understand bzip2 to also be a wrapper around. >> > > libbz2 is built and installed by the app-arch/bzip2 package. Thus, > app-arch/pbzip2 depends on app-arch/bzip2, unless someone rips libbz2 > out into a separate ebuild. That sound like a plan. Maybe bzip2 should become a virtual as busybox also provides an implementation. -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
2012/10/29 Brian Harring : > On Sun, Oct 28, 2012 at 10:35:01PM +0100, Arfrever Frehtes Taifersar Arahesis > wrote: >> 2012-10-28 22:14:15 Mike Gilbert napisa??(a): >> > This library is used for processing Unicode text in several high-profile >> > packages, including Chromium and other Webkit browsers, PHP, boost, and >> > many more. >> > >> > Fair warning: ICU tends to break several packages with every major >> > release, so thorough testing is needed when bumping it. >> > >> > This package is currently being maintained by proxy by a former Gentoo >> > developer, Arfrever. Given this package's potential to cause problems, >> > this situation is not ideal. >> > >> > It would be really great if an active Gentoo developer would step >> > forward and take care of this one. >> >> I am actively maintaining ICU and test many reverse dependencies with new >> versions of ICU >> (using a not package.masked version of GCC). >> >> Members of proxy-maintainers team or others actively commit fixes/updates, >> so there >> is no need to change current situation. > > Yeah... I don't agree with that. Floppym wouldn't be looking > for a new maintainer if that was accurate. > > The package has been cranky enough in parallel with revdeps breaking > everytime it's bumped that this needs a dev watching it, rather than > whichever random proxy-maintainer member snags that version. > > Anyone got the spare cycles for it? If Arfrever keeps maintaining it for a while, I will take it. Christoph > > ~harring > -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
2012/10/29 Diego Elio Pettenò : > On 29/10/2012 10:37, Christoph Junghans wrote: >> If Arfrever keeps maintaining it for a while, I will take it. > > Do remember that whatever you commit, _You_ take responsibility for it. > After a screwup, the answer "I didn't do anything, I just committed what > Arfrever gave me" is not a good answer. Ok, I should have been more precise here. I will take it, but as I am new to the insides of icu, it will take me a bit to understand/fix/workaround it's issues and for that time having Arfrever will be more than useful. > In particular, if I hear such an answer from anybody (be it for icu or > something else, be it for a minor inconsistency or a total fuckup), I'll > be requesting devrel to re-evaluate their commit rights, as they are > missing the understanding of "you're responsible for whatever you commit". Please, go ahead. I am happy with having less rights and less responsibilities. > > -- > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
2012/11/28 Justin :
> Hi,
>
> and another one.
>
> Problem:
> Some packages aren't lucky and their buildsystem doesn't create
> pkg-config files out of the box.
>
> Solution:
> Create them by hand.
>
> Eclass:
> Simplifies this by providing a general function for that.
>
> Example:
> https://github.com/gentoo-science/sci/blob/pkg-config/sci-libs/mmdb/mmdb-1.24.ebuild
>
> Thanks for comments,
> Justin
Great jobs, I had a similar eclass on my mind for a long time. It will
for sure be useful for Gentoo prefix builds.
However, I have some suggestions:
- Cflags should contain -I${includedir} and Libs should contain
-L${libdir} by default (see
<http://people.freedesktop.org/~dbn/pkg-config-guide.html#concepts>).
- Reduce the number of global variables. Arguments to create_pkgconfig
are as useful as global variables.
- arguments like -{l,L}* can be used as Libs to avoid redundancy in
the syntax (example: "-lm" instead of "-l -lm"), same for -I*
- it is only one function, maybe it could be added to eutils eclass
- pc files created by this eclass should go into a Gentoo specific
directory (/usr/share/gentoo/lib/pkgconfig?) to avoid confusion with
upstream pc files. This directory can then be added to PKG_CONFIG_PATH
during the build.
Can you also remind me what should go into these private variables and
what not? Since Fedora has started their DSO Linking policy I am very
confused about flags like -lm and -pthreads.
--
Christoph Junghans
http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] cmake + ninja vs autotools
On Nov 16, 2017 6:29 AM, "Brian Evans" wrote:
On 11/15/2017 10:27 PM, William L. Thomson Jr. wrote:
> It maybe worth considering switching the default generator in the
> cmake-utils.eclass from the default of emake to ninja.
>
> - : ${CMAKE_MAKEFILE_GENERATOR:=emake}
> + : ${CMAKE_MAKEFILE_GENERATOR:=ninja}
>
> For those with cmake ebuilds you can test this out now via
>
> CMAKE_MAKEFILE_GENERATOR="ninja"
> inherit cmake-utils
>
> Working with both cmake and meson. It seems the real performance of
> meson comes from ninja. I am a bit more a fan of cmake than meson for
> cpack, generation of deb, rpm, and binary tarball, in addition to
> sources. That can be done with meson but not as elegantly at this time.
>
> ninja is noticeably faster than make. I haven't seen any cases yet where
> cmake autotools works, and ninja does not. They seem pretty equal, so
> should be safe. Of course could use testing first.
There are still cases where ninja fails...
Ninja doesn't support Fortran as well.
I have forcefully set emake in dev-db/{mysql,mysql-cluster} because they
fail to build with ninja (using the cmake generator) yet emake works
just fine.
Brian
Re: [gentoo-dev] cmake + ninja vs autotools
2017-11-16 6:44 GMT-07:00 Christoph Junghans :
>
>
> On Nov 16, 2017 6:29 AM, "Brian Evans" wrote:
>
> On 11/15/2017 10:27 PM, William L. Thomson Jr. wrote:
>> It maybe worth considering switching the default generator in the
>> cmake-utils.eclass from the default of emake to ninja.
>>
>> - : ${CMAKE_MAKEFILE_GENERATOR:=emake}
>> + : ${CMAKE_MAKEFILE_GENERATOR:=ninja}
>>
>> For those with cmake ebuilds you can test this out now via
>>
>> CMAKE_MAKEFILE_GENERATOR="ninja"
>> inherit cmake-utils
>>
>> Working with both cmake and meson. It seems the real performance of
>> meson comes from ninja. I am a bit more a fan of cmake than meson for
>> cpack, generation of deb, rpm, and binary tarball, in addition to
>> sources. That can be done with meson but not as elegantly at this time.
>>
>> ninja is noticeably faster than make. I haven't seen any cases yet where
>> cmake autotools works, and ninja does not. They seem pretty equal, so
>> should be safe. Of course could use testing first.
>
> There are still cases where ninja fails...
>
> Ninja doesn't support Fortran as well.
Besides not supporting the full feature set.
Ninja vs make didn't seem to make big time difference (for cmake at
least). Back in 2013 ago only found a 40sec difference (of an 6.5 min
overall build) when building kdelibs averaging over 3 builds, which
had more than 40s scatter in the individual builds.
That coincides with my own experience outside of portage where ninja
and make are pretty much even for a full build, but ninja is much
faster in figuring out which parts to rebuild in a partial build.
>
>
> I have forcefully set emake in dev-db/{mysql,mysql-cluster} because they
> fail to build with ninja (using the cmake generator) yet emake works
> just fine.
>
> Brian
>
>
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: sci-chemistry/votca*, sci-libs/votca-tools
sci-chemistry/votca replaces sci-libs/votca-tools & the other votca-* packages. sci-chemistry/votca builds fine, so we should not be last-rited that, but only the votca-*. Christoph On Fri, Dec 23, 2022 at 6:31 AM Michał Górny wrote: > > # Michał Górny (2022-12-23) > # sci-libs/votca-tools fail to build with GCC 12. Pending version bump > # since January 2022. > # Removal on 2023-01-22. Bug #841830. > sci-chemistry/votca > sci-chemistry/votca-csg > sci-chemistry/votca-csgapps > sci-chemistry/votca-xtp > sci-libs/votca-tools > > -- > Best regards, > Michał Górny > >
Re: [gentoo-dev] Packages up for grabs due nelchael retirement
2012/12/16 Pacho Ramos : > net-misc/openntpd I take this. -- Christoph Junghans http://dev.gentoo.org/~ottxor/
[gentoo-dev] RFC: change of the default value for EHG_REVISION (mercurial.eclass)
With nelchael's retirement I (with backup from djc) will take over the maintenance of mercurial.eclass. As one of the first things I would like to change the default value of EHG_REVISION. EHG_REVISION defines the revision/branch/tag to be checkout in src_unpack. The current default is "tip", which identifies the most recent revision. This can lead to unwanted branch changes (see <https://bugs.gentoo.org/show_bug.cgi?id=380947#c16>) as the branch in which tip resides is not fixed. The new default should be "default", which is mercurial's default name for the main branch. Looking at the packages using mercurial.eclass (<http://qa-reports.gentoo.org/output/eclass-usage/mercurial.txt>) the above change shouldn't cause any problems (some packages already use EHG_REVISION="default" to avoid branch changes), but I will wait another week before committing the change. -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] RFC: new "qt" category
2013/1/17 Ben de Groot : > Hi guys, > > Presently we already have a good number of split qt-* library packages > in x11-libs. With the arrival of Qt5 upstream has gone a lot further > in modularization, so we expect the number of packages to grow much > more. We, the Gentoo Qt team, are of the opinion that the time has > come to split all these out into their own category. This category is > to be used for the various modules and applications that belong to the > upstream Qt Framework only (these include e.g. assistant and > linguist). Third-party applications should remain in the current > categories. > > After some initial bikeshedding we came to the conclusion that naming > the category simply "qt" is the most elegant solution. We will then > also be dropping the qt- prefix in package names. This means > x11-libs/qt-core will be moved to qt/core, and so on. -1 I don't like the idea of emerging gui instead qt-qui. > > Please let us know your thought on this. > -- > Cheers, > > Ben | yngwin > Gentoo developer > Gentoo Qt project lead, Gentoo Wiki admin > -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] Should we list sys-apps/sed in DEPEND
2013/2/19 Brian Dolbec : > On Tue, 2013-02-19 at 14:10 +0100, Thomas Kahle wrote: >> ... if it is used in the ebuild? >> >> It is a system package here on amd64, but is it everywhere? >> >> Cheers, >> Thomas >> > > Only if the pkg is also a system package. I recently ran into a problem > running a catalyst build because portage-utils did not list the xz-utils > dep which was another system package. It failed to unpack because > xz-utils was still waiting to be merged. I was running catalyst with > --jobs=3. That is what unpacker_src_uri_depends from unpacker.eclass is intended for. DEPEND+=$(unpacker_src_uri_depends) > > -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] [PATCH 8/8] fftw: example use of multibuild in ebuild.
+1, feel free to commit, when multibuild.eclass was added.
2013/2/27 Michał Górny :
> Just a quick, dirty example. Not even tested thoroughly ;).
> ---
> gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild | 38
> +
> 1 file changed, 15 insertions(+), 23 deletions(-)
>
> diff --git a/gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild
> b/gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild
> index 18554f0..ddca8e4 100644
> --- a/gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild
> +++ b/gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild
> @@ -7,7 +7,7 @@ EAPI=5
> #AUTOTOOLS_AUTORECONF=1
> FORTRAN_NEEDED=fortran
>
> -inherit autotools-multilib eutils flag-o-matic fortran-2 toolchain-funcs
> versionator
> +inherit autotools-multilib eutils flag-o-matic fortran-2 multibuild
> toolchain-funcs versionator
>
> DESCRIPTION="Fast C library for the Discrete Fourier Transform"
> HOMEPAGE="http://www.fftw.org/";
> @@ -24,6 +24,8 @@ DEPEND="${RDEPEND}
> test? ( dev-lang/perl )"
>
> pkg_setup() {
> + # XXX: this looks like it should be used with BUILD_TYPE!=binary
> +
> if use openmp; then
> if [[ $(tc-getCC) == *gcc ]] && ! tc-has-openmp; then
> ewarn "OpenMP is not available in your current
> selected gcc"
> @@ -32,13 +34,13 @@ pkg_setup() {
> FORTRAN_NEED_OPENMP=1
> fi
> fortran-2_pkg_setup
> - FFTW_DIRS="single double longdouble"
> + MULTIBUILD_VARIANTS=( single double longdouble )
> if use quad; then
> if [[ $(tc-getCC) == *gcc ]] && ! version_is_at_least 4.6
> $(gcc-version); then
> ewarn "quad precision only available for gcc >= 4.6"
> die "need quad precision capable gcc"
> fi
> - FFTW_DIRS+=" quad"
> + MULTIBUILD_VARIANTS+=( quad )
> fi
> }
>
> @@ -57,7 +59,9 @@ src_configure() {
> # filter -Os according to docs
> replace-flags -Os -O2
>
> - for x in ${FFTW_DIRS}; do
> + my_configure() {
> + local x=${MULTIBUILD_VARIANT}
> +
> myeconfargs=(
> $(use_enable fma)
> $(use_enable fortran)
> @@ -93,42 +97,30 @@ src_configure() {
> die "${x} precision not implemented in this ebuild"
> fi
>
> - einfo "Configuring for ${x} precision"
> - BUILD_DIR="${S}-${x}" \
> - autotools-multilib_src_configure
> - done
> + autotools-multilib_src_configure
> + }
> +
> + multibuild_foreach my_configure
> }
>
> src_compile() {
> - for x in ${FFTW_DIRS}; do
> - einfo "Compiling for ${x} precision"
> - BUILD_DIR="${S}-${x}" \
> - autotools-multilib_src_compile
> - done
> + multibuild_foreach autotools-multilib_src_compile
> }
>
> src_test () {
> - do_smalltest() { cd "${BUILD_DIR}" && emake -C tests smallcheck; }
> # We want this to be a reasonably quick test, but that is still
> hard...
> ewarn "This test series will take 30 minutes on a modern 2.5Ghz
> machine"
> # Do not increase the number of threads, it will not help your
> performance
> #local testbase="perl check.pl --nthreads=1 --estimate"
> # ${testbase} -${p}d || die "Failure: $n"
> - for x in ${FFTW_DIRS}; do
> - einfo "Testing ${x} precision"
> - BUILD_DIR="${S}-${x}" \
> - multilib_foreach_abi do_smalltest
> - done
> + multibuild_foreach autotools-multilib_src_compile -C tests smallcheck
> }
>
> src_install () {
> local u x
> DOCS=( AUTHORS ChangeLog NEWS README TODO COPYRIGHT CONVENTIONS )
> HTML_DOCS=( doc/html/ )
> - for x in ${FFTW_DIRS}; do
> - BUILD_DIR="${S}-${x}" \
> - autotools-multilib_src_install
> - done
> + multibuild_foreach autotools-multilib_src_install
>
> if use doc; then
> dodoc doc/*.pdf
> --
> 1.8.1.4
>
>
--
Christoph Junghans
http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] Collecting items for EAPI 6
2013/3/28 Michał Górny : > Hello, > > As discussed with ulm, I'd like to start a thread for collecting > initial items for EAPI 6. Preferably items which are either almost > ready or are easy to implement and are non-controversial. In other > words, thing which are practically ready to get on the actual list. > > As usual, each item should have a corresponding 'Future EAPI' bug which > blocks the tracker [1]. > > [1]:https://bugs.gentoo.org/show_bug.cgi?id=future-eapi > #444366 - unique subslot for live ebuilds -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
2013/7/1 Fabio Erculiani : > I believe that end users would benefit more from kernel binary ebuilds > (ebuilds building an actual kernel with an official config), rather > than all this. +1 The "binary" use flag for sys-kernel/*-sources in Funtoo implements exactly that. > > -- > Fabio Erculiani > -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] logging in openntpd 20080406-r3+
2013/11/28 Rich Freeman : > On Wed, Nov 27, 2013 at 10:56 PM, Paul B. Henson wrote: >> On Fri, Nov 22, 2013 at 09:36:38PM +0100, Peter Stuge wrote: >>> Paul B. Henson wrote: >>> > In openntpd ebuilds starting with version 20080406-r3, logging was >>> > changed >>> > from using the default standard syslog to running the daemon in debug >>> > mode, >>> > logging to stderr, and having start_stop_daemon background the process >>> > itself and redirect the output to a log file. >>> > >>> > I think this is broken. >>> >>> Yes, I think it is really f-ing broken too. >> >> Well, looks like it's just you and me in that camp :(, quite >> disappointing no other devs stepped up with an opinion on this. Guess >> I'll just fix this in my local overlay and the rest of the users can >> fend for themselves. > > Did anybody actually talk to the maintainer about this and ask why > this was done? That would probably be a good first step if you want > it to change. Having 47 devs agree with you doesn't really accomplish > much if none of them care to maintain the package in question. Paul talked to me via the bug tracker, bug 491134, and due to discussion we had there openntpd-20080406-r5 features a use flag to bring back syslog support (for details see the bug). This allows to run openntpd with two different ways of logging, via syslog (like Paul wants) and with a separate log file to avoid boot delays (like djc wants). We could easily make syslog logging the default, like polynomial-c suggested in another thread, but syslog is enabled in most profiles by default anyway. > > Also, you can always publish your overlay. :) > > Rich > -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only
2014-02-20 8:19 GMT-07:00 Mike Gilbert : > On Thu, Feb 20, 2014 at 8:12 AM, Lars Wendler wrote: >> Hi, >> >> it seems like some GNU projects start to release their source tarballs >> in lzip compressed versions only [1][2]. >> This is a problem since portage's unpack function doesn't know anything >> about lzip. >> >> ... >> >> What do you think? >> > > A short-term solution would be to add lzip support to unpacker.eclass > and utilize that instead of the built-in unpack function. I had the same idea: <https://bugs.gentoo.org/show_bug.cgi?id=501912> > > A long-term solution would be to modify PMS to support unpacking lzip > archives. I don't see, why we should do that. unpacker.eclass is a good place to support exotic archive formats. > > Either way, you will still need to have app-arch/lzip in DEPEND, > similar to app-arch/unzip. Or use $(unpacker_src_uri_depends). > -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] [PATCH] cmake-utils.eclass: add Fortran to Gentoo override rules (set valid compiler, append FCFLAGS)
2015-02-11 11:14 GMT-07:00 Andrew Savchenko : > Hello, > > attached patch adds Fortran compiler to Gentoo override rules in > cmake-utils.eclass the same way C/C++ compilers are added. > > This change is needed because packages which force their own > precedence of Fortran compilers or flags also exists. We hit this > issue on bug 486626 [1] for sci-libs/lapacke-reference (science > overlay): if multiple Fortran compilers are installed, e.g. pathf95 > and gfortran, package prefers pathf95 — this may even broke build, > because most FCFLAGS are not compatible between this compilers > > In order to fix this FC should be set from $(tc-getFC), which is > implemented in proposed patch as well as ensuring proper flags are > set. > > This change was already discussed with KDE team [1] and I'm going to > commit this patch after feedback or in a week if there are no > objections. +1 > > [1] https://bugs.gentoo.org/show_bug.cgi?id=486626 > > Best regards, > Andrew Savchenko -- Christoph Junghans http://dev.gentoo.org/~ottxor/
[gentoo-dev] Last rites: sci-libs/openmm
# Christoph Junghans (7 Mar 2015) # Fails to build (bug #536406); nothing in the tree uses it. # Masked for removal in 30 days sci-libs/openmm -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] Re: RFC: using Ninja in more CMake-based packages
2015-06-07 14:19 GMT-06:00 Justin Lecher (jlec) :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 07/06/15 22:14, Johannes Huber wrote:
>> Am Sonntag 07 Juni 2015, 17:08:57 schrieb Michał Górny:
>>> Hello, developers.
>>
>> Hello Michal,
>>
>>> As you probably know already, CMake sucks a lot. One of its more
>>> sucky features is that it generates Makefiles that fail a lot. In
>>> particular, they fail at verbose build logs that are cluttered
>>> with useless CMake intermediate commands and hard to read. But
>>> also they sometimes deadloop hard in faulty dependency scanning
>>> [1].
>>>
>>> Those two issues can be solved by switching CMake to use Ninja
>>> instead of make. As you may know, Ninja is the fancy building
>>> tool that is faster and much harder to use than make. However, it
>>> integrates with CMake much better and with less hackery. In
>>> particular, the verbose build log is free of useless CMake
>>> percentage printing output and other non-sense, and contains only
>>> real build commands. It also gets dependency scanning right.
>>>
>>> Sadly, there are two problems with using Ninja:
>>>
>>> 1) it will not work with some packages,
>>>
>>> 2) it introduces an extra dep (on Ninja).
>>>
>>> The first issue is a bit complex. Sometimes the problem lies in
>>> CMake itself (not all CMake magic works in Ninja for some
>>> reason), sometimes in the project (relying on Makefile stuff),
>>> sometimes in the ebuild. For example, with Ninja you can't do '-C
>>> subdirectory' to run targets from a specific subdirectory. So, we
>>> can't force Ninja everywhere.
ninja has a "-C" option, too, but cmake only generates one build.ninja
in the root directory instead of a Makefile in every directory which
has a CMakeLists.txt.
>>>
>>> The second issue is a bit easier. GNU make is part of @system,
>>> ninja would be considered an extra package being installed. Do we
>>> consider it fine to require it randomly? Or do we need to justify
>>> the extra dep by benefits of building a particular package with
>>> Ninja? Is sane verbose build log a good enough benefit?
>>>
>>> So, what do you think? Should I start switching random packages
>>> to Ninja whenever it works?
>>>
>>> Oh, and this would be done via something like: :
>>> ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
>>>
>>> before inherit line. To respect user forcing another generator,
>>> and to get deps right.
>>>
>>> [1]:https://bugs.gentoo.org/show_bug.cgi?id=546336
>>
>> KDE herd maintains ~1000 packages and the majority relies on CMake.
>> I am not aware of any reports about GNU make related build files.
>> So i would vote for the reliable GNU make generator.
>>
>
> I tested ninja some while ago on some big cmake science projects and I
> found it to be faster. So I would vote for Micheals suggestion. Though
> I also never faced any problems with the makefiles either. It's purely
> that I found ninja to work smooth and fast.
Right after this feature was implemented (bug #430608), ago did some
testing on kde-base/kdelibs, but only found a 40 sec save on a 6min
overall build.
Christoph
>
> Justin
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0
>
> iQJ8BAEBCgBmBQJVdKc1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
> OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiDBQP/R2vvdQGBOUGHX5wNHCjJxoy
> XPQdJq7Y+ihrDj+630/EIzvncZjLXpJ1r03ftfQ8Km38m1dIL9HHVIX4Z6NHokwe
> bmEs1VAQk+3NajmzB4Wt6xJoiIPiQiIDeNLAYhe8MVL1qK+LW5sgC8gV7PWwau7b
> 7CsBbPJOE1Y/rcjc8B3c630hE8WXAfQ1lnIBR7EzNsnNwTp5s8F4u7JktZSKkSSc
> g1545i8EBaV2eHeEatIqEpB2oGDp2eDZjeLny7nlCU0FO0MfFFsTWBXEJHUDIto4
> ammwydyWLGBACU97jBkoePgSp54ekAW3XdtMFG9KT7/rArtgDY06wWFH2BqA0tcx
> qYGXqT1QBzjjUmTyQmHflKv3Zx233RD2h4J2g9A0wE5CKZViKdfKWADG0tyIRlOI
> ooZKj7sp/iKZbgQqVdHPqySw7clUFi0LGUr7RQr/RUC1z+ROSb+x+dCkSV9ujPSF
> A8acKoEu7cjjGU4P/RFiWbHR/czMXiv21VmAvD4sdqibkYlfR/YWyctz0JMzfIdz
> tB6ZDpedB3Qsu0tTdlnOYiCMpoMH/ZBK3vjLcG/72BkqjyyD32xJu1KVVARao+ZQ
> 4cOxNXDA35yeOnZ77pNLNhkS8CToGuijqtUdkDhYq+rhLFOkNcTbl+fR88UuTeAH
> ZwGZmZGkP1jubaDIN+NL
> =17Cu
> -END PGP SIGNATURE-
>
--
Christoph Junghans
http://dev.gentoo.org/~ottxor/
