[ragel-users] Path handling of the native Windows build

[Adrian Thurston]

Thank you for getting to the bottom of this!

-Adrian

On 03/26/2011 09:30 AM, ragel-user at jgoettgens.de wrote:
> 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 :)
> 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.
> The patched sources and binaries can be downloaded from:
> http://www.jgoettgens.de/Meine_Bilder_und_Dateien/ragel-vs2008-patched.7z
> Please test the patched version as I have done only basic testing, and
> drop a line in case of any dodgy behavior.
> 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.
> 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...
> 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.
> To explore my source code changes use WinMerge or Meld on the entire
> source trees.
> jg
>
>
>
> _______________________________________________
> ragel-users mailing list
> ragel-users at complang.org
> http://www.complang.org/mailman/listinfo/ragel-users

-- 
Adrian D. Thurston
http://www.complang.org/thurston/

_______________________________________________
ragel-users mailing list
ragel-users at complang.org
http://www.complang.org/mailman/listinfo/ragel-users