On Sat, Oct 04, 2008 at 03:37:15AM +1300, Ralph Versteegen wrote: > 2008/10/3 Mike Caron <[EMAIL PROTECTED]>: > > James Paige wrote: > >> > >> On Thu, Oct 02, 2008 at 11:38:31PM -0400, Mike Caron wrote: > >>> > >>> [EMAIL PROTECTED] wrote: > >>>> > >>>> pkmnfrk > >>>> 2008-10-02 19:28:33 -0700 (Thu, 02 Oct 2008) > >>>> 130 > >>>> More (primarily) type-suffix elimination > >>>> > >>>> I'm through most of the headers, but now I get the fun task of going > >>>> through modules... > >>> > >>> Whelp, turns out it's impossible. Too many gosubs reference externally > >>> defined variables which don't exist in -lang fb, so they have to be made > >>> global, but that causes a branch-crossing warning, which means they need > >>> to > >>> be subiffied, but I don't know enough about that tangled mess to try and > >>> do > >>> it, so I give up for now. > >> > >> Yeah, those gosubs are bad. I don't mind untangling them (I actually kinda > >> enjoy it) but it takes a long time. > >> > >>> Also, run-on sentence. > >>> > >>> Now, it seems that newer versions of FB have a "#lang" directive, so you > >>> can compile individual modules with different settings. But, > >>> unfortunately, > >>> the rest of the codebase is wholly incompatible with fb .20 > >>> > >>> Sigh. > >> > >> Really? I thought I got it to compile with 0.20.0 with just a few > >> warnings. Maybe my memory fails me... > > > > Alas, it's ultimately irrelevant... > > > > slices.bas(12) warning 30(0): Command line option overrides directive > > (haha) > > Strange, Yuriy told me that he fixed (committed) all the warnings that > he got when he compiled. Are you both on linux? FB throws way more > warnings then.
I think that is just because the linux compile scripts use the -v command line option. I just tested with 0.20.0 If I compile with revision 2321, I get no warnings other than the exact same branch crossing warnings that I ususally see in browse.bas But if I compile with anything after 2322, I get a plethora of "Return method mismatch" warnings. The resulting binaries seem to work fine. I think "Return method mismatch" is referring to cases where we have DECLARE FUNCTION foo() AS STRING but in code it is still called as foo$() Which I guess is nice, because it would be dang painful to find all of those without the warning messages. *checks* And it also seems to apply to anywhere that does DECLARE FUNCTION bar() instead of DECLARE FUNCTION bar() AS INTEGER --- James _______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
