[filesystem] BOOST_FILESYSTEM_STATUS_CACHE configuration on SunOS
***See: http://tinyurl.com/7pp9r *These test results appear to pre-date line 69 below: 62 // BOOST_FILESYSTEM_STATUS_CACHE enables status_flags cache in 63 // dir_itr_increment. The config tests are placed here because some of the 64 // macros being tested come from dirent.h. 65 // 66 // TODO: "|| defined(__APPLE__)" compiles, but at runtime d_type is alwasy 0. Why? 67 // TODO: find out what macros enable dirent::d_type on various operating systems. 68 # if !defined(__CYGWIN__) && !defined(__osf__) \ 69 && !(defined(__sun) && defined(__GLIBCXX__)) \ 70 && (defined(BOOST_WINDOWS_API) \ 71 || defined(__USE_BSD) || defined(_DIRENT_HAVE_D_TYPE) \ 72 ) 73 # define BOOST_FILESYSTEM_STATUS_CACHE 74 # endif So I expect Filesystem will compile properly on my Monday test run. However I think the macro test should just be for defined(__sun), and not both __sun && __GLIBCXX__. The lack of d_type in dirent is a C library issue, not a C++ library issue and as would affect any compiler on Solaris (e.g. SunPRO CC would hit this too). -- Caleb Epstein caleb dot epstein at gmail dot com
"Caleb Epstein" <caleb.epstein@gmail.com> wrote in message news:989aceac0512182000m4bffe9caq67b1a9d8697b0da0@mail.gmail.com...
***See: http://tinyurl.com/7pp9r
*These test results appear to pre-date line 69 below:
62 // BOOST_FILESYSTEM_STATUS_CACHE enables status_flags cache in 63 // dir_itr_increment. The config tests are placed here because some of the 64 // macros being tested come from dirent.h. 65 // 66 // TODO: "|| defined(__APPLE__)" compiles, but at runtime d_type is alwasy 0. Why? 67 // TODO: find out what macros enable dirent::d_type on various operating systems. 68 # if !defined(__CYGWIN__) && !defined(__osf__) \ 69 && !(defined(__sun) && defined(__GLIBCXX__)) \ 70 && (defined(BOOST_WINDOWS_API) \ 71 || defined(__USE_BSD) || defined(_DIRENT_HAVE_D_TYPE) \ 72 ) 73 # define BOOST_FILESYSTEM_STATUS_CACHE 74 # endif
So I expect Filesystem will compile properly on my Monday test run.
However I think the macro test should just be for defined(__sun), and not both __sun && __GLIBCXX__.
The lack of d_type in dirent is a C library issue, not a C++ library issue and as would affect any compiler on Solaris (e.g. SunPRO CC would hit this too).
My thinking was that there might be different C libraries available on Sun, and I was trying to use __GLIBCXX__ to differentiate. But you are probably right, so I'll make the change. In any can we are talking about an optimization, so turning it off does no functional harm (although it may impact performance). Thanks, --Beman
On 12/19/05, Beman Dawes <bdawes@acm.org> wrote:
My thinking was that there might be different C libraries available on Sun, and I was trying to use __GLIBCXX__ to differentiate. But you are probably right, so I'll make the change. In any can we are talking about an optimization, so turning it off does no functional harm (although it may impact performance).
The __GLIBCXX__ macro is only used for the C++ library, not the C library. If you want to check for the presence of the GNU C library, the macro to use is __GLIBC__. So perhaps the test should be: if !(defined(__sun) && !defined(__GLIBC__)) Looking at the manual pages and header files, it doesn't seem that there is any way to "enable" dirent.d_type with Sun's own C library. Good to finally see this code on the TRUNK! -- Caleb Epstein caleb dot epstein at gmail dot com
participants (2)
-
Beman Dawes -
Caleb Epstein