#775: Building Parrot doesn't work with dmake
-------------------+--------------------------------------------------------
Reporter: MoC | Type: bug
Status: new | Priority: major
Milestone: | Component: configure
Version: trunk | Severity: medium
Keywords: | Lang:
Patch: | Platform: win32
-------------------+--------------------------------------------------------
Comment(by doughera):
Replying to [comment:2 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 [email protected] mt.exe -nologo -manifest [email protected]
-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 [email protected]
-outputresource:$@;1
}}}
This way the 32 copies of this logic could be collapsed in one
*documented* Configure.pl variable.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/775#comment:4>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
