From: Keith M. <kei...@to...> - 2005-05-20 08:55:08
|
Max T. Woodbury wrote: > You have to start somewhere. I'm in the process of finding out > where. The MinGW kit (bison-1.875.0-2993.02.10-1) is a 1.875 (aka > 1.875a?) kit. CygWin has a 1.875b kit. With a little more thrashing > around, I will have something useful and we might be able to agree > that where I land is where we all want to be, but I've got to land > before we can do that... ;-) The canonical source *must* be the FSF's distribution, with the latest stable release found at http://ftp.gnu.org/gnu/bison Undoubtedly, patches will be required to get to a working MSYS implementation. The patches used in the MinGW 1.875.0-2993.02.10-1 version may provide inspiration, but IMHO, unless you *really* want to start, and maintain, your own private fork, you should adapt this patch set against the bison CVS, found via http://savannah.gnu.org/cvs/?group=bison and should feed the results back into that CVS, so that portability issues may be resolved at source. See http://www.gnu.org/software/bison/bison.html for further information. This is the approach I adopted, when I joined the groff project; as a result, groff-1.19.2, from CVS, is now pretty much an OOTB build with MinGW, with no need for any independently maintained fork. BTW, as Earnie keeps reminding us, Google is your friend. I found all of the above links from the first hit on `site:gnu.org bison'. Best regards, Keith. |
From: Keith M. <kei...@to...> - 2005-05-20 14:53:40
|
Max T. Woodbury wrote, quoting me: >> The canonical source *must* be the FSF's distribution, with the >> latest stable release found at >> >> http://ftp.gnu.org/gnu/bison > > I was looking for a CVS source, but that one will do if I can't > find one. I'm still trying to understand the build process and > how it differs between CygWin, MinGW and MSys. Once I have a > handle on that, I'll be able to make changes at other levels... Since bison is a GNU package, this *is* its definitive canonical source. The link above is for the most recent formal release; for the definitive CVS, it's got to be the second link I cited earlier >> >> http://savannah.gnu.org/cvs/?group=bison >> > ... In particular, I didn't see ANY reference to the CygWin.dll > and I know its in there someplace because the executable will not > run under MSys because it can't find it, even though I specified > a 'mingw' target. If you compile with the Cygwin gcc, then the cygwin1.dll dependency is automatic, unless you specify '-mno-cygwin'; it isn't sufficient to simply specify a 'mingw' target. > And I saw notes on the bison list which could be taken as an > indication that those _WIN32 blocks got retroed into a later version > of 1.875...) Which suggests that the bison maintainer is receptive to patches which facilitate portability to Win32 compilers :-) > It is really starting to look like I am actually going to have to > learn about autoconf. I knew I'd need that sometime, but I was > hoping it wouldn't be quite this soon... It's a worthwhile venture. A tip: don't waste time trying to analyse the generated 'configure' script; studying 'configure.ac', (older versions used 'configure.in' instead), 'aclocal.m4' and possibly 'acinclude.m4', while referring to 'info autoconf' is *much* more productive. BTW, I've just had a look at the browseable image of the bison CVS. It doesn't have either of the above 'm4' files; instead it puts stuff into 'configure.ac' which, IMHO, rightly belongs in 'aclocal.m4'. It also uses automake, which I personally detest, but "c'est la vie". If you're interested, the groff CVS, which is browseable at http://savannah.gnu.org/cgi-bin/viewcvs/groff/groff/ is a good example of how I prefer to see the division of labour between 'configure.ac' and 'aclocal.m4'; I simply prefer to see 'configure.ac' specifying a sequence of configuration tests to be performed, with the gory details of how to do them hidden away in 'aclocal.m4', which makes the configuration process clearer, IMHO. Best regards, Keith. |
From: Max T. W. <max...@ve...> - 2005-05-21 15:21:18
|
Keith MARSHALL wrote: > > Max T. Woodbury wrote, quoting me: > >> The canonical source *must* be the FSF's distribution, with the > >> latest stable release found at > >> > >> http://ftp.gnu.org/gnu/bison > > > > I was looking for a CVS source, but that one will do if I can't > > find one. I'm still trying to understand the build process and > > how it differs between CygWin, MinGW and MSys. Once I have a > > handle on that, I'll be able to make changes at other levels... > > Since bison is a GNU package, this *is* its definitive canonical > source. The link above is for the most recent formal release; for > the definitive CVS, it's got to be the second link I cited earlier > > >> > >> http://savannah.gnu.org/cvs/?group=bison > >> Sorry, I missed that. Thanks. > > ... In particular, I didn't see ANY reference to the CygWin.dll > > and I know its in there someplace because the executable will not > > run under MSys because it can't find it, even though I specified > > a 'mingw' target. > > If you compile with the Cygwin gcc, then the cygwin1.dll dependency > is automatic, unless you specify '-mno-cygwin'; it isn't sufficient > to simply specify a 'mingw' target. That helps. I have not dug into 'gcc' and it's friends yet. I'll get to it when I get there, but it's looking like that will not be a long time since I am making quite a bit of progress. > > And I saw notes on the bison list which could be taken as an > > indication that those _WIN32 blocks got retroed into a later version > > of 1.875...) > > Which suggests that the bison maintainer is receptive to patches which > facilitate portability to Win32 compilers :-) I get the impression from his response in the bison list that 'receptive' is a bit too strong. More like the attitude of an 'animal control' officer's response to a skunk -- he's got to take care of it, but he's not happy about it... (That may be a bit strong, but there was not a lot of enthusiasm in his response.) > > It is really starting to look like I am actually going to have to > > learn about autoconf. I knew I'd need that sometime, but I was > > hoping it wouldn't be quite this soon... > > It's a worthwhile venture. A tip: don't waste time trying to analyse > the generated 'configure' script; studying 'configure.ac', (older > versions used 'configure.in' instead), 'aclocal.m4' and possibly > 'acinclude.m4', while referring to 'info autoconf' is *much* more > productive. I spent most of yesterday going through the 'info' files on autoconf. I didn't get to the end but I went through enough to get a good idea on how it works. I will disagree about looking at the generated 'configure' scripts. Looking at any single one isn't going to help a lot but if you look at enough a pattern emerges, much like the pattern you'll get when you look at the machine code a compiler generates. Being able to look at this stuff is important because some packages do not seem to include proper precursor files, but I may be wrong about that. That insight about configure.[in|ac] and aclocal.m4 is something I hadn't gotten to yet. Thanks for the tip. > BTW, I've just had a look at the browseable image of the bison CVS. > It doesn't have either of the above 'm4' files; instead it puts stuff > into 'configure.ac' which, IMHO, rightly belongs in 'aclocal.m4'. It > also uses automake, which I personally detest, but "c'est la vie". > > If you're interested, the groff CVS, which is browseable at > > http://savannah.gnu.org/cgi-bin/viewcvs/groff/groff/ > > is a good example of how I prefer to see the division of labour between > 'configure.ac' and 'aclocal.m4'; I simply prefer to see 'configure.ac' > specifying a sequence of configuration tests to be performed, with the > gory details of how to do them hidden away in 'aclocal.m4', which makes > the configuration process clearer, IMHO. Thanks again. 'groff' is on my 'todo' list because of 'man', but that's another thing I'll get to when I get to it... [My, that brings back memories. I remember adding an include file capability to roff. That was a LONG time ago...] max |
From: David <db...@du...> - 2005-05-22 02:19:33
|
On Sat, May 21, 2005 at 11:20:59AM -0400, Max T. Woodbury wrote: > Keith MARSHALL wrote: > > > It is really starting to look like I am actually going to have to > > > learn about autoconf. I knew I'd need that sometime, but I was > > > hoping it wouldn't be quite this soon... > > > > It's a worthwhile venture. A tip: don't waste time trying to analyse > > the generated 'configure' script; studying 'configure.ac', (older > > versions used 'configure.in' instead), 'aclocal.m4' and possibly > > 'acinclude.m4', while referring to 'info autoconf' is *much* more > > productive. > > I spent most of yesterday going through the 'info' files on autoconf. > I didn't get to the end but I went through enough to get a good idea > on how it works. Pardon my butting in, and you may already be aware of what I will mention, but I'll do so just on the offshot that you haven't gotten to it yet. There are some tools with the autotools package that might give you a jumpstart, and they may well not even address the problems you are encountering. First, there's "autoscan". This will generate a configure.scan script that is _supposed_ to be a decent preliminary configure.ac script. It is not perfect.. you will undoubtedly still need to do some fixing. Also, in the autotools package, and the m4 chain, that deal with MinGW configuration stuff. I've not done a lot with the MinGW stuff but did come across some stuff that does seem to help. Secondly there's "autoreconf". This is a command that will run all the commands that need to be run to generate (or regenerate) the scripts (not including ./configure itself IIRC). That is, it does autoconf, aclocal, automake, etc. If any of this help, well and good, and if not, you can always just send it to /dev/null :) > I will disagree about looking at the generated 'configure' scripts. > Looking at any single one isn't going to help a lot but if you look > at enough a pattern emerges, much like the pattern you'll get when > you look at the machine code a compiler generates. Being able to > look at this stuff is important because some packages do not seem to > include proper precursor files, but I may be wrong about that. > > That insight about configure.[in|ac] and aclocal.m4 is something I > hadn't gotten to yet. Thanks for the tip. |
From: Max T. W. <max...@ve...> - 2005-05-22 17:01:09
|
David wrote: > > On Sat, May 21, 2005 at 11:20:59AM -0400, Max T. Woodbury wrote: > > Keith MARSHALL wrote: > > > > > It is really starting to look like I am actually going to have to > > > > learn about autoconf. I knew I'd need that sometime, but I was > > > > hoping it wouldn't be quite this soon... > > > > > > It's a worthwhile venture. A tip: don't waste time trying to analyse > > > the generated 'configure' script; studying 'configure.ac', (older > > > versions used 'configure.in' instead), 'aclocal.m4' and possibly > > > 'acinclude.m4', while referring to 'info autoconf' is *much* more > > > productive. > > > > I spent most of yesterday going through the 'info' files on autoconf. > > I didn't get to the end but I went through enough to get a good idea > > on how it works. > > Pardon my butting in, and you may already be aware of what I will > mention, but I'll do so just on the offshot that you haven't gotten to > it yet. > > There are some tools with the autotools package that might give you a > jumpstart, and they may well not even address the problems you are > encountering. > > First, there's "autoscan". This will generate a configure.scan script > that is _supposed_ to be a decent preliminary configure.ac script. It > is not perfect.. you will undoubtedly still need to do some fixing. > Also, in the autotools package, and the m4 chain, that deal with MinGW > configuration stuff. I've not done a lot with the MinGW stuff but did > come across some stuff that does seem to help. > > Secondly there's "autoreconf". This is a command that will run all the > commands that need to be run to generate (or regenerate) the scripts > (not including ./configure itself IIRC). That is, it does autoconf, > aclocal, automake, etc. > > If any of this help, well and good, and if not, you can always just > send it to /dev/null :) Not to /dev/null, but definitely to the 'later' queue. It will be useful when I get back to some of my own projects. Some of the problem I'm having is that I have become used to the GUI IDEs and I have not kept up with all the command line tools available. I'm in the process of correcting that defect... Meanwhile back on the scratch rebuild topic... I have had to conclude that 'bison' is almost FUBAR with respect to MinGW and MSys. I pulled the 1.875e source distribution from GNU and tried building it under MINGW32 with no luck. It would not configure under MSYS. Ernie's tool got it past that, but it then wanted 'autoconf'. When I put that in place, it still would not build right. So I went back to the MinGW 1.875 distribution. It built under MINGW32, but blew the regression tests starting with test 3. Again I tried it under MSYS and it would not configure. I think that 'bison' is going to need a fair amount of work to bring it up to date. However, 'byacc' can be used as a substitute for 'bison' in most cases, and 'byacc' built cleanly under MSYS. It was good enough to build 'flex'. I'm trying it on 'bash' at the moment. If that works, I'm simply going to put 'bison' on the slow track of the reconstruction project. I'll coordinate with Ernie to set its priority when I'm really up to speed. I did notice that 'autoconf' uses the same kind of regression test set as 'bison' and it is just as much of a resource hog. That suggests that both tests have a common framework and that framework could use some work. If someone knows who is working on that framework, it might be useful to post that here so that if I get to a point where I need to get these regression tests working, I'll have some place to start. On the other hand, there is always Goggle, so not having a contact point may not be a big deal anyway. max PS. 'bash' make blew, but that's another thread... |
From: Keith M. <kei...@to...> - 2005-05-23 09:36:24
|
Max T. Woodbury wrote: > I will disagree about looking at the generated 'configure' scripts. > Looking at any single one isn't going to help a lot but if you look at > enough a pattern emerges, much like the pattern you'll get when you > look at the machine code a compiler generates. Being able to look at > this stuff is important because some packages do not seem to include > proper precursor files, but I may be wrong about that. > > That insight about configure.[in|ac] and aclocal.m4 is something I > hadn't gotten to yet. Thanks for the tip. Max, I wasn't trying to suggest that you should *never* look at the generated configure scripts -- just not to waste too much time there, until you have a reasonably good grasp of how they are generated. The problem with trying to interpret a generated configure script, *before* understanding how it's constructed by autoconf, is that it's a huge monolithic collection of Bourne shell code, *very* intimidating and difficult to make sense of. Even the minimum possible AC_INIT AC_OUTPUT generates some 1800 lines of shell script, and that's just the standard initialisation and output code! Once you understand the function of configure.{in,ac} and aclocal.m4, you can use them as a "roadmap", to help you to make sense of the generated configure script itself. One thing which *really* is a "no-no": you must *never*, if you wish to preserve your sanity, modify any autotool generated script by hand editing! To modify "configure", you make appropriate changes in configure.ac, or in aclocal.m4, and then run autoconf to regenerate the configure script. When you get to this stage, *then* it can become quite enlightening to examine the generated configure script, to help you to understand, and debug, the effect of your changes. BTW, if you come across an Open Source autotool managed project which does not package the autotool sources with its distribution, you should complain to the project maintainer -- he is violating the GNU standards for coding and distribution, in addition to restricting your ability to contribute to his project. Best regards, Keith. |
From: Max T. W. <max...@ve...> - 2005-05-23 16:33:02
|
Keith MARSHALL wrote: > > Max T. Woodbury wrote: > > I will disagree about looking at the generated 'configure' scripts. > > Looking at any single one isn't going to help a lot but if you look at > > enough a pattern emerges, much like the pattern you'll get when you > > look at the machine code a compiler generates. Being able to look at > > this stuff is important because some packages do not seem to include > > proper precursor files, but I may be wrong about that. > > > > That insight about configure.[in|ac] and aclocal.m4 is something I > > hadn't gotten to yet. Thanks for the tip. > > Max, > > I wasn't trying to suggest that you should *never* look at the generated > configure scripts -- just not to waste too much time there, until you > have a reasonably good grasp of how they are generated. > > The problem with trying to interpret a generated configure script, > *before* understanding how it's constructed by autoconf, is that it's a > huge monolithic collection of Bourne shell code, *very* intimidating and > difficult to make sense of. Even the minimum possible > > AC_INIT > AC_OUTPUT > > generates some 1800 lines of shell script, and that's just the standard > initialisation and output code! Once you understand the function of > configure.{in,ac} and aclocal.m4, you can use them as a "roadmap", to > help you to make sense of the generated configure script itself. > > One thing which *really* is a "no-no": you must *never*, if you wish to > preserve your sanity, modify any autotool generated script by hand > editing! To modify "configure", you make appropriate changes in > configure.ac, or in aclocal.m4, and then run autoconf to regenerate the > configure script. When you get to this stage, *then* it can become > quite enlightening to examine the generated configure script, to help > you to understand, and debug, the effect of your changes. Umm, that means I'm not sane, but that happened a loooong time ago 8*D. However, I understand your advice even if I disagree a little. I had a vague idea of what 'autoconf' did before studying it and expected to find patterns. I was not disappointed. In finding them, it helps if there is a large sample to work with, not a small one. There are still a lot of details I have not worked through yet, but I'm much more comfortable with the process now. Still, I'm not ready to post patches that involve 'autoconf' input, but that should not take too much longer. I like to think I dig a little deeper into things than most people. That means it takes me a little longer to get things done, but it also means that when I'm done I have a very good understanding of what is going on. > BTW, if you come across an Open Source autotool managed project which > does not package the autotool sources with its distribution, you should > complain to the project maintainer -- he is violating the GNU standards > for coding and distribution, in addition to restricting your ability to > contribute to his project. Well, that's the ideal at any rate. From experience, more standards are honored in the breach than in the observance and keeping things up-to-date is not always easy. I've lost it in a recent clean-up, but there was at least one package I tried that had problems in this respect. One of the reasons for this exercise is to identify just this kind of problem. One of the reasons I was willing to just start over was because I knew that I'd get back to the problem eventually and in the proper context. On the other hand, I've screwed things up myself and doing it again more carefully has gotten me past obstacles that threw me the first time. I just hope what I'm doing is considered helpful rather than obstructive. Max |
From: Mark J. <mj...@gm...> - 2005-05-23 16:48:10
|
Hi, I just want to mention here that I was able (after many source-hacking) to compile and use the texinfo viewer. When it's interesting for some users, I'll create a new archive that'll contain all changes. Currently, there are still two remaining problems: 1. I have to check through all isatty() related code 2. The texinfo viewer is *very* slow. It seems that I must take a much closer look at it. All other tools compiled out-of-the-box *g*. Regards, Mark |
From: Max T. W. <max...@ve...> - 2005-05-20 13:51:13
|
Keith MARSHALL wrote: > > Max T. Woodbury wrote: > > You have to start somewhere. I'm in the process of finding out > > where. The MinGW kit (bison-1.875.0-2993.02.10-1) is a 1.875 (aka > > 1.875a?) kit. CygWin has a 1.875b kit. With a little more thrashing > > around, I will have something useful and we might be able to agree > > that where I land is where we all want to be, but I've got to land > > before we can do that... ;-) > > The canonical source *must* be the FSF's distribution, with the > latest stable release found at > > http://ftp.gnu.org/gnu/bison I was looking for a CVS source, but that one will do if I can't find one. I'm still trying to understand the build process and how it differs between CygWin, MinGW and MSys. Once I have a handle on that, I'll be able to make changes at other levels... > Undoubtedly, patches will be required to get to a working MSYS > implementation. The patches used in the MinGW 1.875.0-2993.02.10-1 > version may provide inspiration, but IMHO, unless you *really* want > to start, and maintain, your own private fork, you should adapt this > patch set against the bison CVS, found via > > http://savannah.gnu.org/cvs/?group=bison > > and should feed the results back into that CVS, so that portability > issues may be resolved at source. See > > http://www.gnu.org/software/bison/bison.html > > for further information. > > This is the approach I adopted, when I joined the groff project; as > a result, groff-1.19.2, from CVS, is now pretty much an OOTB build > with MinGW, with no need for any independently maintained fork. > > BTW, as Earnie keeps reminding us, Google is your friend. I found > all of the above links from the first hit on `site:gnu.org bison'. Actually I had to gnu.org link already and had been through their mailing list archive. I'm hung up at a different, more abstract, level - the build process itself. The script Ernie provided gives major clues as to what is needed but has not produced quite what I expected. I could very well have missed something, but it looks like only very minor changes are needed (if they are even needed) to get ALL of this running under MSys, which means there is some VERY heavy 'magic' somewhere in the build environment. I'll be afraid of breaking things until I find it! In particular I just did a careful comparison between the CygWin 1.875b and the MinGW 1.875 packages looking for differences in the build process. There were really only two -- the addition of a YACC related option and a change of variable from CXX to GXX. (There were code changes that showed up as well, particularly some _WIN32 (or something like that) conditional sections in the MinGW code, but nothing functional in the build process. In particular, I didn't see ANY reference to the CygWin.dll and I know its in there someplace because the executable will not run under MSys because it can't find it, even though I specified a 'mingw' target. And I saw notes on the bison list which could be taken as an indication that those _WIN32 blocks got retroed into a later version of 1.875...) It is really starting to look like I am actually going to have to learn about autoconf. I knew I'd need that sometime, but I was hoping it wouldn't be quite this soon... max |
From: Max T. W. <max...@ve...> - 2005-05-21 16:00:41
|
I'm going to put this back into the mailing list. As far as I can see, it contains nothing personal and others who are following this might find it useful. "Michael S. Zick" wrote: > > On Fri May 20 2005 08:49, Max T. Woodbury wrote: > > > > In particular I just did a careful comparison between the CygWin 1.875b > > and the MinGW 1.875 packages looking for differences in the build > > process. There were really only two -- the addition of a YACC related > > option and a change of variable from CXX to GXX. (There were code > > changes that showed up as well, particularly some _WIN32 (or something > > like that) conditional sections in the MinGW code, but nothing > > functional in the build process. In particular, I didn't see ANY > > reference to the CygWin.dll and I know its in there someplace because > > the executable will not run under MSys because it can't find it, even > > though I specified a 'mingw' target. And I saw notes on the bison > > list which could be taken as an indication that those _WIN32 blocks > > got retroed into a later version of 1.875...) > > > Max, > > I think I can provide some info here... > Although I haven't found it documented anywhere... > The _WIN32 is the non-unix variant selector... Yep, that seems to be the convention... > Each non-unix variant provides some variant specific headers/macros... > The uwin, mingw, msys variants seem to have adopted the cygwin naming > conventions... > > - - - - > > You should be able to find the reference to variant.dll in both the > gcc specs and the load scripts. I think I see where this is going. I'm not quite ready to go into that yet, but I am fairly sure I'll be getting to it, so thanks for the information... > > with appropriate substitution for 'gcc'... > gcc -dumpspecs > > Which will probably output more than you ever wanted to know. Ah, but you might be surprised at what I want to know. However I do have to be in the right context or I simply get overwhelmed. Since I'm not currently in that context, I'll skip this for now, but I expect to arrive at that context in a little while and when I do, this should prove very useful... Progress report -- I could not get 'bison' to build. It has a dependency on itself and the current binary is almost useless. 'flex' has a similar problem. The 'autoconf' dive broke the cycle. 'byacc' can be substituted for 'bison'. 'byacc' built from sources under 'msys' without alteration. (IIRC it did not build under 'mingw32'.) With 'byacc' up, I got 'flex' to build under 'mingw32'. That should get me to 'bison'. It might even get me directly to 'bash', but I'll have a go at 'bison' first since I'm still in that 'context'. The 'autoconf' dive has convinced me that CygWin is not going to be a lot of help for a while. It was a good point of reference, but it costs too much to maintain. As a result of all this searching my build environment was a mess. I've reamed it out and repacked the disk after saving the small amount of stuff that really needs to be kept. (Yes, this is dangerous -- I forgot to save a short but useful script and I'll have to recreate it, and I'll need to rearrange things so I don't make that particular mistake again. These things belong in the '/home' tree, which was not where I had put them...) I'm about to put everything back together. I'll revise my notes as I do it. Eventually I'll post the notes to the list for comment and then put them in the wiki, but their still a little too raw... ma...@mt... |
From: Michael S. Z. <ms...@mo...> - 2005-05-21 17:43:02
|
On Sat May 21 2005 11:00, Max T. Woodbury wrote: > > > > You should be able to find the reference to variant.dll in both the > > gcc specs and the load scripts. > > I think I see where this is going. > If your foresight sees: For any specific version of gcc which outputs x86 code in PE object format; The only difference should be the specs file. A plain text file which you can edit if you want to put your life and job at risk. In theory, you don't need a cygwin, msys, mingw, uwin builds of gcc, just a collection of specs files for each. But that would be in a perfect world. - - - - A note on byacc as a way to bootstrap bison... The folks who originated yacc have switched to byacc in their open source software. The bootstrap system for uwin does not include bison, only byacc. Mike |