From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-39615-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 17965 invoked by alias); 12 Oct 2016 01:21:34 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 39615
Received: (qmail 24277 invoked from network); 12 Oct 2016 01:21:34 -0000
X-Qmail-Scanner-Diagnostics: from mail-vk0-f41.google.com by f.primenet.com.au (envelope-from <gmesalazar@gmail.com>, uid 7791) with qmail-scanner-2.11 
 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1.  
 Clear:RC:0(209.85.213.41):SA:0(0.0/5.0):. 
 Processed in 0.294307 secs); 12 Oct 2016 01:21:34 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,SPF_PASS,
	T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1
X-Envelope-From: gmesalazar@gmail.com
X-Qmail-Scanner-Mime-Attachments: |
X-Qmail-Scanner-Zip-Files: |
Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.213.41 as permitted sender)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc;
        bh=/T0Mt5YWfNlcWDlel7xBJ1BCeemlKdt0+stNU7y5R7Y=;
        b=UxyvKy6bZ9rOjPZXetuHw29NHPF2lVM9emgbrCQqH+dDsyYCW2muYbfxrc/HNDK+Q9
         h1rnkOGQaARI8WEAGBdTPKiQuoAU1x+Xr09H0nbQcGBVqEN0DRKv6L9r5s9vP4HyfA0N
         Og5agEP0FtGBjdf3YP0fBEnFaVERYW3Z4Yqrq8ELX1o+5Ig18p+v9ZsSAT5N7IL3SDVq
         bms+/gx2Vh6oBqKxAqV157XXjs/mMXZFo6POACV5BUgQnC7/imY+CixQkw1gQQLgmk05
         73bVeZh2IVvlrVEP7/QOZUQ3wljBjAu4P1HfaPOta4soB7O77iwPGKWmzigKOid/xrmu
         7TrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc;
        bh=/T0Mt5YWfNlcWDlel7xBJ1BCeemlKdt0+stNU7y5R7Y=;
        b=jW585WhVrwmzeGeHxAq1qNP2qXL/Mo7i3pUCMJoNZhsJEj6761JmesS2DH/Lpxh4kq
         Yh56of0N0h4JfaGLwPf3qZtM1VtSjeINQb9nLVKmoHDHRsUP+q/1pnJ/4gQRZLvVV2+R
         sGYQeXQOYVWgq1vz9UnboykUtK3qSqIgM3Rsvmh28clvuCkR/IB2q2OKDQb/omrMftnB
         swOUoWkWpym/GYjgkNILsjJa+KWNL8udSh9VnhExhsp+9H7jtAUZS6z2U7Cj6sDAAZNj
         najN00QM6KkcLvh/N9PjiEDVSJf3EqR2xvLk8vfKn140kjQGdhCR+AKii2HNfT0QKQa8
         kd0A==
X-Gm-Message-State: AA6/9RkaO8PXocBpiYLrb3uaS2nojnx31/2vhtk77omsfQbaE/v8FtLl/PzmCftuKX1IQCLwwWJfYgh1TFd2cg==
X-Received: by 10.31.88.197 with SMTP id m188mr5500244vkb.156.1476234864691;
 Tue, 11 Oct 2016 18:14:24 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20161012003606.GB32367@fujitsu.shahaf.local2>
References: <CA+Hmt2iOypn5PDukmM3TH1=g-194QC_6FLVeaM-U0vFG1YbO7w@mail.gmail.com>
 <20161011212150.GA24484@fujitsu.shahaf.local2> <CA+Hmt2h+jOFVcg1q9ujfTN0no1WJD2VyvuneRfZ+JJ1SW89cHQ@mail.gmail.com>
 <20161012000249.GA32367@fujitsu.shahaf.local2> <CA+Hmt2hoe-w2iQTi9yfK3kfT7PB6Oc_VKyk57OK2bgBXOgXczA@mail.gmail.com>
 <20161012003606.GB32367@fujitsu.shahaf.local2>
From: Guilherme Salazar <gmesalazar@gmail.com>
Date: Tue, 11 Oct 2016 22:14:04 -0300
Message-ID: <CA+Hmt2ixfYgbXduUgaqCQTFMWyT4BhCGp7A0XUwJJ++fJtxrkw@mail.gmail.com>
Subject: Re: zsh make(1) completion on FreeBSD
To: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: zsh-workers@zsh.org, Baptiste Daroussin <baptiste.daroussin@gmail.com>
Content-Type: text/plain; charset=UTF-8

> That's precisely what the _pick_variant call at the top of the function
> does, so you can just test $is_gnu instead.  Note that the enclosing if
> already inspects that variable.

$is_gnu will still give unix (on FreeBSD) in case `which make` is just
a symlink to /usr/local/bin/gmake.

> In current master (before your patch), the 'call-command' style is
> consulted only for GNU make but not for FreeBSD.  Do you know if that's
> intentional, perhaps (going by the style's docs) because the GNU make
> invocation has side-effects while the BSD make invocation has none?

I'd expect the -n option to avoid side effects. Perhaps the reason is
that the BSD make infrastructure is a lot different than GNU's and a
single Makefile may not carry enough information by itself to generate
good completion?