Hi all, At the moment, LLVM includes the .l, .y sources that are compiled by flex and biston via make. This is fine for most unix developers. For windows developers, it's a bit more of a pain to download flex/bison, but is still a one-time thing. However, anyone releasing an llvm frontend will require their users to have flex/bison. Most (but not all) unix boxes have them, but almost no windows boxes have them. This requires either 1) Forcing the user to dowload flex/bison (bad) 2) Distributing flex/bison with the front-end (not as bad, but a pain) 3) or, and this seems like a simple fix, just distribute the output of flex and bison along with the source. This is analagous to distributing "configure" along with "configure.ac". What do you guys think? -- -Alex
On Mon, 27 Jun 2005, Alexander Friedman wrote:> Hi all, > have flex/bison. Most (but not all) unix boxes have them, but almost > no windows boxes have them. This requires either > > 1) Forcing the user to dowload flex/bison (bad) > 2) Distributing flex/bison with the front-end (not as bad, but a pain) > > 3) or, and this seems like a simple fix, just distribute the output of > flex and bison along with the source. This is analagous to > distributing "configure" along with "configure.ac". > > What do you guys think?I agree that #1 and #2 are not wonderful solutions. If including the output of bison/flex in the source distro will fix the problem for you, I would support that. There are build changes required though and may be incompatibilities between unix bison and windows bison. If these were worked out and solved, I would like to see this happen :) -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
On 6/29/05, Chris Lattner <sabre at nondot.org> wrote:> On Mon, 27 Jun 2005, Alexander Friedman wrote: > > Hi all, > > have flex/bison. Most (but not all) unix boxes have them, but almost > > no windows boxes have them. This requires either > > > > 1) Forcing the user to dowload flex/bison (bad) > > 2) Distributing flex/bison with the front-end (not as bad, but a pain) > > > > 3) or, and this seems like a simple fix, just distribute the output of > > flex and bison along with the source. This is analagous to > > distributing "configure" along with "configure.ac". > > > > What do you guys think? > > I agree that #1 and #2 are not wonderful solutions. If including the > output of bison/flex in the source distro will fix the problem for you, I > would support that. There are build changes required though and may be > incompatibilities between unix bison and windows bison. If these were > worked out and solved, I would like to see this happen :)In my experience the only difference between recent bison versions on unix vs win32 is the inclusion of unistd (for isatty()). This is easily solved by adding a dummy unistd.h header which either defines isatty as a macro which always evaluates to zero, or actually implementing the function in a separate source file for win32. The first option would be preferred since the only required change would be an added include path for win32 in the makefile. // Andreas -- And I hate redundancy, and having different functions for the same thing. - Linus Torvalds on linux-kernel