This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Standard LEX variable doesn't work in Make.
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