Simplify makefile rules on windows.

[MoC]

Windows XP Professional, ActivePerl 5.10.0.1005-MSWin32, dmake 4.11

Trying to build Parrot using dmake results in the following error:

dmake:  makefile:  line 126:  Warning: -- Macro `O' redefined after use
dmake:  makefile:  line 130:  Warning: -- Macro `A' redefined after use
dmake:  makefile:  line 3236:  Warning: -- Found non-white space character after '[' in [[ -d parrot-$(VERSION) ] || ln -s $(CUR_DIR) parrot-$(VERSION)].
dmake:  makefile:  line 3340:  Error: -- Incomplete rule recipe group detected

(See attached Makefile) Especially for Strawberry Perl users this might be a blocker, as afaik Strawberry Perl ships only dmake by default, so someone should probably document this somewhere.

[MoC]

Makefile

[MoC]

I have to correct myself, Strawberry Perl actually also includes mingw32-make with which it works fine. Plus: Even though it might look like it judging from the Makefile I was trying to build in cmd.exe environment, not MSYS environment.

[NotFound]

I do some testing with Strawberry Perl. It does not recommend dmake for me, I suppose that must depend on the order of directories in PATH.

The main problem is caused by the usage of [ ] at the beginning of a command. Looks like this confuses dmake, don't know why. Replacing it whit 'test' fixes the problem.

After fixing that, it fails on 'if' commands. Looks like is trying to execute 'if' as a program instead of letting a shell take care of it. As a quick test I replaced all 'if' with 'cmd /c if', after doing that it has the same problem with 'rem' (value assigned to RANLIB).

At this point, I'm blocked. Don't know if replacing 'if' with something like $(SHELL) /c will not break other win32 builds, and don't know where the 'rem' value for RANLIB comes from.

[doughera]

Replying to NotFound:

I do some testing with Strawberry Perl. It does not recommend dmake for me, I suppose that must depend on the order of directories in PATH. The main problem is caused by the usage of [ ] at the beginning of a command. Looks like this confuses dmake, don't know why. Replacing it whit 'test' fixes the problem.

dmake uses [ and ] for its own special grouping purposes. Replacing them with 'test' allows dmake to successfully parse the line, but it still won't actually work. However, since it's in the 'release:' target, dmake won't ever try to execute it anyway, unless someone is trying to build a release.

After fixing that, it fails on 'if' commands. Looks like is trying to execute 'if' as a program instead of letting a shell take care of it. As a quick test I replaced all 'if' with 'cmd /c if', after doing that it has the same problem with 'rem' (value assigned to RANLIB). At this point, I'm blocked. Don't know if replacing 'if' with something like $(SHELL) /c will not break other win32 builds, and don't know where the 'rem' value for RANLIB comes from.

The 'rem' value comes from perl5's Configure. It's just a 'remark' or comment in DOS batch files. The Win32 library build process does not need to use 'ranlib' so it just ends up commented out.

For parrot, it would probably be better to simply omit the line

	$(RANLIB) $@

from the Makefile if it's not going to be used anyway. Alternatively, it may be that merely defining SHELL in the Makefile is sufficient for dmake. I don't know; I don't have any easy way to test.

As for the 'if exists' lines, it's hard to know what to make of them. I have no idea what '.manifest' files are or how they get created. I found no useful information of any sort in the parrot tree. Are they created during the build process by some tool, or are they added "by hand" and used if they happen to be there? Perhaps someone who understands the process better can suggest an appropriate approach.

Stepping back a moment, though, look at the relevant line in config/gen/makefiles/root.in:

#IF(win32):	if exist $@.manifest mt.exe -nologo -manifest $@.manifest -outputresource:$@;1

This is using perl to determine if the user is on Win32, passing that to a special home-brewed pre-processor to decide whether to include a specific line in Makefile, and then passing that result on to DOS to perform a conditional operation to decide whether to run mt.exe. That's mad. There are three conditional tests being performed by three different tools for just one line in the Makefile. This is then repeated 31 more times in the parrot tree.

Why not simply have perl do the 'if exist' test in Configure.pl (or whatever the appropriate logic would be) and store the result in $PConfig{win32_use_manifests}? Something like this:

#IF(win32_use_manifests):	mt.exe -nologo -manifest $@.manifest -outputresource:$@;1

This way the 32 copies of this logic could be collapsed in one *documented* Configure.pl variable.

[coke]

Changing summary to reflect Andy's suggestion a year ago.