On 10/2/22 14:09, Paul Smith wrote:
I applied these changes but made a few mods:
Thanks. I assume you'll push this to savannah at some point? I had been
working on merging with your more-recent changes to GNU Make, and it
wouldn't hurt to have another pair of eyes look at this finicky busine
On October 2, 2022 6:13 PM, Paul Smith wrote:
>On Sun, 2022-10-02 at 17:48 -0400, rsbec...@nexbridge.com wrote:
>> > I understand that this type of reuse makes things easier for the
>> > gnulib folks, but for GNU make I'm not ready to drop support for
>> > platforms that are not POSIX enough to run
On Sun, 2022-10-02 at 17:48 -0400, rsbec...@nexbridge.com wrote:
> > I understand that this type of reuse makes things easier for the
> > gnulib folks, but for GNU make I'm not ready to drop support for
> > platforms that are not POSIX enough to run configure, and that
> > don't already have "make"
On October 2, 2022 5:24 PM, Paul Smith wrote:
>On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote:
>> (This would not be needed if 'make' used Gnulib's inttypes module.)
>
>I would be happy to use it, if using it didn't import a ton of other things
>that
>require POSIX tools AND an already-worki
On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote:
> (This would not be needed if 'make' used Gnulib's inttypes module.)
I would be happy to use it, if using it didn't import a ton of other
things that require POSIX tools AND an already-working make program.
I understand that this type of reus
On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote:
> On 9/21/22 23:49, Eli Zaretskii wrote:
> > This will cause problems in the native MS-Windows builds, where
> > printf in the system C runtime doesn't support %lld and %llu.
>
> Thanks for the review. Revised patch attached. It also addresses
> * Some POSIX systems (*BSD) do not allow locks to be taken on pipes, which
> caused the output sync feature to not work properly there. Also multiple
> invocations of make redirecting to the same output file (e.g., /dev/null)
> would cause hangs. Instead of locking stdout (which does have
On Sun, 2022-10-02 at 22:14 +0200, Frank Heckenbach wrote:
> I have a pattern rule like "%.c %.h &: %.y" for a tool (Bison) that
> may generate two output files (.c and .h), but in some cases
> (depending on the option "--defines") only one of them (.c).
The change was intentional, but has been re
I noticed a change in behaviour which I didn't find mentioned in
(or an apparent consequence of) the listed backward-incompatible
changes.
I have a pattern rule like "%.c %.h &: %.y" for a tool (Bison) that
may generate two output files (.c and .h), but in some cases
(depending on the option "--de
On 9/22/22 21:29, Sam James wrote:
Thanks and looks good.
Thanks for reviewing. How can I get this installed into GNU Make on
savannah? Or are we in some sort of quiet period before the next
release, and I should wait?
[1] https://lists.gnu.org/r/bug-make/2022-09/msg00126.html
Update of bug #12078 (project make):
Status: Fixed => None
Open/Closed: Closed => Open
Fixed Release: SCM => None
_
Update of bug #63126 (project make):
Status:None => Fixed
Open/Closed:Open => Closed
Fixed Release:None => SCM
Triage Status:
Update of bug #63098 (project make):
Status: Not A Bug => Fixed
Assigned to:None => psmith
Fixed Release:None => SCM
Triage Status:
Update of bug #63111 (project make):
Status:None => Fixed
Assigned to:None => psmith
Open/Closed:Open => Closed
Fixed Release:
Update of bug #58056 (project make):
Item Group: Bug => Documentation
Status:None => Fixed
Assigned to:None => psmith
Open/Closed:
Follow-up Comment #15, bug #58056 (project make):
I updated the documentation to try to make this clearer:
Old docs:
> Occasionally, however, you have a situation where you want to impose a
specific ordering on the rules to be invoked @emph{without} forcing the target
to be updated if one of tho
16 matches
Mail list logo
