[PATCH 2/2] wineinstall - Add support for parallel builds using 'nproc' to detect cpu count

[Chris Morgan]

On Sun, Feb 26, 2017 at 4:01 PM, Alexandre Julliard <julliard at winehq.org>
wrote:

> Sebastian Lackner <sebastian at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20170227/21dac510/attachment.html>