On Sun, Feb 26, 2017 at 4:01 PM, Alexandre Julliard julliard@winehq.org wrote:
Sebastian Lackner sebastian@fds-team.de writes:
On 25.02.2017 01:40, Austin English wrote:
On Fri, Feb 24, 2017 at 6:30 PM, Chris Morgan chmorgan@gmail.com
wrote:
Parallel builds can greatly reduce the overall build time on modern
multi-core processors.
Fall back to two parallel builds in the case where nproc is
unavailable, most modern
processors have at least two cores.
Use the 'NPROC' value defined by the environment if it is not null.
Signed-off-by: Chris Morgan chmorgan@gmail.com
tools/wineinstall | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/tools/wineinstall b/tools/wineinstall index bfd62e3..080d590 100755 --- a/tools/wineinstall +++ b/tools/wineinstall @@ -143,10 +143,19 @@ echo "in the meantime..." echo std_sleep
+# If the NPROC environment variable isn't set use nproc, if
available, to determine
+# the number of processors in the system, if not, fall back to a
default NPROC value
+if type nproc2 &>/dev/null
I don't think this will do what you want ;)
Also, I'm pretty sure &> isn't Posix. You'd want something like: if type nproc > /dev/null 2>&1
Actually, shouldn't we first discuss if we really want to keep
wineinstall as part of the
repo before we merge any improvements? I don't know how many people are
using it, but it
lacks many important features. It does not install any dependencies,
does not warn about
problems during configure, and also does not support a proper wow64
build, ... Basically,
it could be replaced by a one-liner "./configure && make && su root -c
'make install'"...
Do we really want to keep it?
I didn't mind keeping it as long as it was just sitting there, but if we are going to start adding complexity or bikeshedding it, then it's probably better to remove it.
-- Alexandre Julliard julliard@winehq.org
wineinstall still serves a pretty useful purpose of making it very easy for people to get started building wine. We can update documentations or let users hunt around to figure out their distro specific ways of running make install or providing commands to check for potentially conflicting existing binaries of wine. Those are useful things even for people that are very familiar with building from source code. It can't be directly replaced by a one liner in most cases.
I'd recommend merging in my fixes and letting people use wineinstall to get started in building wine.
I'm all for adding distro specific dependencies. For fedora it was a lot of trouble finding dependencies. I don't see a good way to do the equivalent of 'apt-get build-dep wine' on fedora, so in that case it would be quite useful to help the user out with a list of dependencies, for debian maybe prompt or run 'apt-get build-dep wine' etc.
Chris