The utilities as such are standalone (l10n tools). it works if I set the commandline options correct for the linker, so it is not a generic platform issue. It is just a "pain in the neck" problem, when you try to make the program easy supportable.
The source cannot be ported to java because it is not really worth porting, I am learning the old code (which is really old) and writing it new (after discussions with among other juergen) and that could of course be done in Java if preferred. There are two problems with using java. - Flex has no support for java, and we need lots of lexical analysis, which would require lot of hours to program without something like flex. - I do not program voluntarily in Java, which is no limitation for the project, it just means I cannot do it. Anyhow suggestions are always welcome, new eyes looking at a problem can often give new solutions !! Jan. On 12 November 2012 20:11, Rob Weir <robw...@apache.org> wrote: > On Mon, Nov 12, 2012 at 12:14 PM, jan iversen <jancasacon...@gmail.com> > wrote: > > Hi Andre. > > > > What I find "funny" is that in Ubuntu, I dont even get a warning about > > multiple declared symbols in windows I get the warnings but it works > (with > > /force:multiple), so I will just overwrite the linker options in the > > makefile, that should do it. > > > > Are these utilities standalone? or do they have wider dependencies on > other C++ from the project? > > If it is doing relatively simple file parsing and conversions, I > wonder if it would be a huge effort to port to Java and JavaCC? Then > we would not need to worry about the platform differences. > > -Rob > > > > Thanks for your help. > > Jan. > > > > Ps. The flex people just returned to me, and gave me another > possibility, I > > can use the -S option (manual says this is an option you will never use) > > and pass a skeleton file, that will overwrite the standard skeleton and > in > > that I can change yytext. > > > > > > On 12 November 2012 15:49, Andre Fischer <awf....@gmail.com> wrote: > > > >> On 12.11.2012 14:02, jan iversen wrote: > >> > >>> hi > >>> > >>> see below please > >>> > >>> On 12 November 2012 09:30, Andre Fischer <awf....@gmail.com> wrote: > >>> > >>> On 11.11.2012 22:06, jan iversen wrote: > >>>> > >>>> Hi. > >>>>> > >>>>> I would like to hear your opinion on the following problem: > >>>>> > >>>>> The l10n tools uses flex, which is quite nice, however I have found > two > >>>>> problems with flex: > >>>>> > >>>>> - the .l sources defines YYLMAX, but the generated .c source declares > >>>>> yytext[YYLMAX] BEFORE the definition code it sucked in. I have > verified > >>>>> this with the flex sources, nothing to do about it. the flex > generated c > >>>>> sources start with flex things (including yytext[YYLMAX]) and then > the > >>>>> first part of the .l file is included. The manual states to use > YYLMAX > >>>>> to > >>>>> change the yytext buffer size, but with the current flex sources it > does > >>>>> not work. > >>>>> > >>>>> That is a good way, especially since I can make my own targets > (yy.c -> > >>>> > >>> .o) in the makefile. I will do that. > >>> > >>> But it does not solve the name issue (yytext), I will make a bug > report on > >>> flex, and mail one I know that was involved in flex. > >>> > >> > >> Sorry, I did skipped the second problem when I read your mail the first > >> time. > >> > >> I just made an experiment with l10ntools/source/srclex.l. When I add > the > >> line > >> > >> %option prefix="bla" > >> > >> before the first %% then yytext is replaced but yytext_ptr is not. > Besides > >> yytext is not really replaced but flex adds a > >> > >> #define yytext blatext > >> > >> so that yytext, while not used in the rest of src_yy.c, it will be a > >> symbol in the object file. > >> That will likely cause problems when linking two lexers into the same > >> library/executable, which usually the reason for the renaming in the > first > >> place. > >> Telling flex to produce C++ output might help (replace option -l with > >> --c++) but that would require additional work (at least you have to > change > >> the compilation rules in makefile.mk to compile C++ instead of plain > C). > >> > >> I am sorry to be of no help. > >> -Andre > >> > >> > >>> Jan > >>> > >>> > >>> - the .l sources defines a '%option prefix="genXrm_"`which according > to > >>>>> the > >>>>> manual should replace all yy in the generated code, however it does > not > >>>>> work for yytext and yytext_ptr, because the are instanciated before > the > >>>>> code is included. > >>>>> > >>>>> The leads to two problems: > >>>>> - YYLMAX not being used, it a performance degradation on all > platforms > >>>>> (but > >>>>> no real problem). > >>>>> - yytext not being changed, is in Ubuntu (linux) not a problem, but > in > >>>>> windows I had to use a new swich (/forcemultiple), and I have no clue > >>>>> about > >>>>> mac. > >>>>> > >>>>> I see different solutions: > >>>>> 1) I edit the generated .c file, and make a thick note, that if the > .l > >>>>> file > >>>>> is translated, that has to be changed. > >>>>> 2) I create a sed that takes the output of flex and does the trix, > this > >>>>> requires changing the details of the make files. > >>>>> 3) I report the bug to the flex people with a patch, and we wait > until a > >>>>> new version is ready. > >>>>> > >>>>> I am for version 1), but I would like to hear opinions ? > >>>>> > >>>>> I found an answer via Google on another Apache mailing list (Apache > >>>> Thrift): > >>>> http://markmail.org/message/****hgphhaciu6nxwtk7#query:+page:****< > http://markmail.org/message/**hgphhaciu6nxwtk7#query:+page:**> > >>>> 1+mid:hgphhaciu6nxwtk7+state:****results<http://markmail.org/** > >>>> message/hgphhaciu6nxwtk7#**query:+page:1+mid:** > >>>> hgphhaciu6nxwtk7+state:results< > http://markmail.org/message/hgphhaciu6nxwtk7#query:+page:1+mid:hgphhaciu6nxwtk7+state:results > > > >>>> **> > >>>> > >>>> > >>>> In short: > >>>> Add "CPPFLAGS='-DYYLMAX=whatever'" to the compiler invocation > (not > >>>> the > >>>> call to flex that converts %lex.l to %_yy.c) > >>>> However, if I look at l10ntools/source/makefile.mk, then I don't > >>>> see > >>>> an explicit compile rule for the %_yy.c files. You may have to add > one. > >>>> > >>>> > >>>> Oh, and I think option 3) would be good to do also, without the > waiting > >>>> part. > >>>> > >>>> -Andre > >>>> > >>>> > >>>> > >> >
