Re: progress.c does not compile under Mac OS X

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Oh,

I'm a bit confused here - lots of things happening. Submitting patches to
projects is usually fairly simple; it's excitingly fresh to get a bunch of
replies, having the patch set revised, more replies, then a further revised
patch set gets merged to a development branch, and then I get suddenly get
emails about breaking the build on OS X. Let's see if I can figure this out. :-)

My original patch had a minor bug where it forgot to compatibility-wrap the
CLOCK_MONOTONIC constant. Surprisingly, it turns out even in 2014 OS X doesn't
have the clock_gettime interface. What a silly operating system.

Jacob Keller revised my patch set and added compatibility macros that emulate
timer_foo using setitimer. Turns out, it had a few typos of its own.

The revised patch set got slightly changed and was merged to the pu branch,
which is where you are having build trouble now.

Alright, so to recover, first appropriately add this to git-compat-util.h:

+#ifndef CLOCK_MOTOTONIC
+#define CLOCK_MONOTONIC 1 /* dummy */
+#define

Secondly, there is a typo where an underscore is used instead of a period.

-       _ivalue_it_value.tv_usec = value.it_value.tv_nsec / 1000L;              \
+       _ivalue.it_value.tv_usec = value.it_value.tv_nsec / 1000L;              \

Third, there needs to be an end brace before the while:

-while (0)
+} while (0)

That should fix the immediate breakage, I believe.

Looking closer, there are a bunch of additional issues here:

+#define timer_create(clockid, sevp, timerp) ((void) (clockid), (void) (sevp), (void) (timerp), errno = ENOSYS, -1)
+#define timer_create(clockid, sevp, timerp) ((void) (clockid), (void) (sevp), (void) (timerp), 0)

This emulates a timer_create that always fails. That's not what we are trying to
do, we want to emulate one that always works. It should return 0 instead of
setting errno to ENOSYS and returning -1. (My original patch set made the
replacement timer_create this this way, but at that time I was not trying to
emulate the interface, just stub it.)

Finally patch set also fails to break with platforms with a broken timer_settime
but a working setitimer. If that is something we want to support? Might as well.

On 08/30/2014 10:37 PM, Torsten Bögershausen wrote:
> And then we have the question why we do not check the return value of
> timer_create() in progress.c#66:

It's because the old code didn't check the result value. Secondly it's because
this code is non-essential, if it fails, there is really no choice but to carry
on anyways. I admit it's probably not a good idea to make timer_settime time
with an uninitialized timer id. The likelihood is low though as git only needs
one timer - but I agree it's prudent to check the error codes.

On 08/30/2014 10:37 PM, Torsten Bögershausen wrote:
> It feels as if the macros in git-compat-util.h could be converted into real
> functions, in compat/timer_settime.c (or so) so that we can test-compile under
> Linux)

This is my preferred route as well.

I hope that sorts things out. I'll be submitting a full V2 of my patch set
shortly that should work reliably on all systems. For now, you can fix the build
by applying the above fixes, or perhaps revert the commits as they are
troublesome. :-)

Jonas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]