Re: [gentoo-dev] Java 9 on Gentoo
On Fri, Nov 17, 2017 at 12:30 AM, William L. Thomson Jr. wrote: > On Thu, 16 Nov 2017 23:38:09 -0600 > R0b0t1 wrote: >> >> Hopefully this is not a tangent, but the OpenJDK release is available >> on Ubuntu. I have tried to understand the IcedTea build process and >> failed, as I was hoping that it could be packaged for Gentoo before >> the official IcedTea release. I was not able to find a timeline from >> the OpenJDK project. > > Gentoo is a from source distro not binary. It will be some time before > icedtea, some version support slot 9 will be available. There is no eta > for icedtea. That comes from directly from RedHat. The person who > makes it for the world does so on Gentoo, for RedHat their employer. > I am confused. I was aware that IcedTea was a build system, but I am not aware as to how Ubuntu packaged OpenJDK 9. In the context of Gentoo I meant "packaged" as in "created an ebuild for," which is not proper language. > I tried for years to get others to make a path for them to be able to > become a dev and work in tree. Rather that work goes into java-overlay > and is proxied to tree by Chewi/James. > https://github.com/gentoo/java-overlay/tree/master/dev-java/icedtea > Though I am not a developer, this concerns me in other areas too. Many developers do not produce extremely high quality code, but this concern is cited as exactly the reason for keeping developership exclusive. Projects I feel I should mention include genkernel and crossdev. I had to temporarily give up my personal interests that relied on them and have since begun rewriting them. In the small bit I have done understanding crossdev, it has become apparent to me that the authors did not reference the GCC build system documentation very well. Of course, it may be the case that no one refers to it. >> You focus on Oracle's Java? > > Yes, in brief, as the other will always lag. I would be some what > interested in a actual OpenJDK package. That could build with either > oracle or icedtea. Usually for production and business purposes people > want to run Oracle. I do not know many who run icedtea/openjdk. Though > I am sure they are out there. Definitely RedHat customers. > I expect the releases to lag, which is why I had been using Oracle's JDK. Can you explain why there is an IcedTea ebuild but not an OpenJDK ebuild? > Also icedtea on Gentoo does not have OpenJavaFX. I am not > sure any distro has OpenJavaFX packaged. I am not aware of any ebuilds > ever for that. Probably be me someday if I ever have interest. Which > can bind many to oracle for JavaFX. Which includes myself. > OpenJDK now contains an implementation of JavaFX. Debian and Ubuntu have it packaged. For general instructions, see the following: http://openjdk.java.net/projects/openjfx/ https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX Packages: https://tracker.debian.org/pkg/openjfx https://packages.ubuntu.com/xenial/openjfx I have recently been interested in JavaFX. It is far more user friendly. Many open source applications still target Swing however, to be compatible with old OpenJDK releases. > Icedtea really is not a jdk but a build system. On Gentoo only it > becomes the name of the JDK/JRE. It really is just OpenJDK built > without Oracle. Ideally there is oracle, openjdk, and icedtea ebuilds. > You then build openjdk with oracle or icedtea via USE flag. > > Icedtea will always lag from Oracle. There will always be oracle > binaries before others. Yes you can build the source against it, but no > one is working on that. Again Gentoo has what it does because of > RedHat. Really for RedHats own interest, not Gentoo. Gentoo just > benefits. > > It would likely be a considerable effort to have a openjdk that can > build via oracle or icedtea/openjdk binaries. I think exherbo managed > that, I am not sure. > My response to this is the same as above: Can you explain why the Gentoo build system is the way it is? If you have any suggestions as to what I should look at to better understand the OpenJDK build system I would very much appreciate them. > The lagging may get worse as JDK release is scheduled to speed up > considerably come March. Say hello to Java 18.3 > https://mreinhold.org/blog/forward-faster > >> The Oracle binaries seem to work well for me and I have experienced no >> issues. Notably, Scala works transparently on the Oracle JDK 9. What >> kind of issues are you seeing? The biggest issue I have had is that >> some version tests do not parse "9" the same way as "1.8.0_152". > > There are tons of build issues for Java packages in tree. From not > supporting < 1.6 source/target, The whole modules system. Changes with > class visibility and deprecation of sun.* classes. No tools.jar. Odd > build issues where some packages build fine under 1.8, but generate > errors under 9 that require code fixes. > > A slew of issues that Gentoo already lacks man power to keep some stuff > current. The amount of work is pretty tremendous on t
Re: [gentoo-dev] Java 9 on Gentoo
On Thu, 16 Nov 2017 23:38:09 -0600 R0b0t1 wrote: > > Hopefully this is not a tangent, but the OpenJDK release is available > on Ubuntu. I have tried to understand the IcedTea build process and > failed, as I was hoping that it could be packaged for Gentoo before > the official IcedTea release. I was not able to find a timeline from > the OpenJDK project. Gentoo is a from source distro not binary. It will be some time before icedtea, some version support slot 9 will be available. There is no eta for icedtea. That comes from directly from RedHat. The person who makes it for the world does so on Gentoo, for RedHat their employer. I tried for years to get others to make a path for them to be able to become a dev and work in tree. Rather that work goes into java-overlay and is proxied to tree by Chewi/James. https://github.com/gentoo/java-overlay/tree/master/dev-java/icedtea > You focus on Oracle's Java? Yes, in brief, as the other will always lag. I would be some what interested in a actual OpenJDK package. That could build with either oracle or icedtea. Usually for production and business purposes people want to run Oracle. I do not know many who run icedtea/openjdk. Though I am sure they are out there. Definitely RedHat customers. Also icedtea on Gentoo does not have OpenJavaFX. I am not sure any distro has OpenJavaFX packaged. I am not aware of any ebuilds ever for that. Probably be me someday if I ever have interest. Which can bind many to oracle for JavaFX. Which includes myself. Icedtea really is not a jdk but a build system. On Gentoo only it becomes the name of the JDK/JRE. It really is just OpenJDK built without Oracle. Ideally there is oracle, openjdk, and icedtea ebuilds. You then build openjdk with oracle or icedtea via USE flag. Icedtea will always lag from Oracle. There will always be oracle binaries before others. Yes you can build the source against it, but no one is working on that. Again Gentoo has what it does because of RedHat. Really for RedHats own interest, not Gentoo. Gentoo just benefits. It would likely be a considerable effort to have a openjdk that can build via oracle or icedtea/openjdk binaries. I think exherbo managed that, I am not sure. The lagging may get worse as JDK release is scheduled to speed up considerably come March. Say hello to Java 18.3 https://mreinhold.org/blog/forward-faster > The Oracle binaries seem to work well for me and I have experienced no > issues. Notably, Scala works transparently on the Oracle JDK 9. What > kind of issues are you seeing? The biggest issue I have had is that > some version tests do not parse "9" the same way as "1.8.0_152". There are tons of build issues for Java packages in tree. From not supporting < 1.6 source/target, The whole modules system. Changes with class visibility and deprecation of sun.* classes. No tools.jar. Odd build issues where some packages build fine under 1.8, but generate errors under 9 that require code fixes. A slew of issues that Gentoo already lacks man power to keep some stuff current. The amount of work is pretty tremendous on top of the state of the tree. Out of some 160 packages I had installed, 48 failed, with some 600+ to test still. There were more failures before some fixes. I am still working on fixing those and there are likely a considerable amount more. My overlay is already ahead of the tree in many ways. The tree has to play additional catchup. The tree itself without my overlay may have may more issues. I do not know. I am working on replacing all packages in tree, not running them. I need them kept current. > Adding Java 9 to the tree would help users who are interested > experiment with the language. The JDK/JRE could go into tree masked for anyone who wants to unmask. I have been pushing for that for some time, but will only happen when Chewi/James has time. JRE is safer than JDK. There will be issues with JDK if set to system VM and used to build Java packages on Gentoo. The mask should warn about such, etc. > As part of the first work on Python 3.5 > (very minor) I installed it on my system but did not add it to > PYTHON_TARGETS. Is there an equivalent for Java? Heck no, Java is not in my opinion an pain like Ruby and Python. Perl is not either. In fact if I get time to re-write eclasses. I plan to move the versions from in ebuilds to eclass. Making 1 place to update source/target/release of a java package. Right now Java is controlled via depends. The DEPEND version sets the -source, and RDEPEND the -target version. Java 9 has a new -release. The source/target has long time issue on Gentoo. To trigger you build with newer and run with older. https://wiki.gentoo.org/wiki/Java_Developer_Guide#Bootstrap_class_path > I have read the bug discussing your retirement. It is not possible for > me to ascertain what led to disciplinary action. The lack of concrete > discussion on behavior to be addressed reflects poorly on those who > sought disciplinary action. The whol
Re: [gentoo-dev] Java 9 on Gentoo
Hello friends! I am excited about Java 9. However, I am a very excitable person. Hopefully this is not a tangent, but the OpenJDK release is available on Ubuntu. I have tried to understand the IcedTea build process and failed, as I was hoping that it could be packaged for Gentoo before the official IcedTea release. I was not able to find a timeline from the OpenJDK project. On Thu, Nov 16, 2017 at 10:41 PM, William L. Thomson Jr. wrote: > On Thu, 16 Nov 2017 21:42:59 -0600 > Matthew Thode wrote: >> >> You seem to know a bit about this, has there been a bug made outlining >> the troubles we will encounter as you know them? > > No, I feel I am already doing more than I should to help given my past > treatment. I have been making most issues with potential resolutions > know in #gentoo-java for the past ~48 hours. I have been spending > most time fixing stuff in my overlay. As I have been for over a year. > https://github.com/Obsidian-StudiosInc/os-xtoo > You focus on Oracle's Java? >> It's nice to have a warning, but sounding alarmist without concrete >> help doesn't actually help all that much. > > People have been asking in #gentoo-java about Java 9. I was simply > letting everyone know it would be some time before that is likely to be > the case. That alone was a courtesy to others. > > It does not take much to find out there are considerable issues with > Java 9 from most any web search. For anyone who cares, most do not. > Thus the present state of Java on Gentoo. Which I have brought up many > times over the past years. A new major version taking some time should > not be of surprise to anyone given that fact. > The Oracle binaries seem to work well for me and I have experienced no issues. Notably, Scala works transparently on the Oracle JDK 9. What kind of issues are you seeing? The biggest issue I have had is that some version tests do not parse "9" the same way as "1.8.0_152". Adding Java 9 to the tree would help users who are interested experiment with the language. As part of the first work on Python 3.5 (very minor) I installed it on my system but did not add it to PYTHON_TARGETS. Is there an equivalent for Java? > If you recall I got banned from Github over commenting on Java 9 early > access PR. I have also commented on another since. > https://github.com/gentoo/gentoo/pull/1721 > https://github.com/gentoo/gentoo/pull/6033 > > You can see the history of jdk 9 I put in my overlay almost a year ago. > That could have been in Gentoo. I maintained EA builds till release... > Dec 5, 2016 > https://github.com/Obsidian-StudiosInc/os-xtoo/commit/f90d8b21c39dbe8684e0951b845c43fae2ba6cfc#diff-0ecef02a46ed32d29b482614d71d229f > https://github.com/Obsidian-StudiosInc/os-xtoo/commits/master/dev-java/oracle-jdk-bin > That looks promising, thank you. > I have done all I can. This is the visible result of blocking people, > with no one else wiling to do the work. I am playing catch up now. > I have read the bug discussing your retirement. It is not possible for me to ascertain what led to disciplinary action. The lack of concrete discussion on behavior to be addressed reflects poorly on those who sought disciplinary action. However, I am not a very smart man. I am usually wrong. Hopefully someone who is much more intelligent than I can explain how I have erred in my opinion. Respectfully, R0b0t1.
Re: [gentoo-dev] Java 9 on Gentoo
On Thu, 16 Nov 2017 21:42:59 -0600 Matthew Thode wrote: > > You seem to know a bit about this, has there been a bug made outlining > the troubles we will encounter as you know them? No, I feel I am already doing more than I should to help given my past treatment. I have been making most issues with potential resolutions know in #gentoo-java for the past ~48 hours. I have been spending most time fixing stuff in my overlay. As I have been for over a year. https://github.com/Obsidian-StudiosInc/os-xtoo > It's nice to have a warning, but sounding alarmist without concrete > help doesn't actually help all that much. People have been asking in #gentoo-java about Java 9. I was simply letting everyone know it would be some time before that is likely to be the case. That alone was a courtesy to others. It does not take much to find out there are considerable issues with Java 9 from most any web search. For anyone who cares, most do not. Thus the present state of Java on Gentoo. Which I have brought up many times over the past years. A new major version taking some time should not be of surprise to anyone given that fact. If you recall I got banned from Github over commenting on Java 9 early access PR. I have also commented on another since. https://github.com/gentoo/gentoo/pull/1721 https://github.com/gentoo/gentoo/pull/6033 You can see the history of jdk 9 I put in my overlay almost a year ago. That could have been in Gentoo. I maintained EA builds till release... Dec 5, 2016 https://github.com/Obsidian-StudiosInc/os-xtoo/commit/f90d8b21c39dbe8684e0951b845c43fae2ba6cfc#diff-0ecef02a46ed32d29b482614d71d229f https://github.com/Obsidian-StudiosInc/os-xtoo/commits/master/dev-java/oracle-jdk-bin I have done all I can. This is the visible result of blocking people, with no one else wiling to do the work. I am playing catch up now. -- William L. Thomson Jr. pgpDnE5BlR_1f.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Java 9 on Gentoo
On 17-11-16 15:17:15, William L. Thomson Jr. wrote: > Just as a heads up, pass it along. For anyone interested. It will be > some time before Java 9 is available on Gentoo. It will take > considerable work to get it unmasked and safe for use. > > Once in tree masked, it will likely be very painful for anyone who does > unmask. You have been forewarned!!! > > NOT FUD! > Constructive heads up as to the factual state of things. If > you would like to see them change. Talk to Chewi/James Le Cuirot. He > will need lots of help! Even with others I guestimate a month or more > before it can be unmasked. Once its added to tree... > > -- > William L. Thomson Jr. You seem to know a bit about this, has there been a bug made outlining the troubles we will encounter as you know them? It's nice to have a warning, but sounding alarmist without concrete help doesn't actually help all that much. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
[gentoo-dev] Java 9 on Gentoo
Just as a heads up, pass it along. For anyone interested. It will be some time before Java 9 is available on Gentoo. It will take considerable work to get it unmasked and safe for use. Once in tree masked, it will likely be very painful for anyone who does unmask. You have been forewarned!!! NOT FUD! Constructive heads up as to the factual state of things. If you would like to see them change. Talk to Chewi/James Le Cuirot. He will need lots of help! Even with others I guestimate a month or more before it can be unmasked. Once its added to tree... -- William L. Thomson Jr. pgpyjGgp4pQab.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-qt/qtwebkit:4 and remaining rdeps
# Andreas Sturmlechner (16 Nov 2017) # Qt4WebKit is ancient and full of security holes. # Masked for removal in 30 days. Bug #620684 dev-qt/qtwebkit:4 # Andreas Sturmlechner (16 Nov 2017) # Depends on dead Qt4WebKit. Masked for removal in 30 days. Bug #620826 # Needs someone to package release 2.1 which is Qt5-based. (16 Nov 2017) # Depends on dead Qt4WebKit. Masked for removal in 30 days. Bug #620702 # Qt5-based packaging efforts need help in bug #622726 (16 Nov 2017) # Depends on dead Qt4WebKit. Masked for removal in 30 days. Bug #620736 # Needs someone to package release 13 which is Qt5-based. =net-misc/teamviewer-10* =net-misc/teamviewer-11* =net-misc/teamviewer-12*
Re: [gentoo-dev] cmake + ninja vs autotools
On Thu, 16 Nov 2017 09:17:52 -0700 Christoph Junghans wrote: > > > Ninja doesn't support Fortran as well. > Besides not supporting the full feature set. That does not seem to be effecting meson. Which only supports ninja. A considerable amount of projects are switching to meson, look around. I have switched over a couple projects I am working on. I have worked with all three, autotools, cmake, and meson. I prefer cmake + ninja. The performance of meson vs cmake is negligible. Given cmake cpack, I prefer that for now over meson. I could not make a strong case for speed of cmake vs meson. That is moot speed wise, pretty equal. Meson maybe a tad faster. > 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. It is making huge differences in other projects. I have seen considerable time savings in the smaller projects I am working on, ecrire, entrance, clipboard, and some others. Enlightenment desktop for 0.23 release will have dropped autotools entirely for meson. 0.22 already ships with meson. I switched over and it builds faster. No problems there with ninja. I think EFL may switch to meson as well. Other E projects like rage have already. > 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. Maybe time to check again. My experience says otherwise. I can switch over some stuff in travis and show via CI the difference in time. I see it all the time in development doing routine builds as part of code, build, test, code, etc. Rinse and repeat. -- William L. Thomson Jr. pgpaAQR5qEBTJ.pgp Description: OpenPGP digital signature
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
>
>
Re: [gentoo-dev] [PATCH] out-of-source.eclass: A new eclass to help with out-of-source builds
On Thu, 2017-11-16 at 14:48 +0100, Michał Górny wrote: > // NB: I'm not sure if I haven't submitted it already but that was > // a long time ago, so let's try again. Requested by soap. > > The out-of-source.eclass is a simple multilib-minimal-style wrapper > to perform out of source builds of autotools (and other) packages. It > is > mostly derived from the function served in the past by autotools- > utils > since a number of developers found it useful. However, in order to > avoid > the mistakes of autotools-utils, it is meant to be focused on a > single > feature and have a better API. > > This eclass has two use cases: > > 1. Ensuring that packages are tested with out-of-source builds. > > 2. Improving consistency between multilib and non-multilib packages. > > In the most basic form, it just redefines the phases from > src_configure() > to src_install() with out-of-source wrappers. However, each phase can > be overriden using my_src_*() sub-phase that is run inside build dir > (alike multilib_src_*() in multilib-minimal). There is also > my_src_install_all() for the trailing source-dir actions. +1
[gentoo-dev] [PATCH] out-of-source.eclass: A new eclass to help with out-of-source builds
// NB: I'm not sure if I haven't submitted it already but that was
// a long time ago, so let's try again. Requested by soap.
The out-of-source.eclass is a simple multilib-minimal-style wrapper
to perform out of source builds of autotools (and other) packages. It is
mostly derived from the function served in the past by autotools-utils
since a number of developers found it useful. However, in order to avoid
the mistakes of autotools-utils, it is meant to be focused on a single
feature and have a better API.
This eclass has two use cases:
1. Ensuring that packages are tested with out-of-source builds.
2. Improving consistency between multilib and non-multilib packages.
In the most basic form, it just redefines the phases from src_configure()
to src_install() with out-of-source wrappers. However, each phase can
be overriden using my_src_*() sub-phase that is run inside build dir
(alike multilib_src_*() in multilib-minimal). There is also
my_src_install_all() for the trailing source-dir actions.
---
eclass/out-of-source.eclass | 124
1 file changed, 124 insertions(+)
create mode 100644 eclass/out-of-source.eclass
diff --git a/eclass/out-of-source.eclass b/eclass/out-of-source.eclass
new file mode 100644
index ..4d9c8d05fd64
--- /dev/null
+++ b/eclass/out-of-source.eclass
@@ -0,0 +1,124 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: out-of-source.eclass
+# @MAINTAINER:
+# Michał Górny
+# @BLURB: convenient wrapper to build autotools packages out-of-source
+# @DESCRIPTION:
+# This eclass provides a minimalistic wrapper interface to easily
+# build autotools (and alike) packages out-of-source. It is meant
+# to resemble the interface used by multilib-minimal without actually
+# requiring the package to be multilib.
+#
+# For the simplest ebuilds, it is enough to inherit the eclass
+# and the new phase functions will automatically build the package
+# out-of-source. If you need to redefine one of the default phases
+# src_configure() through src_install(), you need to define
+# the matching sub-phases: my_src_configure(), my_src_compile(),
+# my_src_test() and/or my_src_install(). Those sub-phase functions
+# will be run inside the build directory. Additionally,
+# my_src_install_all() is provided to perform doc-install and other
+# common tasks that are done in source directory.
+#
+# Example use:
+# @CODE
+# inherit out-of-source
+#
+# my_src_configure() {
+# econf \
+# --disable-static
+# }
+# @CODE
+
+case ${EAPI} in
+ 6);;
+ *) die "EAPI ${EAPI:-0} unsupported (too old)";;
+esac
+
+EXPORT_FUNCTIONS src_configure src_compile src_test src_install
+
+if [[ ! ${_OUT_OF_SOURCE_ECLASS} ]]; then
+
+# @FUNCTION: out-of-source_src_configure
+# @DESCRIPTION:
+# The default src_configure() implementation establishes a BUILD_DIR,
+# sets ECONF_SOURCE to the current directory (usually S), and runs
+# my_src_configure() (or the default) inside it.
+out-of-source_src_configure() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ # set some BUILD_DIR if we don't have one yet
+ : "${BUILD_DIR:=${WORKDIR}/${P}_build}"
+ local ECONF_SOURCE=${PWD}
+
+ mkdir -p "${BUILD_DIR}" || die
+ pushd "${BUILD_DIR}" >/dev/null || die
+ if declare -f my_src_configure >/dev/null ; then
+ my_src_configure
+ else
+ default_src_configure
+ fi
+ popd >/dev/null || die
+}
+
+# @FUNCTION: out-of-source_src_compile
+# @DESCRIPTION:
+# The default src_compile() implementation runs my_src_compile()
+# (or the default) inside the build directory.
+out-of-source_src_compile() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ pushd "${BUILD_DIR}" >/dev/null || die
+ if declare -f my_src_compile >/dev/null ; then
+ my_src_compile
+ else
+ default_src_compile
+ fi
+ popd >/dev/null || die
+}
+
+# @FUNCTION: out-of-source_src_test
+# @DESCRIPTION:
+# The default src_test() implementation runs my_src_test()
+# (or the default) inside the build directory.
+out-of-source_src_test() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ pushd "${BUILD_DIR}" >/dev/null || die
+ if declare -f my_src_test >/dev/null ; then
+ my_src_test
+ else
+ default_src_test
+ fi
+ popd >/dev/null || die
+}
+
+# @FUNCTION: out-of-source_src_install
+# @DESCRIPTION:
+# The default src_install() implementation runs my_src_install()
+# (or the 'make install' part of the default) inside the build directory,
+# followed by a call to my_src_install_all() (or 'einstalldocs' part
+# of the default) in the original working directory.
+out-of-source_src_install() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ pushd "${BUILD_DIR}" >/dev/null || die
+ if declare -f my_src_install >/dev/null ; then
+
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
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...
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
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [RFC] GLEP 74 post-Council review update
Hi, everyone. Here's the updated version of GLEP 74 taking into consideration the points made during the Council pre-review. ReST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html Changes: 09ed01f glep-0074: Explain combining multiple Manifest trees 9de0840 glep-0074: Clarify timestamp handling of sub-Manifests 516c2ec glep-0074: Forbid compressing top-level Manifest b01783e glep-0074: Clarify sub-Manifest signing paragraph --- GLEP: 74 Title: Full-tree verification using Manifest files Author: Michał Górny , Robin Hugh Johnson , Ulrich Müller Type: Standards Track Status: Draft Version: 1 Created: 2017-10-21 Last-Modified: 2017-11-16 Post-History: 2017-10-26, 2017-11-16 Content-Type: text/x-rst Requires: 59, 61 Replaces: 44, 58, 60 --- Abstract This GLEP extends the Manifest file format to cover full-tree file integrity and authenticity checks.The format aims to be future-proof, efficient and provide means of backwards compatibility. Motivation == The Manifest files as defined by GLEP 44 [#GLEP44]_ provide the current means of verifying the integrity of distfiles and package files in Gentoo. Combined with OpenPGP signatures, they provide means to ensure the authenticity of the covered files. However, as noted in GLEP 57 [#GLEP57]_ they lack the ability to provide full-tree authenticity verification as they do not cover any files outside the package directory. In particular, they provide multiple ways for a third party to inject malicious code into the ebuild environment. Historically, the topic of providing authenticity coverage for the whole repository has been mentioned multiple times. The most noteworthy effort are GLEPs 58 [#GLEP58]_ and 60 [#GLEP60]_ by Robin H. Johnson from 2008. They were accepted by the Council in 2010 but have never been implemented. When potential implementation work started in 2017, a new discussion about the specification arose. It prompted the creation of a competing GLEP that would provide a redesigned alternative to the old GLEPs. This specification is designed with the following goals in mind: 1. It should provide means to ensure the authenticity of the complete repository, including preventing the injection of additional files. 2. The format should be universal enough to work both for the Gentoo repository and third-party repositories of different characteristics. 3. The Manifest files should be verifiable stand-alone, that is without knowing any details about the underlying repository format. Specification = Manifest file format This specification reuses and extends the Manifest file format defined in GLEP 44 [#GLEP44]_. For the purpose of it, the *file type* field is repurposed as a generic *tag* that could also indicate additional (non-checksum) metadata. Appropriately, those tags can be followed by other space-separated values. Unless specified otherwise, the paths used in the Manifest files are relative to the directory containing the Manifest file. The paths must not reference the parent directory (``..``). Manifest file locations and nesting --- The ``Manifest`` file located in the root directory of the repository is called top-level Manifest, and it is used to perform the full-tree verification. In order to verify the authenticity, it must be signed using OpenPGP, using the armored cleartext format. The top-level Manifest may reference sub-Manifests contained in subdirectories of the repository. The sub-Manifests are traditionally named ``Manifest``; however, the implementation must support arbitrary names, including the possibility of multiple (split) Manifests for a single directory. The sub-Manifest can only cover the files inside the directory tree where it resides. The sub-Manifest can also be signed using OpenPGP armored cleartext format. However, the signature verification can be omitted since it already is covered by the signed top-level Manifest. Directory tree coverage --- The specification provides three ways of skipping Manifest verification of specific files and directories (recursively): 1. explicit ``IGNORE`` entries in Manifest files, 2. injected ignore paths via package manager configuration, 3. using names starting with a dot (``.``) which are always skipped. All files that are not ignored must be covered by at least one of the Manifests. A single file may be matched by multiple identical or equivalent Manifest entries, if and only if the entries have the same semantics, specify the same size and the checksums common to both entries match. It is an error for a single file to be matched by multiple entries of different semantics, file size or checksum values. It is an error to specify another entry for a file matching ``IGNORE``, or one of its subdirectories. The file entries (except for ``IGNORE``) can be specified for regular file
