Re: Unlink failure on abort

2017-06-15 Thread Orgad Shaneh
On Friday, June 16, 2017, Henrik Carlqvist wrote: > On Fri, 16 Jun 2017 01:16:09 +0300 > Orgad Shaneh > wrote: > > > > On Thu, Jun 15, 2017 at 10:33 PM, Orgad Shaneh > > > > wrote: > > >> mingw32-make[1]: ***

Re: Unlink failure on abort

2017-06-15 Thread Orgad Shaneh
On Fri, Jun 16, 2017 at 12:46 AM, Orgad Shaneh wrote: > On Thu, Jun 15, 2017 at 10:33 PM, Orgad Shaneh wrote: > >> Hi, >> >> I'm using mingw32-make 4.2.1 from MSYS2/mingw32. >> >> When I abort a build, make fails to unlink the intermediate files. I >>

Re: Unlink failure on abort

2017-06-15 Thread Orgad Shaneh
On Thu, Jun 15, 2017 at 10:33 PM, Orgad Shaneh wrote: > Hi, > > I'm using mingw32-make 4.2.1 from MSYS2/mingw32. > > When I abort a build, make fails to unlink the intermediate files. I > previously used 4.1.90, and I don't remember having these problems. > > This happens even

Unlink failure on abort

2017-06-15 Thread Orgad Shaneh
Hi, I'm using mingw32-make 4.2.1 from MSYS2/mingw32. When I abort a build, make fails to unlink the intermediate files. I previously used 4.1.90, and I don't remember having these problems. This happens even for a single job (without -j). Output: main.cpp mingw32-make[1]: *** Deleting file

Re: Checking software build tries for “commands.cmo”

2017-06-15 Thread SF Markus Elfring
> Did you tell make, then, to disable all of its default rules for creating > commands.mli or, > for that matter, commands.cmo, by checking them out of version control? Not directly so far. - The source file “commands.mli” is not needed for the generation of the object module “commands.cmo” in

RE: Checking software build tries for “commands.cmo”

2017-06-15 Thread Martin Dorey
Sorry for my fat-fingered phoning. >> Would you have it complain that commands.mli,v, RCS/commands.mli,v, >> RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing? > Not really in this use case. Did you tell make, then, to disable all of its default rules for creating

Checking alternatives for a dynamic make rule construction

2017-06-15 Thread SF Markus Elfring
Hello, I have constructed the following small script to be executed by the program “GNU Make 4.2.1-1.7” on my openSUSE Tumbleweed system. define rule_pair = name::=$(1) $$(name:.ml=.cmo): $$(name) $$(OCAMLC_CMD) -c $$< $$(name:.ml=.cmx): $$(name) $$(OCAMLOPT_CMD) -c $$< endef

Re: Checking software build tries for “commands.cmo”

2017-06-15 Thread Martin Dorey
Would you have it complain that commands.mli,v, RCS/commands.mli,v, RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing? > Not really in this use case. Did you tell make, then, to disable all of its default rules for creating commands.mli or, for that matter, commands.cmo, by

Re: Checking software build tries for “commands.cmo”

2017-06-15 Thread Martin Dorey
Would you have it complain that commands.mli,v, RCS/commands.mli,v, RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing? > Not really in this use case. Did you tell make, then, to disable all of its default rules for creating commands.mli or, for that matter, commands.cmo, by

[bug #51237] Deadlock in Ctrl-C handler on Windows

2017-06-15 Thread Michael Builov
Follow-up Comment #3, bug #51237 (project make): I have created test application, which detaches console and sleeps for 1000 seconds: #include int main(int argc, char *argv[]) { FreeConsole(); Sleep(100); return 0; } And tested it with this makefile: # run make -j -O, then

[bug #51237] Deadlock in Ctrl-C handler on Windows

2017-06-15 Thread Michael Builov
Follow-up Comment #2, bug #51237 (project make): >> ...Would you be willing to assign copyright for your changes to the FSF... Yes, I will, no problem. >> ...signaling the event you added will not interrupt that wait... New event is not supposed to interrupt Main thread waiting for

Re: Checking software build tries for “commands.cmo”

2017-06-15 Thread SF Markus Elfring
>> I have noticed a moment ago that an interface description file was missing >> somehow for the OCaml source file in this compilation attempt. > ... >> I wonder then that the make tool did not give me a direct clue for a failed >> software dependency as I am used to in other cases. > Would you