Status of Mac OS/X ports of git and cogito?

Do git and cogito build easily on Mac OS/X now? Are there binaries available anywhere?

John

John Ellson <ellson@research.att.com> writes:

Not that I know of. We used to get portability patches from Darwin folks, but I haven't seen any lately.

I am somewhat interested in what portability glitches we still have, but not having an access to a machine, it is more of a curiosity rather than a necessity for me.

Are Darwin folks on the list happy with the current codebase, or have you given up because it is too GNU/Linux specific?

Hi,

On Fri, 26 Aug 2005, Junio C Hamano wrote:

While I'm not exactly Darwin folk, I use git on Mac OS X 10.2.8 (I'm sitting behind a scary firewall, so don't even think about hacking me).

I have three fixes in my personal tree without which git refuses to compile:

- daemon.c needs a define or typedef for socklen_t.

- mailinfo.c needs to have a simple strcasestr implementation, because 
  10.2.8 (at least in my setup) is lacking it!

- gitk gets very confused about the window layout. My preliminary tests on 
  cygwin showed that this seems to be rather a problem of Tk with rootless 
  Xwin. I worked around it by explicitely stating the dimensions of some 
  canvas windows which would not automatically resize with their contents 
  otherwise.

The only thing I did not "fix" is git-cvsimport not running because of a lacking File/Temp.pm. But then, I run git-cvsimport on a different machine anyway.

I regularly use git on OS X and it works great!

Ciao, Dscho

On 9/11/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

 
Can you share that fix? 

cheers,

martin

Hi,

On Sun, 11 Sep 2005, Martin Langhoff wrote:

I'm reluctant to do it, because it is not really a fix: the layout is better, but not perfect (BTW this is the reason I don't sign it off this time). For example, the width of the commit message window is not really the same when restarting. Worse, the upper part is shrinking with every restart of gitk. But anyhow, this is as far as I got to make it at least a bit usable:

Patrick and Jason CC:'ed because they also have portability issues and seem to have good ideas about how they should be solved. Linus CC:'ed because he once expressed rather strongly his dislike about autoconf.

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I still keep that patch around (the patch was end of July), but have not touched it only because I did not hear from you asking about its inclusion.

Yes, I've used it knowing that it is marked as a GNU extension, hoping if somebody else can supply a patch to work it around ;-).

I am slightly reluctant to do autoconf [*1*], but I might be tempted to take patches if it is done cleanly.

As a workaround until I am convinced otherwise and we go fully autoconf, I am inclined to introduce a new subdirectory in the source tree, compat/, which would house compat/linux.h, compat/darwin.h, compat/solaris.h and friends, and have compat.h symlink which points at one of those files.

[Footnote] *1* ...although I admit that I once used to be an autoconf freak and even had a few lines of my own code in the official autoconf distribution. It was an ancient history, most likely before libtool and automake came along. The last time I checked my changes were all superseded.

On Sun, 11 Sep 2005, Junio C Hamano wrote:

I personally think autoconf is the devils tool, and have had much more luck with

 - creating "compat" libraries that implement functions that some 
   configurations don't have.

   Sometimes this involves renaming the function, in order to avoid 
   clashes with broken implementations of same.

 - just ignoring the really broken systems (old HP-UX etc is terminally 
   diseased, and simply not worth worrying about)

autoconf generates an unreadable mess that can't be fixed. Doing it by hand at least means you can fix it.

But hey, I don't care that much any more, since I'm not the sucker who maintains it ;)

		Linus

Linus Torvalds wrote:

[regarding autoconf]

OK, this is just _evil_ coming from you since we all know that you _do_ care, even if you don't maintain it. :-)

Linus Torvalds <torvalds@osdl.org> writes:

Thanks for the vote of confidence ;-).

Hi,

On Sun, 11 Sep 2005, Linus Torvalds wrote:

That was the original idea of autoconf...

... which is sometimes no option.

A real pity! autoconf showed great promise in the first days. But then they started using m4 and other crud crept in.

