Boyd Lynn Gerber [off-list ref] writes:
On Sun, 8 Jun 2008, Jakub Narebski wrote:
quoted
Boyd Lynn Gerber [off-list ref] writes:
quoted
This patch adds support to compile git on 12 additional platforms.
They are based on UNIX Systems Labs (USL)/Novell and SYS V
based OS's, SCO OpenServer 5.0.X, SCO UnixWare 7.1.4, OpenServer 6.0.X and
SCO pre OSR 5 OS's to build and run git.
Signed-off-by: Boyd Lynn Gerber <redacted>
---
[...]
quoted
git-compat-util.h
__USLC__ indicates UNIX System Labs Corperation (USLC), or a Novell-derived
compiler and/or some SysV based OS's.
__M_UNIX indicates XENIX/SCO UNIX/OpenServer 5.0.7 and prior releases
of the SCO OS's. It is used just like Apple and BSD, both of these
shouldn't have _XOPEN_SOURCE defined.
Above info is neither in commit message, not in comment in some file.
It would be nice to have it in somewhere, and not only in mailing list
archives.
This was from my own copy of the master archive. It is my proposal. I
thought you had to get an OK from this list before you do a push to the
main archive. Am I missing something? I am new to this list and the
proper methods for submitting patches. I thought I was following the
guidelines from
http://repo.or.cz/w/git.git?a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD
What am I missing?
It might appear that many people somehow hate your patch and ganging up on
it, and if so I apologize for them and I assure you that they do not mean
ill.
There seem to be some confusion either in the SubmittingPatches document
or the way some suggestions have been given in the recent postings by
people, so let's clear it up first.
There are four different kinds of information you would want to convey
when you send patches to the list. This is just a convention around here,
but the tool is built to support that convention, so you can consider it
the suggested BCP in any git managed projects that employ e-mail based
workflow.
* What the patch is about, a short and sweet summary. This should be
something that can be used to identify the change and it should be easy
to tell what it is about when viewed in "git log --pretty=oneline" or
in "git shortlog" output. This goes to Subject: line.
* Justification for the patch. When anybody views with "git show" the
change after it gets committed, "how" the patch changes can be seen,
but what cannot be easily seen is "why", and the commit message is the
place to describe it. This takes various forms, depending on the
nature of the patch:
* For a fix, describe how the status-quo is broken, what the desired
behaviour should be, and discuss and defend why you chose this
specific approach to fix among other possible avenues. E.g. "If you
use this and that option together, the command does this, which is
not correct. It should do that instead. For that, we introduce
helper function X and Y use them in each codepaths. We could instead
use a single helper that does X or Y depending on an option but these
two codepaths are likely to evolve into doing even more different
things, and using separate functions would be cleaner."
* For an enhancement, describe in what situation the new feature is
useful, defend why that use case is worth supporting, state how
awkward (or perhaps impossible) to do the same thing is with the
current set of features, and discuss and defend why you chose this
specific approach to fix the awkwardness among other possibilities.
E.g. "This adds a new feature X that works like this. When you have
Y and want to arrive at Z, with the current set of commands you would
need to do W, but...".
The point is to help people, who later wonder why the change was made
and on what basis the author thought the change was necessary and/or
sufficient back then when the change was made, understand the context.
This comes at the beginning of the e-mail message, and is concluded by
S-o-b line(s).
* Supporting material that makes it easy to understand the particular
iteration of the patch in the context of review discussion, things like
"Compared to the previous round, I changed this and that, thanks to
comments from X and Y." Because only the final iteration will get
committed in the final history, it does not make sense to include such
information in the commit message. This comes after the commit log
message, and a single three-dash line is used to separate this part
from the commit log message.
* The change itself, aka "patch". This comes at the end of the message.
Let's look at the pieces you have after --- (the first one is the only one
that counts).
Makefile
Add changes for System V, UnixWare, SCO OS's
This is something poeple can find out and guess by looking at the patch
itself, and is unnecessary, not even as supporting material.
__USLC__ indicates UNIX System Labs Corperation (USLC), or a Novell-derived
compiler and/or some SysV based OS's.
__M_UNIX indicates XENIX/SCO UNIX/OpenServer 5.0.7 and prior releases
of the SCO OS's. It is used just like Apple and BSD, both of these
shouldn't have _XOPEN_SOURCE defined.
These are valuable clues to anybody who is unfamiliar with (and/or do not
have an easy access to) these systems. When people later want to touch
git-compat-util.h around the place where !defined(__USLC__) is used, they
would run "git blame" (or perhaps "git log -S__USLC__") to find your
commit that modified this line, and by looking at the commit log message
why you added these symbols on the #if line. It would help protect your
changes from begin broken by them if you help them understand why these
are there, and the above two paragraphs should definitely go to the commit
log message. They are not mere supporting material for this review cycle
alone.
"..., both of these shouldn't have" however could even be more helpful if
it was stated like "On these platforms, defining _XOPEN_SOURCE hides
definitions of X, Y and Z that we use, which is not what we want.", for
people who would want to know what specific breakage the change addresses.
It would change "Ok, somebody with SCO systems says this patch fixes
things for him" to "I see, if _XOPEN_SOURCE over there makes *that*
function unavailable, then we definitely shouldn't have _XOPEN_SOURCE
defined at this point of the header file". IOW, it makes "Ok, I trust the
guy's judgement, even though the details are fuzzy to me" into "Ok, I
agree with his judgement".
On Sun, 8 Jun 2008, Junio C Hamano wrote:
Boyd Lynn Gerber [off-list ref] writes:
quoted
On Sun, 8 Jun 2008, Jakub Narebski wrote:
This was from my own copy of the master archive. It is my proposal. I
thought you had to get an OK from this list before you do a push to the
main archive. Am I missing something? I am new to this list and the
proper methods for submitting patches. I thought I was following the
guidelines from
http://repo.or.cz/w/git.git?a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD
What am I missing?
It might appear that many people somehow hate your patch and ganging up
on it, and if so I apologize for them and I assure you that they do not
mean ill.
This list has been very good. The problem comes from other lists and
personal assualts on my domain.
There seem to be some confusion either in the SubmittingPatches document
or the way some suggestions have been given in the recent postings by
people, so let's clear it up first.
Yes, I was a bit confused but the docs/email/IRC. I really apperciate the
message below. I really want to comply with the rules of this list and
make sure my changes make it into the master/core source.
...
* For an enhancement, describe in what situation the new feature is
useful, defend why that use case is worth supporting, state how
awkward (or perhaps impossible) to do the same thing is with the
current set of features, and discuss and defend why you chose this
specific approach to fix the awkwardness among other possibilities.
E.g. "This adds a new feature X that works like this. When you have
Y and want to arrive at Z, with the current set of commands you would
need to do W, but...".
The point is to help people, who later wonder why the change was made
and on what basis the author thought the change was necessary and/or
sufficient back then when the change was made, understand the context.
This comes at the beginning of the e-mail message, and is concluded by
S-o-b line(s).
I agree. I am not sure on some things but I will ask more later.
* Supporting material that makes it easy to understand the particular
iteration of the patch in the context of review discussion, things like
"Compared to the previous round, I changed this and that, thanks to
comments from X and Y." Because only the final iteration will get
committed in the final history, it does not make sense to include such
information in the commit message. This comes after the commit log
message, and a single three-dash line is used to separate this part
from the commit log message.
* The change itself, aka "patch". This comes at the end of the message.
...
__USLC__ indicates UNIX System Labs Corperation (USLC), or a Novell-derived
compiler and/or some SysV based OS's.
__M_UNIX indicates XENIX/SCO UNIX/OpenServer 5.0.7 and prior releases
of the SCO OS's. It is used just like Apple and BSD, both of these
shouldn't have _XOPEN_SOURCE defined.
These are valuable clues to anybody who is unfamiliar with (and/or do
not have an easy access to) these systems. When people later want to
touch git-compat-util.h around the place where !defined(__USLC__) is
used, they would run "git blame" (or perhaps "git log -S__USLC__") to
find your commit that modified this line, and by looking at the commit
log message why you added these symbols on the #if line. It would help
protect your changes from begin broken by them if you help them
understand why these are there, and the above two paragraphs should
definitely go to the commit log message. They are not mere supporting
material for this review cycle alone.
I will have to find all this information. It took me 2 months in my
personal time to find and fix them. I will have to get back on this
below.
"..., both of these shouldn't have" however could even be more helpful
if it was stated like "On these platforms, defining _XOPEN_SOURCE hides
definitions of X, Y and Z that we use, which is not what we want.", for
people who would want to know what specific breakage the change
addresses.
It would change "Ok, somebody with SCO systems says this patch fixes
things for him" to "I see, if _XOPEN_SOURCE over there makes *that*
function unavailable, then we definitely shouldn't have _XOPEN_SOURCE
defined at this point of the header file". IOW, it makes "Ok, I trust
the guy's judgement, even though the details are fuzzy to me" into "Ok,
I agree with his judgement".
Thanks, more later when time permits.
--
Boyd Gerber [off-list ref]
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
On Sun, 8 Jun 2008, Junio C Hamano wrote:
* Justification for the patch. When anybody views with "git show" the
change after it gets committed, "how" the patch changes can be seen,
but what cannot be easily seen is "why", and the commit message is the
place to describe it. This takes various forms, depending on the
nature of the patch:
* For a fix, describe how the status-quo is broken, what the desired
behaviour should be, and discuss and defend why you chose this
specific approach to fix among other possible avenues. E.g. "If you
use this and that option together, the command does this, which is
not correct. It should do that instead. For that, we introduce
helper function X and Y use them in each codepaths. We could instead
use a single helper that does X or Y depending on an option but these
two codepaths are likely to evolve into doing even more different
things, and using separate functions would be cleaner."
* For an enhancement, describe in what situation the new feature is
useful, defend why that use case is worth supporting, state how
awkward (or perhaps impossible) to do the same thing is with the
current set of features, and discuss and defend why you chose this
specific approach to fix the awkwardness among other possibilities.
E.g. "This adds a new feature X that works like this. When you have
Y and want to arrive at Z, with the current set of commands you would
need to do W, but...".
...
"..., both of these shouldn't have" however could even be more helpful if
it was stated like "On these platforms, defining _XOPEN_SOURCE hides
definitions of X, Y and Z that we use, which is not what we want.", for
people who would want to know what specific breakage the change addresses.
It would change "Ok, somebody with SCO systems says this patch fixes
things for him" to "I see, if _XOPEN_SOURCE over there makes *that*
function unavailable, then we definitely shouldn't have _XOPEN_SOURCE
defined at this point of the header file". IOW, it makes "Ok, I trust the
guy's judgement, even though the details are fuzzy to me" into "Ok, I
agree with his judgement".
So the patch should be
From: Boyd Lynn Gerber <redacted>
Date: Sun, 8 Jun 2008 11:41:46 -0600
[PATCH] Port to 12 other Platforms.
This patch adds support to compile and run git on 12 additional platforms.
The platforms are based on UNIX Systems Labs (USL)/Novell/SYS V code base.
The most common are Novell UnixWare 2.X.X, SCO UnixWare 7.X.X,
OpenServer 5.0.X, OpenServer 6.0.X, and SCO pre OSR 5 platforms.
This is from
# 1 "/usr/include/netinet/tcp_f.h"
The problem is that git source has blocked some typedefs
by excluding certain <sys/types.h> content.
Looking at the the various platform header, I see around line 450
#if defined(_KERNEL) || !defined(_POSIX_SOURCE) \
&& !defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)
The git source is covering the u_short typedef line and other typedefs
are also covered in the platforms. They all lead back to the above
which comes from
git-compat-util.h
about line 66. I had to make the following changes
#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
The _XOPEN_SOURCE hides many typedefs.
__USLC__ indicates UNIX System Labs Corperation (USLC), or a Novell-derived
compiler and/or some SysV based OS's.
__M_UNIX indicates XENIX/SCO UNIX/OpenServer 5.0.7 and prior releases
of the SCO OS's. It is used just like Apple and BSD, both of these
shouldn't have _XOPEN_SOURCE defined.
This is with suggestions and modifications from
Daniel Barkalow [off-list ref]
Junio C Hamano [off-list ref]
Thomas Harning [off-list ref]
Jeremy Maitin-Shepard [off-list ref]
Signed-off-by: Boyd Lynn Gerber <redacted>
--
Boyd Gerber [off-list ref]
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
---
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
---
git-compat-util.h
__USLC__ indicates UNIX System Labs Corperation (USLC), or a Novell-derived
compiler and/or some SysV based OS's.
__M_UNIX indicates XENIX/SCO UNIX/OpenServer 5.0.7 and prior releases
of the SCO OS's. It is used just like Apple and BSD, both of these
shouldn't have _XOPEN_SOURCE defined.
diff --git a/Makefile b/Makefile
index cce5a6e..026de2f 100644
--- a/Makefile
+++ b/Makefile
@@ -564,6 +564,45 @@ endif
ifeq ($(uname_S),GNU/kFreeBSD)
NO_STRLCPY = YesPlease
endif
+ifeq ($(uname_S),UnixWare)
+ CC=cc
+ NEEDS_SOCKET = YesPlease
+ NEEDS_NSL = YesPlease
+ NEEDS_SSL_WITH_CRYPTO = YesPlease
+ NEEDS_LIBICONV = YesPlease
+ SHELL_PATH = /usr/local/bin/bash
+ NO_IPV6 = YesPlease
+ NO_HSTRERROR = YesPlease
+ BASIC_CFLAGS += -Kthread
+ BASIC_CFLAGS += -I/usr/local/include
+ BASIC_LDFLAGS += -L/usr/local/lib
+ INSTALL = ginstall
+ TAR = gtar
+ NO_STRCASESTR = YesPlease
+ NO_MEMMEM = YesPlease
+endif
+ifeq ($(uname_S),SCO_SV)
+ ifeq ($(uname_R),3.2)
+ CFLAGS = -O2
+ endif
+ ifeq ($(uname_R),5)
+ CC=cc
+ BASIC_CFLAGS += -Kthread
+ endif
+ NEEDS_SOCKET = YesPlease
+ NEEDS_NSL = YesPlease
+ NEEDS_SSL_WITH_CRYPTO = YesPlease
+ NEEDS_LIBICONV = YesPlease
+ SHELL_PATH = /usr/bin/bash
+ NO_IPV6 = YesPlease
+ NO_HSTRERROR = YesPlease
+ BASIC_CFLAGS += -I/usr/local/include
+ BASIC_LDFLAGS += -L/usr/local/lib
+ NO_STRCASESTR = YesPlease
+ NO_MEMMEM = YesPlease
+ INSTALL = ginstall
+ TAR = gtar
+endif
ifeq ($(uname_S),Darwin)
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
diff --git a/git-compat-util.h b/git-compat-util.h
index 01c4045..c04e8ba 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -39,7 +39,7 @@
/* Approximation of the length of the decimal representation of this type. */
#define decimal_length(x) ((int)(sizeof(x) * 2.56 + 0.5) + 1)
-#if !defined(__APPLE__) && !defined(__FreeBSD__)
+#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
--
1.5.2.4