Multiple bugs in GNUMakefile

[khwilliamson]

Description

miniperl is first made. If a file that depends on is changed, it doesn't know to recompile miniperl.
It only runs to completion the first time a work space is compiled. This is because it does a rename ..\config.sh.tmp config.sh . rename fails if the destination file exists.

It runs to completion in spite of something failing. For example, if the dll can't be generated (say because of a missing symbol), gmake will continue to go through the modules, compiling each one. The original error, like a needle in a haystack, ends up in the midst of the output. This may not be a problem if the -j option isn't specified.

Steps to Reproduce

1st bug: touch locale.c; recompile; miniperl isn't remade.

2nd bug: gmake; gmake

3rd bug: Introduce a syntax error in a file. Then gmake -jN where N is some number, like the number of cores on your system

Expected behavior

None of these should happen
Perl configuration

This is a longstanding bug, and the configuration is irrelevant

[jkeenan]

The Subject of this ticket refers to GNUMakefile. I don't see that file in the core distribution. I do see:

$ find . -type f -iname '*GNUmakefile*'
./win32/GNUmakefile

Is that the file you're referring to? If so, is this bug (and bug ticket) Win32-specific?

Description

miniperl is first made. If a file that depends on is changed, it doesn't know to recompile miniperl. It only runs to completion the first time a work space is compiled. This is because it does a rename ..\config.sh.tmp config.sh . rename fails if the destination file exists.

It runs to completion in spite of something failing. For example, if the dll can't be generated (say because of a missing symbol), gmake will continue to go through the modules, compiling each one. The original error, like a needle in a haystack, ends up in the midst of the output. This may not be a problem if the -j option isn't specified.

Steps to Reproduce

1st bug: touch locale.c; recompile; miniperl isn't remade.

I see that happening on Linux, which implies that this problem is not Win32-specific. Is that correct?

2nd bug: gmake; gmake

What problem am I supposed to see in this case?

3rd bug: Introduce a syntax error in a file. Then gmake -jN where N is some number, like the number of cores on your system

What problem am I supposed to see in this case?

[demerphq]

I see that happening on Linux, which implies that this problem is not Win32-specific. Is that correct?

That is surprising to me. I see it getting rebuilt.

$ touch locale.c
$ make
ccache gcc -c -DPERL_CORE -D_REENTRANT -D_GNU_SOURCE -fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c99 -g -Wall -Werror=pointer-arith -Werror=vla -Wextra -Wno-long-long -Wno-declaration-after-statement -Wc++-compat -Wwrite-strings locale.c
ccache gcc -fstack-protector-strong -L/usr/local/lib -o miniperl \
    opmini.o perlmini.o universalmini.o  gv.o toke.o perly.o pad.o regcomp.o regcomp_debug.o regcomp_invlist.o regcomp_study.o regcomp_trie.o regexec.o dump.o util.o mg.o reentr.o mro_core.o keywords.o builtin.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o peep.o doop.o doio.o utf8.o taint.o deb.o globals.o perlio.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o  miniperlmain.o  -lpthread -ldl -lm -lcrypt -lutil -lc 

from that output I would say this does not affect *nix builds.

[demerphq]

@khwilliamson can you try 20751 please? I don't have win32 to test on.

[demerphq]

Note that the win32 makefiles all guard the rename command with a del command first, except for the case that @khwilliamson specified here.

[jkeenan]

I see that happening on Linux, which implies that this problem is not Win32-specific. Is that correct?

That is surprising to me. I see it getting rebuilt.

$ touch locale.c
$ make
ccache gcc -c -DPERL_CORE -D_REENTRANT -D_GNU_SOURCE -fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c99 -g -Wall -Werror=pointer-arith -Werror=vla -Wextra -Wno-long-long -Wno-declaration-after-statement -Wc++-compat -Wwrite-strings locale.c
ccache gcc -fstack-protector-strong -L/usr/local/lib -o miniperl \
    opmini.o perlmini.o universalmini.o  gv.o toke.o perly.o pad.o regcomp.o regcomp_debug.o regcomp_invlist.o regcomp_study.o regcomp_trie.o regexec.o dump.o util.o mg.o reentr.o mro_core.o keywords.o builtin.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o peep.o doop.o doio.o utf8.o taint.o deb.o globals.o perlio.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o  miniperlmain.o  -lpthread -ldl -lm -lcrypt -lutil -lc 

from that output I would say this does not affect *nix builds.

Correct.

[khwilliamson]

Most portions of this issue are still broken

[demerphq]

@khwilliamson "most parts of this issue are still broken" isnt a very helpful way to reopen the ticket. What parts are still broken? What parts aren't. Did the delete before rename work or not?

I dont understand bug 2. All you say is "gmake; gmake". What does that mean?

bug 3, i dont think is a bug in the perl build process. If you make various types of error in linux with a parallel build you will get various artifacts interspersed together.