Standard LEX variable doesn't work in Make.

Standard LEX variable doesn't work in Make.

[Kaz Kylheku]

Hi,

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.

Anyway, even though my Cygwin installation has GNU Flex,
the lex command is nonexistent; thus the $(LEX) Make
variable fails.

Either LEX should go to "flex", or there should be a
"lex" alias.

If the installation has some sort of lex, the
predefined $(LEX) variable should resolve to it.



--
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

Re: Standard LEX variable doesn't work in Make.

[Ken Brown]

On 11/21/2016 11:57 AM, Kaz Kylheku wrote:
> Hi,
>
> 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.
>
> Anyway, even though my Cygwin installation has GNU Flex,
> the lex command is nonexistent; thus the $(LEX) Make
> variable fails.
>
> Either LEX should go to "flex", or there should be a
> "lex" alias.
>
> If the installation has some sort of lex, the
> predefined $(LEX) variable should resolve to it.

Shouldn't your configure script take care of this?  There's an autoconf 
macro AC_PROG_LEX that you can use.

Ken


--
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

Re: Standard LEX variable doesn't work in Make.

[Hans-Bernhard Bröker]

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.


--
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

Re: Standard LEX variable doesn't work in Make.

[Brian Inglis]

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

Re: Standard LEX variable doesn't work in Make.

[Hans-Bernhard Bröker]

Am 25.11.2016 um 15:31 schrieb Brian Inglis:

> One solution, and the most common in Cygwin, is the package flex should
> create a symlink lex if no such symlink or exe exists;

In this case I believe that would be less than fully correct, because 
flex is not a clean drop-in replacement for generic lex.  For that one 
has to add the '-l' flag. So instead of a symlink one would use a 
wrapper script much like the 'yacc' script found in the 'bison' package, 
i.e.:

	#! /bin/sh
	exec /usr/bin/flex -l "$@"

 > 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.

I don't think 'alternatives' is applicable here.  We're not looking at 
several packages providing the same file --- we're looking at

* single packages offering the same executable under more than one name, 
causing it to express different personalities, like ex -> vi.exe, view 
-> vi.exe, latex --> pdftex.exe,

* a subsystem like texlive installing a truckload of executable scripts 
somewhere else, and links from /bin to them.

So while I agree that the 'alternatives' mechanism could, or even should 
be used more in Cygwin, I don't think this is one of the cases where 
that applies.


--
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

Re: Standard LEX variable doesn't work in Make.

[Brian Inglis]

On 2016-11-25 17:08, Hans-Bernhard Bröker wrote:
> Am 25.11.2016 um 15:31 schrieb Brian Inglis:
>
>> One solution, and the most common in Cygwin, is the package flex should
>> create a symlink lex if no such symlink or exe exists;
>
> In this case I believe that would be less than fully correct, because
> flex is not a clean drop-in replacement for generic lex. For that one
> has to add the '-l' flag. So instead of a symlink one would use a
> wrapper script much like the 'yacc' script found in the 'bison'
> package, i.e.:
>
>     #! /bin/sh
>     exec /usr/bin/flex -l "$@"

On Debian both yacc and bison.yacc are alternatives;

>> 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.
>
> I don't think 'alternatives' is applicable here. We're not looking at
> several packages providing the same file --- we're looking at
>
> * single packages offering the same executable under more than one
> name, causing it to express different personalities, like ex ->
> vi.exe, view -> vi.exe, latex --> pdftex.exe,

and all vi, vim, nvi, elvis etc. links are handled via alternatives:
it's used as the canonical example in

	https://wiki.debian.org/DebianAlternatives
  
> * a subsystem like texlive installing a truckload of executable
> scripts somewhere else, and links from /bin to them.

but tex uses no alternatives.

> So while I agree that the 'alternatives' mechanism could, or even
> should be used more in Cygwin, I don't think this is one of the cases
> where that applies.

Cygwin currently seems to follow the RH/RHEL/Fedora model using it in
limited cases. Not running Cygwin/X I don't know if it is used for X
or Gnome packages, where it is used extensively in Debian-based distros.
One commenter on Debian notes it is also used for: "
- cases where you've got a common name referring to specific name
   (like emacs-->/usr/bin/emacs20)
- cases where an older style name refers to the modern equivalent
   (maybe cc-->/usr/bin/gcc or csh-->/usr/bin/tcsh or rcp-->/usr/bin/scp)
- cases where a Unix-style name refers to the modern GNU equivalent
   (like yacc-->/usr/bin/bison)."
and I'd add it is also used for some versioned .so files and language
variants, so it appears it can apply wherever the packager decides it
should.
Cygport currently supports it for postinstall(/preremove) in the berkdb
cygclass and Google shows some other packages also appear to use it.
Perhaps Cygwin packages should use it more, whenever symlink creation
is considered for some component.

-- 
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

Re: Standard LEX variable doesn't work in Make.

[Hans-Bernhard Bröker]

Am 26.11.2016 um 04:42 schrieb Brian Inglis:

> On Debian both yacc and bison.yacc are alternatives;

Not exactly.  bison.yacc is a script; the same one that Cygwin's bison 
package installed as /usr/bin/yacc.  Debian obviously renamed it.  They 
have to do that because their yacc is an alternative.  And that's 
because there are at least 4 programs available in the package 
repository that can fulfill that role: bison, bison++, byacc and btyacc.

Nor do they use alternatives to build their symlink lex -> flex.

>> I don't think 'alternatives' is applicable here. We're not looking at
>> several packages providing the same file --- we're looking at
>>
>> * single packages offering the same executable under more than one
>> name, causing it to express different personalities, like ex ->
>> vi.exe, view -> vi.exe, latex --> pdftex.exe,
>
> and all vi, vim, nvi, elvis etc. links are handled via alternatives:
> it's used as the canonical example in

... the canonical example for multiple packages supplying the same 
program, 'vi'.  Cygwin has only 'vim', not nvi or elvis, so there's no 
need for the alternatives mechanism.

Just because alternative manages symlinks in /usr/bin, that doesn't mean 
every symlink in /usr/bin has to, or even should, be managed by it.

--
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