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

[Adrian Thurston]

I've applied your fix for the failing -I option. I'm not yet sure what 
to do about the other path issues ... there seems to be no pressing 
issue, just overall design problems. I've got urgent coding to do 
elsewhere (DSNP) so I'm going to leave that for now.

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