On Tue, Jan 13, 2009 at 1:17 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Tue, Jan 13, 2009 at 6:16 AM, Beman Dawes <bdawes@acm.org> wrote:
I've decided not to attempt support for Cygwin in the next version of Boost.Filesystem.
I pulled the plug on Cygwin support at my company a couple of years ago for the lack of wchar_t support. They ought to support it.
Since in this case Cygwin is just a packager of other people's work, it isn't on their radar screen. I doubt it would take much work to add gcc wide character support; the compiler already supports wchar_t as does the C++ standard library. IIUC, the only piece of the puzzle that is missing is the C language library support. I suspect any of us could code that up in short order, but I don't want to take the time to figure out how to integrate it into their build system and sheppard the changes through their process.
Cygwin's lack of library support for wchar_t is the problem . For the current Boost.Filesystem version (v2), the necessary workarounds are so pervasive that the implementation code is much harder to read and maintain.
Is it true that had the interface of boost::filesystem been defined in terms of utf8, then the only platform on which wchar_t support would have been instrumental is Windows, and we wouldn't have had problems with Cygwin?
The problem isn't so much the interface as the internals. Windows' native character type for file names is wchar_t.
IIUC, the reason Cygwin doesn't provide C++ standard library support for wchar_t is that the underlying C library is missing the C wchar_t functions. Perhaps Boosters who care about Cygwin could spearhead an effort to add the missing C support?
You're right that it's missing the needed C library functions, but I was able to hack into the C++ headers to trick them to support std::wstring anyway. That's not the same as full wchar_t support, but it was the only thing I personally cared about.
My hack broke with one of the Cygwin releases that followed and I gave up on tracking down why, but I suppose if someone cares enough about this it can be done (my approach was to inject a modified version of one of the gcc-specific header files into the compiler include path, I'm not sure if this would be good enough for Boost.)
I suspect it is far easier to just fix the problem at the Cygwin source code level that trying to hack and maintain patches for Cygwin object code distributions. --Beman