Shiqing and I took this offlist and have a solution which looks like it works.
End results:
- no more flex.exe in tarballs
- updated the flex to 2.5.35 on the IU machine that is used to generate 1.4 and
1.5 tarballs; hence, the generated _lex.c files in the tarball are
Windows-friendly
- chang
Are you saying (per your other mail) that the .c files are simply generated by a flex
that is too old, and we need to update the flex that is used to generate the .c files in
the tarball? If so, that's a relatively simple change to make in the "make a
tarball" scripts at IU.
Yes, exactl
Actually, I take that back -- the .c files *are* in the tarball already.
Are you saying (per your other mail) that the .c files are simply generated by
a flex that is too old, and we need to update the flex that is used to generate
the .c files in the tarball? If so, that's a relatively simple
Ok, moving this back to devel (sorry, I replied to an earlier mail -- before
Ralph moved it to devel).
Let's figure out how to generate the relevant code that you need at "make dist"
time and not include flex.exe in the tarball -- it can still be in svn if you
want/need it. You might want to n
Hi,
In the User's list, Jeff mentioned generating the windows flex code
during make dist time, I didn't think about it before, it should work if
flex is newer than 2.5.4 (the latest version is 2.5.35).
In the created tarball, the flex generated c source won't compile under
Windows, that's be
Let's shift this to the devel mailing list and add it to the Tues telecon.
Thanks for clarifying. Sounds to me like the suggestions made below are right -
we shouldn't be distributing binary in the main tarball for export reasons.
Seems like we have four options:
1. A separate Windows-tool tarb
