<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: 12pt">
<DIV>Recently Austin Hastings reported about a bug of the native Windows build
when further machines are included when the include directories are given on the
command line. There is more than the bug Austin discovered as path handling for
non Posix platforms is at least somewhat incomplete and inconsistent. You
can blame the maintainer of the Windows port for this :)</DIV>
<DIV> </DIV>
<DIV>I have patched the source code such that you can now include additional
machines by specifying sub directories from the include statement and by
specifying them on the command line with the -I option. All include directories
may be specified as relative or absolute paths and the path separator may be
either '/' odr '\'---you can even mix them.</DIV>
<DIV> </DIV>
<DIV>The patched sources and binaries can be downloaded from:</DIV>
<DIV> </DIV>
<DIV><A
href="http://www.jgoettgens.de/Meine_Bilder_und_Dateien/ragel-vs2008-patched.7z">http://www.jgoettgens.de/Meine_Bilder_und_Dateien/ragel-vs2008-patched.7z</A></DIV>
<DIV> </DIV>
<DIV>Please test the patched version as I have done only basic testing, and drop
a line in case of any dodgy behavior.</DIV>
<DIV> </DIV>
<DIV>Although there is a Windows specific (aka _WIN32 is defined) definition for
a path separator, include statements like #include inner
"xdir\testinc.rl"; work, because the current Windows runtime libraries
accept also the separtor '/'. Using '\' is not enforced by Ragel.
Interestingly, statements like #include inner "xdir\testinc.rl";
fail, because the include file is handled by the scanner inside Ragel which
calls prepareLitString() for new tokens. If the path contains a valid '\',
the next char is either dropped or translated, because the '\' is interpreted as
an escape character. So when it is time to open the include file, its name
has been changed to "xdir<tab char>estinc.rl". Obviously, this file exists
only by coincidence.</DIV>
<DIV> </DIV>
<DIV>Since I did not want to touch the data structures of Ragel, I simply hacked
argv as various paths are just pointers into argv. The only source code
change was to remove the constness of argv in addition to a routine that
normalizes paths. If Adrian decides to copy the names, my patches are
obsolete, but then his path data will be no longer read-only and a similar patch
could be applied to these variables. Of course a better solution would be to
make Ragel platform path agnostic...</DIV>
<DIV> </DIV>
<DIV>As far as the failing -I <include dir> is concerned, it's just that
the Microsoft compiler doesn't let you read or write to a file when its state is
not "good". The good old days are over when gcc was the stricter
compiler. When iterating through all possible file names, the state of the
ifstream is "fail". The patch (the correct way?) is to call
inFile->clear() if opening fails. If you specify a sub directory
inside your FSM description, the current algorithm at first tries to open this
file relative to the path of the main file (unless it is an absolute path, which
also works). The first file never suffers from the state problem, so this
method worked without patching, although the same routines are involved.</DIV>
<DIV> </DIV>
<DIV>To explore my source code changes use WinMerge or Meld on the entire source
trees.</DIV>
<DIV> </DIV>
<DIV>jg</DIV>
<DIV> </DIV></DIV></DIV></BODY></HTML>