After seeing Parrot 0.0.10 released and My new signature - Some assembly required, my interest was piqued enough that I downloaded the latest build of Parrot and attempted to build it.
Unfortunately, the supplied build mechanism baulked at the first fence on my system, so I set about trying to re-work it for my system.
However, it's deeply nested structure and lack of useful information when failure occurs has left me floundering around trying to manually unwind the process so that I can work out what is going on and how to intervene to correct the errors I am seeing.
If there is anyone reading these pages that is familiar with the whole Parrot::Configure::RunSteps process that would be prepared to work with me to get this working under Win32 and BCC, could they please /msg me. Thanks.
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
|
Re: Parrot build mechanism expertise required.
by Util (Priest) on Mar 24, 2003 at 02:45 UTC
|
Borland support is not as seamless as MinGW, yet; it should still be very usable. (At least for Parrot proper; I have not tried any of this with IMCC, Perl6, or the other languages.)
This works for me with ActivePerl 631 (5.6.1), and Borland's C++ 5.5.1 (The free version).
First, configure with 'cc' and 'link' set to 'bcc32', and removing the linkflags from Perl5:
perl Configure.pl --cc=bcc32 --link=bcc32 --linkflags=""
Edit "Makefile", changing 'AR_CR' from 'lib cr' to 'rem', like so:
-AR_CR = lib cr
+AR_CR = rem
Then build and test the code. Expect lots of warnings during the build.
nmake
nmake test
If you don't have nmake, get it free from Microsoft here: nmake. Borland's make will fail without some hacking.
I get these test failures, all of which I expected. (I am working on patches for all of them; none should affect your use of Parrot assembler):
Failed Test Status Wstat Total Fail Failed List of Failed
---------------------------------------------------------------
t/op/hacks.t 1 256 9 1 11.11% 7
t/op/string.t 1 256 99 1 1.01% 97
t/src/basic.t 255 65280 2 2 100.00% 1-2
t/src/exit.t 255 65280 2 2 100.00% 1-2
t/src/intlist.t 255 65280 4 4 100.00% 1-4
t/src/list.t 255 65280 2 2 100.00% 1-2
t/src/sprintf.t 255 65280 2 2 100.00% 1-2
Also, expect some tests to pass, but give spurious/false exit code failures, like this: failed with exit code 1 Again, this is a known bug in Win32. (I just haven't filed the patch, yet).
| [reply]
[d/l]
[select] |
|
|
Thankyou, that's both much more and much less than I expected.
Much more, in as much as I wasn't expecting to receive a solution to the question, just hoping for guidance in arriving at one:)
Much less in that I expected there to be considerably more work involved in getting there. The main difference between what you provided and what I had tried was the use of BCC32 for the linker instead of ilink32, and the use of "" for the linker options. Suffice to say, I now have parrot.exe built and the testing is progressing
Test results summary--final
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply]
[d/l] |
Re: Parrot build mechanism expertise required.
by jryan (Vicar) on Mar 24, 2003 at 01:02 UTC
|
| [reply]
[d/l] |
|
|
Basically, I don't want Cygwin and I don't want to use a build process that is dependant upon other parts of my installed and working system for it's operation.
I have tried to use the --ask switch to bypass the automated (and incorrect) detection of the build tools I wish to use, and would like a little help in working my way through the existing build process in order to construct a standard makefile. I have been trying to track my way through the existing build process, but am finding this to be an extremely difficult thing to do and hope that someone who is familiar with it will be able to guide me.
For example: What is the route of the dependancy tree. The obvious starting place is the file in the root of the build directories parrot.c, but all this does is include parrot.h. This is further complicated by the precence of other source files in this same directory which apparently are not directly a part of the parrot binary such as jit.c
I realise that the JIT and several other subprojects are related, but I can find no clear delineation between the sub-projects nor any simple roadmap of the dependancies of any given source file.
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply] |
|
|
Ack; I just upgraded my version of mozilla, and didn't realize that I wasn't logged in. Please reply to this node, instead of the last, so that I will know if you reply.
| [reply] |
|
|
Parrot's Configure routine uses your Perl5 compiler info as a starting point. Everything inherited from the Perl5 environment is overrideable. Parrot will often be built in environments where the compilers for Parrot and Perl5 differ; Configure.pl and friends have support for this. See my post below for more details. My personal goal for the free Win32 compiler support is an auto-recognition routine in Configure.pl, but no tuits yet.
| [reply] |
|
|
|
|
|
|
---
print map { my ($m)=1<<hex($_)&11?' ':'';
$m.=substr('AHJPacehklnorstu',hex($_),1) }
split //,'2fde0abe76c36c914586c';
| [reply]
[d/l] |
|
|
Re: Parrot build mechanism expertise required.
by Ctrl-z (Friar) on Mar 24, 2003 at 01:47 UTC
|
man, you just described my evening ;)
before you do anything rash like uninstall Perl - a precompiled binary is on the horizon. Assuming you are on windows.
time was, I could move my arms like a bird and...
| [reply] |
|
|
I undertand your frustrations and also your motivation for wanting a precompiled binary. However, I would actually like to build Parrot for myself, on my own machine using the toolset that I have.
BCC handles building Perl 5.6.1/5.8 natively--provided you grab the CPAN source distribution and not the Active State sources.
I am quite happy to put in the work to evolve a build machanism to suit my configuration, but I need some help getting started. The existing mechanism is very sophisticated, possibly with an eye to the future requirements, but doesn't seem to have any simple mechanism for allowing modifications to the process. I haven't yet found any way of tracing out the intermediate steps of the process so that I can work out what and where needs to be change to accomodate my setup.
To this end, I am hoping to start with a simplistic, single level makefile process. If I can get that to work, then I may be able to work backwards from that to seeing what changes/additions are required to the existing mechanism.
I sincerely feel that if the build process can be made a little more freindly to the non-unix environments, then a wider audience of contributors to the overall project would be enabled. It might then be possible to get some non-unix people in on the ground floor (or at least the first) instead of having to wait for a commercial concern to do the work with all the knock-on effects and delays that implies.
I currently have the time, a certain amount of expertise in areas that possibly fall outside the core competence of the existing concentrations of the development team, and would like to get involved. I'd go right ahead and just sign up to the mailing lists, but without having at least managed to get Parrot up and running, most of what I read about the internals is going right over my head. I see little benefit to the project in my turning my system into a unix-clone in order to work on the project as I would then be operating in a field outside of my best knowledge and would always be playing catchup to the those who's knowledge and expertise is far in advance of my own--whether it was Cygwin, linux, or unix.
It would seem better to me to concentrate on trying to contribute in thise areas where I have some existing skills especially as there appears to be an area where the project currently has a lack of them--or at least a lack of time in which to expend energies on development and testing on the Win32 platform.
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply] |
|
|
