* Standard LEX variable doesn't work in Make. @ 2016-11-21 17:33 Kaz Kylheku 2016-11-22 20:59 ` Ken Brown 2016-11-22 21:16 ` Hans-Bernhard Bröker 0 siblings, 2 replies; 7+ messages in thread From: Kaz Kylheku @ 2016-11-21 17:33 UTC (permalink / raw) To: Cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Standard LEX variable doesn't work in Make. 2016-11-21 17:33 Standard LEX variable doesn't work in Make Kaz Kylheku @ 2016-11-22 20:59 ` Ken Brown 2016-11-22 21:16 ` Hans-Bernhard Bröker 1 sibling, 0 replies; 7+ messages in thread From: Ken Brown @ 2016-11-22 20:59 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Standard LEX variable doesn't work in Make. 2016-11-21 17:33 Standard LEX variable doesn't work in Make Kaz Kylheku 2016-11-22 20:59 ` Ken Brown @ 2016-11-22 21:16 ` Hans-Bernhard Bröker 2016-11-25 19:54 ` Brian Inglis 1 sibling, 1 reply; 7+ messages in thread From: Hans-Bernhard Bröker @ 2016-11-22 21:16 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Standard LEX variable doesn't work in Make. 2016-11-22 21:16 ` Hans-Bernhard Bröker @ 2016-11-25 19:54 ` Brian Inglis 2016-11-26 23:51 ` Hans-Bernhard Bröker 0 siblings, 1 reply; 7+ messages in thread From: Brian Inglis @ 2016-11-25 19:54 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Standard LEX variable doesn't work in Make. 2016-11-25 19:54 ` Brian Inglis @ 2016-11-26 23:51 ` Hans-Bernhard Bröker 2016-11-27 3:04 ` Brian Inglis 0 siblings, 1 reply; 7+ messages in thread From: Hans-Bernhard Bröker @ 2016-11-26 23:51 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Standard LEX variable doesn't work in Make. 2016-11-26 23:51 ` Hans-Bernhard Bröker @ 2016-11-27 3:04 ` Brian Inglis 2016-11-27 16:02 ` Hans-Bernhard Bröker 0 siblings, 1 reply; 7+ messages in thread From: Brian Inglis @ 2016-11-27 3:04 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Standard LEX variable doesn't work in Make. 2016-11-27 3:04 ` Brian Inglis @ 2016-11-27 16:02 ` Hans-Bernhard Bröker 0 siblings, 0 replies; 7+ messages in thread From: Hans-Bernhard Bröker @ 2016-11-27 16:02 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-11-26 21:42 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-21 17:33 Standard LEX variable doesn't work in Make Kaz Kylheku 2016-11-22 20:59 ` Ken Brown 2016-11-22 21:16 ` Hans-Bernhard Bröker 2016-11-25 19:54 ` Brian Inglis 2016-11-26 23:51 ` Hans-Bernhard Bröker 2016-11-27 3:04 ` Brian Inglis 2016-11-27 16:02 ` Hans-Bernhard Bröker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).