threads / discuss / 32331

Build fixes for another obscure Unix

Subject: Build fixes for another obscure Unix

## tl;dr

6 messages between Dec 13, 2012 and Dec 14, 2012.

replies: 5people: 4as markdown or json

David Michael· Dec 13, 2012, 15:22 UTC · lore
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
Pyeron, Jason J CTR (US)· Dec 13, 2012, 17:18 UTC · re: David Michael · lore

RE: Build fixes for another obscure Unix

Show 9 quoted lines
> -----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?
David Michael· Dec 13, 2012, 22:30 UTC · re: Pyeron, Jason J CTR (US) · lore

Re: Build fixes for another obscure Unix

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
Joachim Schmitz· Dec 14, 2012, 07:54 UTC · re: David Michael · lore

Re: Build fixes for another obscure Unix

David Michael wrote:
Show 32 quoted lines
> 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> 
David Michael· Dec 14, 2012, 19:48 UTC · re: Joachim Schmitz · lore

Re: Build fixes for another obscure Unix

Hi,

On Fri, Dec 14, 2012 at 2:54 AM, Joachim Schmitz <jojo@schmitz-digital.de> wrote:

Show 7 quoted lines
> 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
Junio C Hamano· Dec 13, 2012, 18:53 UTC · re: David Michael · lore

Re: Build fixes for another obscure Unix

David Michael <fedora.dm0@gmail.com> writes:
Show 6 quoted lines
> 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.

← back to recent threads