All that said, autoconf still makes it easy to make a program or library portable. However, for git it would be overkill.

Ciao, Dscho

On Sun, 11 Sep 2005, Junio C Hamano wrote:

Side note: one simple solution for "socklen_t" is to just replace it with "int".

Any operating system where socklen_t is anything else than "int" is terminally broken. The people who introduced that typedef were confused, and I actually had to argue with them that it was fundamentally wrong: there is no other valid type than "int" that makes sense for it.

In case anybody cares: not only is "int" obviously "big enough" even on some theoretical 16-bit architecture, so there's never any real _reason_ to use anything else.

But more importantly, the core BSD networking functions have historically had declarations like

	int accept(int s, struct sockaddr *addr, int *addrlen);

which means that if 'socklen_t' is ever anything else than "int", you'd break all old applications. For no good reason.

Ergo, any operating system that has socklen_t != int is so broken that it's simply not worth playing with.

(POSIX for a short while had _defined_ it to be the same as "size_t", I really had to scream at some people over it, and told people that Linux would never do anything that stupid. Apparently Linux was the first 64-bit operating system that people actually ever tried to use).

		Linus

This should work around the compilation problem Johannes Schindelin and others had on Mac OS/X.

Quoting Linus:

    Any operating system where socklen_t is anything else than
    "int" is terminally broken. The people who introduced that
    typedef were confused, and I actually had to argue with them
    that it was fundamentally wrong: there is no other valid
    type than "int" that makes sense for it.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

    Linus Torvalds <torvalds@osdl.org> writes:

    > On Sun, 11 Sep 2005, Junio C Hamano wrote:
    >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
    >> 
    >> > I have three fixes in my personal tree without which git refuses to 
    >> > compile:
    >> >
    >> > - daemon.c needs a define or typedef for socklen_t.
    >> 
    >> I still keep that patch around (the patch was end of July), but
    >> have not touched it only because I did not hear from you asking
    >> about its inclusion.
    >
    > Side note: one simple solution for "socklen_t" is to just replace it with 
    > "int".

 daemon.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

def13dbdb962069f4cb22e3d72483ae443bda6cf

Hi,

On Sun, 11 Sep 2005, Linus Torvalds wrote:

Linus, we all know that you are always right. Only that in this case you are just a little bit less right than usual. The introduction of this typedef was a sane thing to do, for the same reason it is a sane thing to use sensible variable names: documentation. It is _important_ that a program be easy to read for others. As a further candy, you can grep and even sed for socklen_t. Try that with every socklen_t substituted by int.

Ciao, Dscho

On Mon, 12 Sep 2005, Johannes Schindelin wrote:

Nope.

Go through the history of that thing.

It wasn't introduced as "socklen_t". It was introduced as "size_t".

That was so horribly wrong that it's not even funny. 

Documentation my ass. It's a matter of people thinking that the old portable types aren't good enough, and that you have to make up new names for everything in order to allow "portability" where different systems have different ideas.

And it's ignoring the fact that true portability means "it just works". "size_t" fundamentally didn't work.

And the really sad part is that before the standards bodies started messing around with it, things really _did_ "just work". There was no question at all about what kind of type to use.

These days, we sadly have some systems that just blindly followed the standard, changed "int" to "size_t", and then when the standard was fixed, changed "socklen_t" to be "size_t".

Don't believe me? Just google for "size_t" and "socklen_t", and weep.

All this confusion, and for what? Absolutely _zero_ upsides.

Basically, if a programmer feels like he needs to remind himself what the variable was all about, how about using descriptive variable names? I claim that

	int addr_len;

is a lot more documentation than

	socklen_t len;

and that the people who think that different type-name are "documentation" are ignoring the fact that they are _also_ "confusing".

There's a virtue in simplicity. Abstraction is _not_ a virtue.

			Linus

On Sun, 11 Sep 2005, Linus Torvalds wrote:

