Re: [PATCH] fix conflicting prototypes for getenv/getopt (v2 of Khem Raj's patch)

--00000000000077f157064fcbce64
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for the feedback.

Currently my patch updates getopt but leaves getopt_long and
getopt_long_only with old-style declarations, which is inconsistent.

I also understand the point about preferring Gnulib replacements rather
than continuing to patch local copies.

Would you prefer that I send a corrected incremental patch updating all
declarations consistently, or instead help move this toward the gnulib-port
approach?

I'm happy to work in either direction.

Thanks,
Shubham

On Sun, Apr 19, 2026 at 3:59=E2=80=AFAM Paul Eggert <[email protected]> wr=
ote:

> On 2026-04-18 15:18, Collin Funk wrote:
> > It would be nice for GNU make to use more Gnulib stuff, but as Paul
> > (Smith) writes in gl/README
>
> Thanks for reminding me about that. I see two paths forward here:
>
> 1. Give up on "build.sh" and require users to already have a
> decent-enough "make". This is the second option listed in gl/README.
>
> 2. Do the "git merge --no-ff gnulib-port" mentioned towards the end of
> gl/README. Make sure the merge fixes all problems mentioned by Shubham,
> along with all problems addressed by Gnulib.
>
> In the long run, (1) is a better way to go. In the short run (2) should
> work.
>
> If we keep doing (2) we should strive to minimizes the differences
> between Gnulib and GNU Make's copies of these files, and not change
> these files without first looking to see how Gnulib already fixed the
> porting problem (which it probably has).
>

--00000000000077f157064fcbce64
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p class=3D"gmail-isSelectedEnd">Hi,</p><p class=3D"gmail-=
isSelectedEnd">Thanks for the feedback.</p><p class=3D"gmail-isSelectedEnd"=
>Currently my patch updates getopt but leaves getopt_long and getopt_long_o=
nly with old-style declarations, which is inconsistent.</p><p class=3D"gmai=
l-isSelectedEnd">I also understand the point about preferring Gnulib replac=
ements rather than continuing to patch local copies.</p><p class=3D"gmail-i=
sSelectedEnd">Would you prefer that I send a corrected incremental patch up=
dating all declarations consistently, or instead help move this toward the =
gnulib-port approach?</p><p class=3D"gmail-isSelectedEnd">I&#39;m happy to =
work in either direction.</p><p>Thanks,<br>Shubham</p></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Sun, Apr 19, 2026 at 3:59=E2=80=AFAM Paul Eggert &lt;<a href=3D"mailto=
:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">On 2026-04-18 15:18, Collin Funk wro=
te:<br>
&gt; It would be nice for GNU make to use more Gnulib stuff, but as Paul<br=
>
&gt; (Smith) writes in gl/README<br>
<br>
Thanks for reminding me about that. I see two paths forward here:<br>
<br>
1. Give up on &quot;build.sh&quot; and require users to already have a <br>
decent-enough &quot;make&quot;. This is the second option listed in gl/READ=
ME.<br>
<br>
2. Do the &quot;git merge --no-ff gnulib-port&quot; mentioned towards the e=
nd of <br>
gl/README. Make sure the merge fixes all problems mentioned by Shubham, <br=
>
along with all problems addressed by Gnulib.<br>
<br>
In the long run, (1) is a better way to go. In the short run (2) should <br=
>
work.<br>
<br>
If we keep doing (2) we should strive to minimizes the differences <br>
between Gnulib and GNU Make&#39;s copies of these files, and not change <br=
>
these files without first looking to see how Gnulib already fixed the <br>
porting problem (which it probably has).<br>
</blockquote></div>

--00000000000077f157064fcbce64--