You need to handle the static buildtime/buildhost more carefully: the intent
with build time was to have one constant and consistent timestamp everywhere
during the build no matter where accessed (first access timestamps the entire
build).
Similarly, the build host (which is supposed to be the
I'm definitely interested in the patches @RPM5 (even if rather uninterested in
a NSPR thread pool: I believe there are better alternatives, like OMP: YMMV).
Let me look at what was needed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
Updated this PR to use a static variable.
I'm still fine with either solution, but @pmatilai and @megaumi @ffesti - can
someone weigh in, please?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
proyvind commented on this pull request.
> @@ -14,6 +14,8 @@
#include
#include
+#include/* NSPR thread pools */
openmp, unless for some reason would turn out to be unfeasiable, would be the
definitive candidate IMO given it's standardization and implementation
ignatenkobrain commented on this pull request.
> @@ -14,6 +14,8 @@
#include
#include
+#include/* NSPR thread pools */
openmp?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo commented on this pull request.
> @@ -14,6 +14,8 @@
#include
#include
+#include/* NSPR thread pools */
It'd be pretty hard for me to compile this on Mac OS now, as the Netscape stuff
is difficult to bootstrap.
--
You are receiving this because you are
ignatenkobrain commented on this pull request.
> @@ -14,6 +14,8 @@
#include
#include
+#include/* NSPR thread pools */
@kanavin NSS is not hard dependency, it has support for openssl and other
crypto backend and I would say that NSS is hardest to bootstrap so we
kanavin commented on this pull request.
> @@ -14,6 +14,8 @@
#include
#include
+#include/* NSPR thread pools */
rpm already has a hard dependency on nss, and nss has a hard dependency on
nspr, so it seemed obvious to utilize the thread pool API from nspr. Why you
are
ignatenkobrain commented on this pull request.
> @@ -14,6 +14,8 @@
#include
#include
+#include/* NSPR thread pools */
I'm kinda reluctant for such external dependencies
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
cool!
I'll try get around reviewing it myself at least when I find the time, then
provide feedback and/or my approval of (FWIW). :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@proyvind @simotek There you go, pull request created :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Please see here for background information and rationale:
https://github.com/rpm-software-management/rpm/issues/211
Caveats:
- this work was based on an older commit from master that Yocto is currently
using. I have rebased it to latest upstream master, but did not test that the
rebased version
12 matches
Mail list logo