getDirectoryContents and renameFile needs to be implemented in Win32/Path.cpp

Hi Jeff,

We need to get getDirectoryContents and renameFile implemented from Unix/Path.cpp in Win32/Path.cpp, otherwise I can't get llvm-ar linked.

Henrik.

I suspect those aren't the only two. I'll have to make a pass over Path.cpp to see what was added to the unix version and not to the win32 version.

Henrik Bach wrote:

Indeed they weren't. It's up to date now.

And now that I've done that I can't help but notice that Path.cpp is getting very Unix-centric in its interfaces, what with file permission bits and stuff. This is going to cause problems if and when LLVM is ported to other operating systems, though I have to admit it's getting difficult to name viable operating systems it could get ported to that isn't some flavor of Unix. But there are a few left...

Jeff Cohen wrote:

Yeah, this is a known problem. I've been purposely holding off until all
the Path functionality was done. That's complete now so I'm starting to
think about making the interface less sucky. We're probably going to
model it after java.io.File which has a pretty clean interface. As for
the permission bits, this is just needed for llvm-ar whose file format
dictates that it have mode bits. There might be some opportunity for
cleaning that up as well. If you have any specific suggestions for
improving the Path interface, I'm all ears.

Also, thanks for completing the Win32 Path implementation.

Reid.

Reid Spencer wrote:

And now that I've done that I can't help but notice that Path.cpp is getting very Unix-centric in its interfaces, what with file permission bits and stuff. This is going to cause problems if and when LLVM is ported to other operating systems, though I have to admit it's getting difficult to name viable operating systems it could get ported to that isn't some flavor of Unix. But there are a few left...
   
Yeah, this is a known problem. I've been purposely holding off until all
the Path functionality was done. That's complete now so I'm starting to
think about making the interface less sucky. We're probably going to
model it after java.io.File which has a pretty clean interface. As for
the permission bits, this is just needed for llvm-ar whose file format
dictates that it have mode bits. There might be some opportunity for
cleaning that up as well. If you have any specific suggestions for
improving the Path interface, I'm all ears.

Also, thanks for completing the Win32 Path implementation.

Reid.

Sigh... maybe it would be best to declare there shall not be a port to a non-Unix OS, except for Windows. There really are few alternatives left. The only ones I can think of that still have life are IBM's, and we don't want to go there. An MVS port for IBM's mainframes? I can't even begin to list the assumptions in Path.cpp that are false on that platform, and, unfortunately, it's not from ignorance. If it can't emulate the POSIX api, forget it--and I bet there's POSIX emulation for MVS nowadays anyway.