This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] compile: rm -rf -> ftw()+rmdir()+unlink() [Re: [patch] compile: Fix MinGW build]


On 12/18/2014 08:14 PM, Kai Tietz wrote:
> ----- UrsprÃngliche Mail -----
>>> Date: Thu, 18 Dec 2014 18:31:03 +0100
>>> From: Jan Kratochvil <jan.kratochvil@redhat.com>
>>> Cc: ktietz@redhat.com, sellcey@imgtec.com, brobecker@adacore.com,
>>>         yao@codesourcery.com, gdb-patches@sourceware.org
>>>
>>> >From the Fedora point of view MinGW64 32-bit mode seems to be a superset
>>>> of
>>> MinGW32 so why to care about MinGW32 anymore?  Or what do I miss?
>>
>> That _I_ use MinGW32?
> 
> That is actually your problem, isn't it?  The mingw-w64 target support ftw, so why
> not simply allow it for targets providing it, and other targets can be covered by gnulib?
> Anyway gnulib is nothing I am concerned in general.

Let me try to make this clear.

gnulib does not provide an ftw replacement.  And AFAIK, that's on
purpose.  Note that ftw has been marked obsolete in POSIX.1-2008.
Per POSIX, applications "should" be using nftw/nftw64 instead.

For our purposes, both APIs are just as good (*).  It's just
that ftw has System V roots, while fts has BSD roots.

In practice, programs that use fts instead are just, if not
more portable.

But, as I mentioned, gnulib provides an fts replacement
for systems that don't have it.  So if we use fts instead, we're
good to go everywhere.

(*) - see ftw vs fts limitations here:
   http://lists.gnu.org/archive/html/bug-gnu-utils/2003-02/msg00224.html

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]