DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:subject:reply-to:references:to:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=FysZRsCfiTlENI+s
	4V7UEBdDBq3cmFRxPvMiD/YTxgQHLzLNr9OldrcNN0/LqnHn38VHJBenld4Abqh/
	Ujz8ZaHKhyY+BVu2D/cv5WGEwXxGTdn26AWEPi0lLr1o5m9v4IqreQKdCKeJ4t8Q
	eZcIdkOznV8EP3f7Ix6pf6sFqHc=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
Subject: Re: Standard LEX variable doesn't work in Make.
Reply-To: Brian.Inglis@SystematicSw.ab.ca
References: <d06883e8208624afb5d094ebd3e78375@mail.kylheku.com> <11448207-52c8-6745-999f-48a4534bbc41@t-online.de>
To: cygwin@cygwin.com
Message-ID: <eee3ac0a-6715-1517-9045-2e2ac8544c66@SystematicSw.ab.ca>
Date: Fri, 25 Nov 2016 07:31:15 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <11448207-52c8-6745-999f-48a4534bbc41@t-online.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2016-11-21 12:09, Hans-Bernhard Bröker wrote:
> Am 21.11.2016 um 17:57 schrieb Kaz Kylheku:
>
>> I'm changing a FOSS project to rely more on standard Make
>> vars such as CC and CFLAGS and such: use $(CC) for
>> the compiler unless told otherwise, incorporate $(CFLAGS)
>> if it is defined, and so forth. This is friendly toward
>> distro package maintainers.
>
> Not really. Package maintainers will almost universally expect your
> source to have some kind of 'configure' script, which would take of
> this and most other such properties for you.
>
>> Anyway, even though my Cygwin installation has GNU Flex,
>> the lex command is nonexistent; thus the $(LEX) Make
>> variable fails.
>
> It's not $(LEX) that's failing here; it's the way you form
> expectations about what $(LEX) is supposed to be. The value of $(LEX)
> is clearly documented to default to 'lex' (see "info make implicit
> implicit").
>
>> If the installation has some sort of lex, the
>> predefined $(LEX) variable should resolve to it.
>
> No. LEX is a modifiable variable, for the express purpose that it be
> set to what the system actually needs. Yes, that means _you_ are
> supposed to do that (or to set up tools outside make to do it for
> you).
>
> Morale: Make is not autoconf, nor does it want to be.
>
> One final note: your report is in no way specific to Cygwin, so this
> is almost certainly the wrong mailing list to send it to.

One solution, and the most common in Cygwin, is the package flex should
create a symlink lex if no such symlink or exe exists; or by the FHS,
create a group of alternatives, with a slave alternative for each of
its public components e.g. bin, man, info, etc. files.

Should Cygwin packages not be making more use of alternatives instead
of creating direct symlinks in bin?

I notice that out of 577 symlinks in Cygwin ...bin directories, sendmail
and automake-doc are the only packages I have that install alternatives:
5 symlinks in ...bin and 13 in /etc/alternatives to man, bin, info.
On my Debian system, out of 591 symlinks in ...bin directories, 126 are to
/etc/alternatives, in which there are 297 symlinks, most to man, bin, jvm,
and icons.
They seem to be heavily used to support virtual, X, Gnome, desktop, and
Java package provisioning and aliases, plus compilers, languages, editors,
and network functions.

Should there be promotion of alternatives instead of symlinks for
programs offering common functionality and options, or which support
multiple versions, in postinstall and preremove scripts?
What should the standard priority for standard programs be, for popular
non-standard programs that provide the same functions, and newer
versions (automake-doc adds 5 each version)?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple