<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Clarification:<br>upgrade.sh (note the .sh) rebuilds everything<br>I wrote upgrade.py based on it, but missed the "everything" part.<br>upgrade.py only upgrades "the compiler" (and m3core, libm3..)<br><br>A better practise although inefficient is:<br><br> upgrade.py && ./do-cm3-all.py realclean skipgcc && ./do-cm3-all.py buildship <br><br>I didn't suggest that to you here in order to get further in the pipeline faster.<br><br>However upgrade.py w/o other rebuild could leave m3core.so too new for many programs.<br>But for purposes of building/cross-building just the compiler, my instructions are good.<br><br><br>John, I see you added cm3 to the FreeBSD ports and you clearly know what you are doing.<br>Nevertheless, I am a lazy snob, don't quite see what you are doing wrong, and am suggesting "just different", not clearly better.<br>But, to my credit, this "just different" is what I use all the time.<br>I have used it to cross to several systems, w/ and w/o cm3cg (w/ and w/o C backend).<br>It isn't fast, and it doesn't always have the best incrementality, but it does usually work.<br>There is redundancy. pylib.py essentially duplicates parts of the config files.<br><br><br>You misunderstood what I meant by "C backend" and from the ports history you will somewhat appreciate it.<br>The C backend, instead of having a lot to do with gcc, is a backend that generates C, and then invokes a C compiler.<br>The problem you had with -gstabs for example, goes away. We'll use whatever debugging format regular C/C++ use.<br>There is a little hope of taking the one C output and compiling it for different targets -- at least FreeBSD 8,9,10.<br>Currently the C is very word size dependent, endian dependent, and somewhat otherwise target-dependent.<br>I'd like to fix these aspects but it isn't easy by far, will take possibly controversial changes in the frontend and interface to backend.<br><br><br> - Jay<br><br><br><br><br><div><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: adacore@marino.st<br>Date: Sun, 19 Jan 2014 12:17:24 +0000<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">Hey..I like that that does capture some of My Way.<br><br><br>Here is my independent off the cuff write up though:<br><br><br> I know the ports system is nice. <br> I know we really need to be in it for many operating systems. <br><br><br> I suspect your problem is that you didn't "upgrade" to apply you changes at the right time.<br><br> Do any of these work for you: <br><br><br> https://modula3.elegosoft.com/cm3/snaps/snapshot-index.html <br><br><br> Anyway, please try this: <br><br><br> Ignore DragonFly at first. <br> Go to a system with a working cm3. Such as FreeBSD. Linux. Almost anything. <br> Such as from ports. <br> Make a backup, e.g. of /usr/local/cm3. <br> My instructions are unfortunately destructive of the existing install. <br> Checkout the full current CVS repository. <br> In that repository, run scripts/python/upgrade.py. <br> If that doesn't work, stop, and we'll help. <br> If that does work, apply your diffs. And upgrade.py again. You can say "upgrade.py skipgcc" here. <br> Then boot1.py c amd64_dragonflybsd <br> Make sure you say "c" and the target "amd64_dragonflybsd", anywhere on the command line. <br> Ok, "c" is actually up to you. Since nobody messes with ABI much, gcc/amd64 works for the same<br> for Linux, FreeBSD, OpenBSD, NetBSD, and Dragonfly. <br> If this works, it will give you, roughly amd64_dragonflybsd*.tar.gz <br> Copy that to your Dragonfly system, extract it, cd into it, make. <br> If that works, you have a native cm3. <br> Run it. It should say "can't find cm3.cfg". <br> Now on Dragonfly, mkdir -p /usr/local/cm3/bin <br> cp cm3 /usr/local/cm3/bin <br> export PATH=/usr/local/cm3/bin:$PATH <br> full CVS checkout <br> cd scripts/python ; ./boot2.sh <br> <br><br> You will need to have made small changes to pylib.py for this to work. <br> (And your config file should say to use the C backend, like Darwin and ARM_LINUX do.)<br><br><br><br><br> - Jay<br><br><br><br><br><div>> Date: Sun, 19 Jan 2014 13:09:37 +0100<br>> From: adacore@marino.st<br>> To: jay.krell@cornell.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)<br>> <br>> On 1/19/2014 12:40, Jay K wrote:<br>> > Your change looks about right.<br>> > <br>> > Did you first "upgrade" and existing install, with these changes, and<br>> > then cross?<br>> > That is what you must do.<br>> <br>> <br>> It's probably easier that I show you.<br>> I've attached "Makefile.local" (I added the .txt extension just now to<br>> help out some mail clients) which is my recipe.<br>> <br>> So I run three targets in a freshly patched workarea:<br>> 1) make cross-compiler<br>> 2) make assembler-code (called from cross-archive)<br>> 3) make cross-archive<br>> <br>> In the cross-compiler target, the FreeBSD bootstrap compiler builds<br>> m3middle, m3linker, m3front, mequake, and CM3 for the cross compiler.<br>> <br>> The cross-compiler then builds libm3core and libm3 with FreeBSD cm3cg<br>> Everything is cleaned, then the cross compiler builds everything again<br>> (including libm3core and libm3) along with m3objfile, sysutils, and<br>> patternmatching.<br>> <br>> Then the cm3.cfg is changed to specify HOST=freebsd, TARGET=dragonfly,<br>> cm3cg is cm3cg-AMD64_DRAGONFLY.<br>> <br>> I would not be surprised is there is a logic flaw or two in "make<br>> cross-compiler". The "how to port CM3" tutorial was slightly out of<br>> date and some of the instructions were a bit ambiguous so this was a<br>> best guess.<br>> <br>> Regards,<br>> John<br></div> </div></div> </div></body>
</html>