Build fixes for another obscure Unix

Build fixes for another obscure Unix

[David Michael]

Hi,

I've been experimenting with git running on z/OS USS.  It is not yet
stable, but I have had to make a few fixes and generalizations in the
build system to get it to compile.

Would there be any interest in applying such individual compatibility
fixes for this system, even if a full port doesn't reach completion?

Thanks.

David

RE: Build fixes for another obscure Unix

[Pyeron, Jason J CTR (US)]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

> -----Original Message-----
> From: David Michael
> Sent: Thursday, December 13, 2012 10:23 AM
> 
> Hi,
> 
> I've been experimenting with git running on z/OS USS.  It is not yet
> stable, but I have had to make a few fixes and generalizations in the
> build system to get it to compile.

Maybe it would help address other build issues on other platforms.

> 
> Would there be any interest in applying such individual compatibility
> fixes for this system, even if a full port doesn't reach completion?

What are the down sides? Can your changes be shown to not impact builds on other systems?

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]

Re: Build fixes for another obscure Unix

[Junio C Hamano]

David Michael <fedora.dm0@gmail.com> writes:

> I've been experimenting with git running on z/OS USS.  It is not yet
> stable, but I have had to make a few fixes and generalizations in the
> build system to get it to compile.
>
> Would there be any interest in applying such individual compatibility
> fixes for this system, even if a full port doesn't reach completion?

If you post patches here, it may help you find like-minded people
who may want to join forces and help you complete the port, so by
all means.

If I pick up a partially completed series and carry it in my tree is
a separate matter.  The patch has to be cleanly done (i.e. without
too many #ifdefs) for longer-term maintainability, and it has to be
clear that the changes do not affect other platforms negatively.

Re: Build fixes for another obscure Unix

[David Michael]

Hi,

On Thu, Dec 13, 2012 at 12:18 PM, Pyeron, Jason J CTR (US)
<jason.j.pyeron.ctr@mail.mil> wrote:
>> Would there be any interest in applying such individual compatibility
>> fixes for this system, even if a full port doesn't reach completion?
>
> What are the down sides? Can your changes be shown to not impact builds on other systems?

I've pushed a handful of small compatibility patches to GitHub[1]
which are enough to successfully compile the project.  The default
values of the new variables should make them unnoticeable to other
systems.

Are there any concerns with this type of change?  If they would be
acceptable, I can try sending the first four of those patches to the
list properly.  (I expect the last two may be tweaked as I continue
working with the port.)

I do have a concern with strings.h, though.  That file will be
included for most people who run ./configure, when it wasn't before.
Do you think it's worth making a more detailed test to see if
strcasecmp is still undefined after string.h is included, rather than
just testing for the header's existence?

Thanks.

David

[1] https://github.com/dm0-/git/commits

Re: Build fixes for another obscure Unix

[Joachim Schmitz]

David Michael wrote:
> Hi,
>
> On Thu, Dec 13, 2012 at 12:18 PM, Pyeron, Jason J CTR (US)
> <jason.j.pyeron.ctr@mail.mil> wrote:
>>> Would there be any interest in applying such individual
>>> compatibility fixes for this system, even if a full port doesn't
>>> reach completion?
>>
>> What are the down sides? Can your changes be shown to not impact
>> builds on other systems?
>
> I've pushed a handful of small compatibility patches to GitHub[1]
> which are enough to successfully compile the project.  The default
> values of the new variables should make them unnoticeable to other
> systems.
>
> Are there any concerns with this type of change?  If they would be
> acceptable, I can try sending the first four of those patches to the
> list properly.  (I expect the last two may be tweaked as I continue
> working with the port.)
>
> I do have a concern with strings.h, though.  That file will be
> included for most people who run ./configure, when it wasn't before.
> Do you think it's worth making a more detailed test to see if
> strcasecmp is still undefined after string.h is included, rather than
> just testing for the header's existence?
>
> Thanks.
>
> David
>
> [1] https://github.com/dm0-/git/commits

For what's it worth: I ACK your HP-NonStop patch (as you can see by my 
comment in git-compat-util.h I was thinking along the same line)
https://github.com/dm0-/git/commit/933d72a5cfdc63fa9c3c68afa2f4899d9c3f791e
together with its prerequisit
https://github.com/dm0-/git/commit/301032c6488aeabb94ccc81bfb6d65ff2c23b924

ACKed by: Joachim Schmitz <jojo@schmitz-digital.de> 

Re: Build fixes for another obscure Unix

[David Michael]

Hi,

On Fri, Dec 14, 2012 at 2:54 AM, Joachim Schmitz
<jojo@schmitz-digital.de> wrote:
> For what's it worth: I ACK your HP-NonStop patch (as you can see by my
> comment in git-compat-util.h I was thinking along the same line)
> https://github.com/dm0-/git/commit/933d72a5cfdc63fa9c3c68afa2f4899d9c3f791e
> together with its prerequisit
> https://github.com/dm0-/git/commit/301032c6488aeabb94ccc81bfb6d65ff2c23b924
>
> ACKed by: Joachim Schmitz <jojo@schmitz-digital.de>

Okay, thanks for verifying.  Especially since another port needing
that header was just sent to the list, I'd prefer to see some
generalized feature test rather than building and maintaining an
explicit OS list.

No one has suggested any adjustments, so I'll send out those patches now.

Thanks.

David