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

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

[John Ellson]

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


John

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

[Junio C Hamano]

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

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

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?

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

[Johannes Schindelin]

Hi,

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

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

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

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

[Martin Langhoff]

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

> - 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.
 
Can you share that fix? 

cheers,


martin

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

[Johannes Schindelin]

Hi,

On Sun, 11 Sep 2005, Martin Langhoff wrote:

> On 9/11/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 
> > - 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.
>  
> Can you share that fix? 

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:

diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -357,13 +357,13 @@ proc makewindow {} {
 	set geometry(ctexth) [expr {($texth - 8) /
 				    [font metrics $textfont -linespace]}]
     }
-    frame .ctop.top
+    frame .ctop.top -height $geometry(canvh)
     frame .ctop.top.bar
     pack .ctop.top.bar -side bottom -fill x
     set cscroll .ctop.top.csb
     scrollbar $cscroll -command {allcanvs yview} -highlightthickness 0
     pack $cscroll -side right -fill y
-    panedwindow .ctop.top.clist -orient horizontal -sashpad 0 -handlesize 4
+    panedwindow .ctop.top.clist -orient horizontal -sashpad 0 -handlesize 4 -height $geometry(canvh)
     pack .ctop.top.clist -side top -fill both -expand 1
     .ctop add .ctop.top
     set canv .ctop.top.clist.canv
@@ -433,9 +433,10 @@ proc makewindow {} {
     # for making sure type==Exact whenever loc==Pickaxe
     trace add variable findloc write findlocchange
 
-    panedwindow .ctop.cdet -orient horizontal
+    panedwindow .ctop.cdet -orient horizontal \
+	-height [expr $geometry(ctexth)*$linespc+4]
     .ctop add .ctop.cdet
-    frame .ctop.cdet.left
+    frame .ctop.cdet.left -width [expr $geometry(ctextw)*[font measure $textfont "0"]+8]
     set ctext .ctop.cdet.left.ctext
     text $ctext -bg white -state disabled -font $textfont \
 	-width $geometry(ctextw) -height $geometry(ctexth) \

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

[Junio C Hamano]

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 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.

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

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.

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

[Linus Torvalds]

On Sun, 11 Sep 2005, Junio C Hamano wrote:
>
> 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.

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

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

[A Large Angry SCM]

Linus Torvalds wrote:
> 
[regarding autoconf]
> 
> But hey, I don't care that much any more, since I'm not the sucker who 
> maintains it ;)

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

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

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> 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 ;)

Thanks for the vote of confidence ;-).

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

[Johannes Schindelin]

Hi,

On Sun, 11 Sep 2005, Linus Torvalds 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.

That was the original idea of autoconf...

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

... which is sometimes no option.

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

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

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

[Linus Torvalds]

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".

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

[PATCH] Use int instead of socklen_t

[Junio C Hamano]

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
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -80,11 +80,11 @@ static unsigned int children_deleted = 0
 
 static struct child {
 	pid_t pid;
-	socklen_t addrlen;
+	int addrlen;
 	struct sockaddr_storage address;
 } live_child[MAX_CHILDREN];
 
-static void add_child(int idx, pid_t pid, struct sockaddr *addr, socklen_t addrlen)
+static void add_child(int idx, pid_t pid, struct sockaddr *addr, int addrlen)
 {
 	live_child[idx].pid = pid;
 	live_child[idx].addrlen = addrlen;
@@ -178,7 +178,7 @@ static void check_max_connections(void)
 	}
 }
 
-static void handle(int incoming, struct sockaddr *addr, socklen_t addrlen)
+static void handle(int incoming, struct sockaddr *addr, int addrlen)
 {
 	pid_t pid = fork();
 
@@ -308,7 +308,7 @@ static int serve(int port)
 
 			if (FD_ISSET(sockfd, &fds)) {
 				struct sockaddr_storage ss;
-				socklen_t sslen = sizeof(ss);
+				int sslen = sizeof(ss);
 				int incoming = accept(sockfd, (struct sockaddr *)&ss, &sslen);
 				if (incoming < 0) {
 					switch (errno) {

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

[Johannes Schindelin]

Hi,

On Sun, 11 Sep 2005, Linus Torvalds wrote:

> 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".
> 
> 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.

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

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

[Linus Torvalds]

On Mon, 12 Sep 2005, Johannes Schindelin 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.

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

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

[Linus Torvalds]

On Sun, 11 Sep 2005, Linus Torvalds wrote:
> 
> 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.

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

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

[Johannes Schindelin]

Hi,

On Sun, 11 Sep 2005, Linus Torvalds wrote:

> On Sun, 11 Sep 2005, Linus Torvalds wrote:
> > 
> > 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.
> 
> Btw, here's the result of the "documentation":
> 
> [lots of ugly code]
>
> 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.

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

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

[Daniel Barkalow]

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

> 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 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.
> 
> > - mailinfo.c needs to have a simple strcasestr implementation, because 
> >   10.2.8 (at least in my setup) is lacking it!
> 
> 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.

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*

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

[Martin Langhoff]

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:
> - daemon.c needs a define or typedef for socklen_t.

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

Not a problem on 10.3.9.
 
> - 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.

I _am_ seeing this problem, but it's definitely an issue with Tk. I'd
be thankful if you could post the fixes...
 
> 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.

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

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

[Johannes Schindelin]

Hi,

On Mon, 12 Sep 2005, Martin Langhoff wrote:

> 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...

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

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

[Martin Langhoff]

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:
> Do git and cogito build easily on Mac OS/X now?   Are there binaries available
> anywhere?
> 
> 
> John
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Martin Langhoff]

On 8/27/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> 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.

Blame the xargs implementation. Fixed.


martin

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

[Martin Langhoff]

On 8/29/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Blame the xargs implementation. Fixed.

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