Wiki**3

Compact is a very simple compiler. Nevertheless, it already incorporates all major components in a compiler (except for type validation).

The following is a quick guide to start your compiler from the Compact sources.

Unpacking the Goods

The first thing you have to do is check whether your development environment is friendly. CDK, RTS, and Compact -- your basic start up kit -- was made for Linux. It may, however, compile and run without problems in any Unix-like system. Some restrictions apply (e.g., the 32-bit vs. 64-bit issue could be a major source of unhappiness).

To check whether your system can be used, first check that you have yasm (nasm can also be used, if yasm is unavailable) and byacc (version 1.9 should work -- if not, check out the version available here). flex is ubiquitous, but ensure that you are using version 2.5.35 (other versions can also be made to work, YMMV). The recommended C++ compiler is GCC 4.3 (again, others may and, indeed, should work). In the commands below, tar is GNU tar, make is GNU make.

The versions indicated below are just examples.

LibRTS

To unpack, compile, and install LibRTS, do the following:

 tar xvfj librts-200903170001.tar.bz2 
 cd librts-200903170001
 make
 make install

If you are unlucky enough not to have GNU tar, try it this other way:

 bzcat librts-200903170001.tar.bz2 | tar xvf -
 cd librts-200903170001
 make
 make install

The last command will install the compiled version of librts (librts.a) in the libs directory, relative to ROOT (in the Makefile). By default, ROOT is defined as $HOME/compiladores/root.

LibCDK

Similarly, to unpack, compile, and install LibCDK, do the following:

 tar xvfj  libcdk4-200903152029.tar.bz2
 cd libcdk4-200903152029
 make
 make install

Compact

If the previous sections went well, then you should be ready to build Compact. All Makefiles share the same assumptions about ROOT, so if you make the same decisions regarding that variable in all cases, all should work.

Try it, just to be sure you can do it:

 tar xvfj compact-200903152029.tar.bz2
 cd compact-200903152029
 make 
 make install

Ok? Good.

Now that the trouble is behind, lets begin with a clean version: remove the old version and unpack Compact again:

 rm -rf compact-200903152029
 tar xvfj compact-200903152029.tar.bz2
 cd compact-200903152029

Now rename all files, so that the "Compact" part becomes the name corresponding to your compiler. For the sake of simplicity, we will call it "Potato".

If you have zsh:

 rename Compact Potato ./**/*(.)

Or, if you have the other rename (but still with zsh):

 rename 's/Compact/Potato/g' ./**/*(.)

If you have other shell variants (also good for zsh), try these:

 find . -type f -print -exec rename Compact Potato {} \;

Or:

 find . -type f -print -exec rename 's/Compact/Potato/g' {} \;

If all went well, all the "Compact" bits in the file names should now read "Potato".

Now that the outside is changed, lets concentrate on the inside. For this, we will use grep (GNU grep, if you must know) to find all occurrences of compact, Compact, and COMPACT, to change them, respectively, into potato, Potato, and POTATO. The idea is that all the factories and classes depending on the name, will now depend on the new name.

We will start with uppercase names (you may wish to repeat each of these cycles, to ensure that, for whatever reason, did not forget any occurrence):

 for i in `grep -rl COMPACT .`
 do
   sed -e 's/COMPACT/POTATO/g' < $i > $i.tmp
   mv $i.tmp $i
 done

Then:

 for i in `grep -rl Compact .`
 do
   sed -e 's/Compact/Potato/g' < $i > $i.tmp
   mv $i.tmp $i
 done

And, finally:

 for i in `grep -rl compact .`
 do
   sed -e 's/compact/potato/g' < $i > $i.tmp
   mv $i.tmp $i
 done

If you changed mknodedecls.pl with any of the above commands, it's almost certain it is no longer executable. Just do:

 chmod 755 mknodedecls.pl

That's all. If you did everything, a simple make should give you your "potato" compiler, albeit still compiling the original language. The idea is to regard this as a particularly annoying bug and go from there in the direction of the language you want to implement. Step by step. Baby steps.

Start with some concept that already exists and share some features: for instance, you may want to start by adding a "for" cycle concept after noting that the original compiler already provides a "while" cycle. Just add the new features wherever you find "while" features.

Good luck.