[PATCH v4 2/4] config.mak.uname: support for modern HPE NonStop config.

[PATCH v4 2/4] config.mak.uname: support for modern HPE NonStop config.

[randall.s.becker]

From: "Randall S. Becker" <rsbecker@nexbridge.com>

A number of configuration options are not automatically detected by
configure mechanisms, including the location of Perl and Python.

There was a problem at a specific set of operating system versions
that caused getopt to have compile errors. Account for this by
providing emulation defines for those versions.

Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com>
---
 config.mak.uname | 34 +++++++++++++++++++++++++++++-----
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/config.mak.uname b/config.mak.uname
index 3ee7da0e23..aa4432ac2f 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -441,26 +441,45 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
 	# INLINE='' would just replace one set of warnings with another and
 	# still not compile in c89 mode, due to non-const array initializations.
 	CC = cc -c99
+	# Build down-rev compatible objects that don't use our new getopt_long.
+	ifeq ($(uname_R).$(uname_V),J06.21)
+		CC += -WRVU=J06.20
+	endif
+	ifeq ($(uname_R).$(uname_V),L17.02)
+		CC += -WRVU=L16.05
+	endif
+
 	# Disable all optimization, seems to result in bad code, with -O or -O2
 	# or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
 	# abends on "git push". Needs more investigation.
-	CFLAGS = -g -O0
+	CFLAGS = -g -O0 -Winline
 	# We'd want it to be here.
 	prefix = /usr/local
- 	# Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
+	# perl and python must be in /usr/bin on NonStop - supplied by HPE
+	# with operating system in that managed directory.
-	PERL_PATH = ${prefix}/bin/perl
-	PYTHON_PATH = ${prefix}/bin/python
-
+	PERL_PATH = /usr/bin/perl
+	PYTHON_PATH = /usr/bin/python
+	# The current /usr/coreutils/rm at lowest support level does not work
+	# with the git test structure. Long paths as in
+	# 'trash directory...' cause rm to terminate prematurely without fully
+	# removing the directory at OS releases J06.21 and L17.02.
+	# Default to the older rm until those two releases are deprecated.
+	RM = /bin/rm -f
 	# As detected by './configure'.
 	# Missdetected, hence commented out, see below.
 	#NO_CURL = YesPlease
 	# Added manually, see above.
+	NEEDS_SSL_WITH_CURL = YesPlease
+	NEEDS_CRYPTO_WITH_SSL = YesPlease
+	HAVE_DEV_TTY = YesPlease
 	HAVE_LIBCHARSET_H = YesPlease
 	HAVE_STRINGS_H = YesPlease
 	NEEDS_LIBICONV = YesPlease
 	NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
 	NO_SYS_SELECT_H = UnfortunatelyYes
 	NO_D_TYPE_IN_DIRENT = YesPlease
+	NO_GETTEXT = YesPlease
 	NO_HSTRERROR = YesPlease
 	NO_STRCASESTR = YesPlease
 	NO_MEMMEM = YesPlease
@@ -470,8 +489,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
 	NO_MKDTEMP = YesPlease
 	# Currently libiconv-1.9.1.
 	OLD_ICONV = UnfortunatelyYes
-	NO_REGEX = YesPlease
+	NO_REGEX=NeedsStartEnd
 	NO_PTHREADS = UnfortunatelyYes

 	# Not detected (nor checked for) by './configure'.
 	# We don't have SA_RESTART on NonStop, unfortunalety.
-- 
2.17.0.10.gb132f7033

Re: [PATCH v4 2/4] config.mak.uname: support for modern HPE NonStop config.

[Junio C Hamano]

randall.s.becker@rogers.com writes:

> @@ -470,8 +489,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
>  	NO_MKDTEMP = YesPlease
>  	# Currently libiconv-1.9.1.
>  	OLD_ICONV = UnfortunatelyYes
> -	NO_REGEX = YesPlease
> +	NO_REGEX=NeedsStartEnd
>  	NO_PTHREADS = UnfortunatelyYes
>
>  	# Not detected (nor checked for) by './configure'.
>  	# We don't have SA_RESTART on NonStop, unfortunalety.

The hunk header claims that the preimage has 8 lines while the
postimage has 13 lines, adding 5 new lines in total.  But that is
not what we can see in the hunk.

It is unclear to me if the numbers on the hunk header are bogus, or
the patch text was truncated, so I cannot use these two patches with
confidence.  The first hunk had the same issue, and 1/4 too.

I do not see v4 3/4 and v4 4/4, either.  It's not like you are the
only person who sends patches to the mailing list, and not having
the patches as responses to a cover letter for proper threading
makes it very hard to see which patches belong to the same series
and if all the necessary patches in a series have become available.
Is it possible to arrange that to happen?

Thanks.

RE: [PATCH v4 2/4] config.mak.uname: support for modern HPE NonStop config.

[randall.s.becker]

On January 3, 2019 14:45, Junio C Hamano wrote:
> To: randall.s.becker@rogers.com
> Cc: git@vger.kernel.org; Randall S. Becker <rsbecker@nexbridge.com>
> Subject: Re: [PATCH v4 2/4] config.mak.uname: support for modern HPE
> NonStop config.
> 
> randall.s.becker@rogers.com writes:
> 
> > @@ -470,8 +489,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
> >  	NO_MKDTEMP = YesPlease
> >  	# Currently libiconv-1.9.1.
> >  	OLD_ICONV = UnfortunatelyYes
> > -	NO_REGEX = YesPlease
> > +	NO_REGEX=NeedsStartEnd
> >  	NO_PTHREADS = UnfortunatelyYes
> >
> >  	# Not detected (nor checked for) by './configure'.
> >  	# We don't have SA_RESTART on NonStop, unfortunalety.
> 
> The hunk header claims that the preimage has 8 lines while the postimage
> has 13 lines, adding 5 new lines in total.  But that is not what we can
see in
> the hunk.
> 
> It is unclear to me if the numbers on the hunk header are bogus, or the
patch
> text was truncated, so I cannot use these two patches with confidence.
The
> first hunk had the same issue, and 1/4 too.
> 
> I do not see v4 3/4 and v4 4/4, either.  It's not like you are the only
person
> who sends patches to the mailing list, and not having the patches as
> responses to a cover letter for proper threading makes it very hard to see
> which patches belong to the same series and if all the necessary patches
in a
> series have become available.
> Is it possible to arrange that to happen?
> 
> Thanks.

I will reissue the whole package for you. I think I hacked it badly. Will
get to it after $DAYJOB is done.

Re: [PATCH v4 2/4] config.mak.uname: support for modern HPE NonStop config.

[Junio C Hamano]

<randall.s.becker@rogers.com> writes:

> I will reissue the whole package for you. I think I hacked it badly. Will
> get to it after $DAYJOB is done.

Thanks.