Btw, here's the result of the "documentation":

	dnl check for Unix98 socklen_t
	AC_MSG_CHECKING(for socklen_t)
	AC_TRY_COMPILE([#include <sys/socket.h>
	socklen_t x;
	],[],[AC_MSG_RESULT(yes)],[
	AC_TRY_COMPILE([#include <sys/socket.h>
	int accept (int, struct sockaddr *, size_t *);
	],[],[
	AC_MSG_RESULT(size_t)
	AC_DEFINE(socklen_t,size_t)], [
	AC_MSG_RESULT(int)
	AC_DEFINE(socklen_t,int)])])

isn't that nice? Before the "documentation", you could just use

	int accept(int, struct sockaddr *, int *);

and it would work. EVERYWHERE. No autoconf crap required.

So don't talk to me about documentation. It's pure and unadulterated crap.

		Linus

Hi,

On Sun, 11 Sep 2005, Linus Torvalds wrote:

Okay. I have to admit that what you presented is a good argument.

However, the code I usually have to deal with is comparable to what you read on www.thedailywtf.com, and even a "socklen_t l;" with that type of code is more helpful than a simple "int l;", which might even be reused as something completely different.

That said, in a well designed and clean project, such as git, such types of documentation should not be necessary.

Ciao, Dscho

On Sun, 11 Sep 2005, Junio C Hamano wrote:

I've never noticed autoconf successfully improving portability, and it seems to mostly obfuscate errors. E.g., the GNU binutils I was trying to build recently, if you don't have "msgfmt", helpfully runs "no" instead. Of course, that's autoconf being misused, but if binutils can't use it correctly, I doubt any other project can keep from messing up.

Compatibility workarounds with simple detection scripts invoked by people who find they actually need workarounds are probably best.

	-Daniel
*This .sig left intentionally blank*

I'm running git & cogito on OSX 10.3.9 (Panther) with fink 0.7.1(stable), and have been using git w/o problems. I've just done an update and recompiled to confirm...

On 9/11/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Not a problem on 10.3.9.
 

Not a problem on 10.3.9.
 

I _am_ seeing this problem, but it's definitely an issue with Tk. I'd
be thankful if you could post the fixes...
 

sudo cpan install File::Temp ?

At any rate, I've just checked and File::Temp is part of the Perl 5.8.1 installed in 10.3.9. Even fink knows this, and if you do apt-cache show system-perl it'll tell you that it includes File::Temp.

Any platform-specific changes should be limited to backwards compat, really. MacOSX is converging quickly towards GNU/Linux compatibility in the build environment.

cheers,

martin

Hi,

On Mon, 12 Sep 2005, Martin Langhoff wrote:

Call me backwards. I am using 10.2.8, mainly because I do not intend to 
shell out bucks everytime Apple decides to increment the major version 
number of OSX. For exactly the same reason I do not have a single machine 
running Microsoft software.
 
It is great that you confirmed what I was suspecting, namely that newer 
OSXes do not share the problems of my old one.

Ciao, Dscho

I am running git/cogito on MacOSX 10.3.x mostly as a client, and it works pretty well. My main dev machines are Debian boxes, so the OSX build is most often just fetching commits and running cg-log. So it's not very intensive ;)

I get all my build dependencies from Fink, and also get diffutils from Fink, as the diff included in MacOSX is old/buggy. The one in Fink's diffutils matches GIT's expectations ;)

There is _one_ bug I've seen with cg-diff and I haven't had time to fix. On OSX, running cg-diff with no parameters doesn't show anything. For some reason, it fails to list the files. If you give it the paths explicitly, it'll give you the appropriate diff.

And there is a problem with gitk too: the tk that I get from fink gets the panels sizes all wrong for gitk. I doubt this is a bug in gitk though.

cheers,

martin 

On 8/27/05, John Ellson <ellson@research.att.com> wrote:

On 8/27/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:

Blame the xargs implementation. Fixed.

martin

On 8/29/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:

I posted the patch at the same time that I was writing this, but it got eaten by a b0rken MTA setup on my laptop. Reposted.

cheers,

martin