[PATCH] Support Android NDK (which has neither futimes nor futimens)

[Alp Toker]

On 09/12/2013 09:37, Neil Henning wrote:
> Hey all,
>
> Thanks for the comments! I was reluctant to make it work on any 
> non-Android UNIX platform without either futimes or futimens simply 
> because I don't have the targets to hand to test that on!
>
> In terms of making the call a no-op - would it be acceptable to then 
> make it work on non-Android UNIX platforms like Pete Cooper suggested? 
> That way I wouldn't have to include any mention of ANDROID at all in 
> the patch, and the expected behaviour of the function 
> setLastModificationAndAccessTime would become 'Set the modification 
> and access time if we can, if not no problem!'
>
> Thoughts?

Neil,

The right thing to do here is (in pseudo-code):

|error_code setLastModificationAndAccessTime() {||
||#if defined(HAVE_FUTIMENS)||
||  return ...||;||
||#elif defined(HAVE_FUTIMES)||
||  return ...||;||
||#elif defined(__ANDROID__)||
||  return ENOTAVAIL;||
||#||else||
||#warning Missing futimes() and futimens()||
||  return ENOTIMPL;||
||#||endif||
||}|

The actual error codes don't matter too much as long as they don't 
return success*.

This has all the properties we want and makes the existing code a little 
more defensive and portable.

The rationale is that if the libc is missing such a basic function, the 
platform vendor is giving us a strong hint that it's not useful to set 
filesystem stamps on that platform anyway. The new version of Android 
will "just work" when HAVE_FUTIME[N]S gets detected at configure time 
and presumably it'll be an explicitly supported feature that we can 
legitimately use.

Here to review your updated patch when ready.

Alp.

>
> -Neil.
>
> On 08/12/2013 02:21, Rafael Espíndola wrote:
>>> This needs a cost vs. benefit analysis before going any further...
>>>
>>> Cost:
>>>    Maintaining direct Linux syscalls is a burden to the project.
>>>
>>> Benefits:
>>>    Adding the syscall may provide command-line users on older Android
>>> versions some limited support for the llvm-ar tool's obscure -o 
>>> option to
>>> preserve timestamps.
>>>
>>> On balance, I'd go for making this a no-op :-)
>> Even better :-) (assuming people are not somehow depending on -o).
>>
>> Cheers,
>> Rafael
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-- 
http://www.nuanti.com
the browser experts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131210/e162f193/attachment.html>