Tor Lillqvist <> wrote: >> it was built with cl.exe as native win32 executable, and not with >> mingw gcc (which i think would result in a mess, since the compiler >> couldn't convert the mingw unix style paths to something that cl.exe >> understands....))? > > You misunderstand. MinGW produces native Win32 executables, exactly > like cl does. That's the point of it, to be a more or less direct > functional equivalent of cl.exe, link.exe et al. > > The MinGW programs (gcc, ld, nm etc) are also native Win32 exectuables > themselves. They don't understand Unix style paths. "mingw unix style > paths" don't exist. > > But when used from a MSYS shell or make, that doesn't matter, as MSYS > takes care of converting for instance command-line parameters like > -I /where/ever/include > that uses a MSYS Unix style path into > -I x:/stuff/subdir/where/ever/include > when running gcc. (If /where is "mounted" in the MSYS sense on > x:\stuff\subdir\where) > > Now, MinGW is *usually* used from a MSYS shell or make, so it is > perhaps easy to con-fuse them. But they are separate things.
I see... So parity would get to see only windows paths? That would be ok then. _Maybe_ things work out ot the box :) If not i'll be happy to look into it, but i need a MSYS environment first... Arg... :) Cheers, Markus > > --tml _______________________________________________ orbit-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/orbit-list
