History

Pascaline » Development »

ToolChain

Problems with toolchain were caused by the fact that the makefile generator (GNUMakeFileGenerator) passes the compiler all sources. However, FreePascal can only compile one file at a time.

Compiling all files

It seems that (as of CDT 6) the option inputType.multipleOfTYpe of the org.eclipse.cdt.managedbuilder.buildDefinitions extension point works fine. This means that the tool is called once with all n files if set to true or it is called n times with one file at a time . This provides a chance to compiles all sources in order to mark as much errors as we can, even if files do not depend each other. The original implementation of the Pascaline toolchain just compiled the program (searching it as defined above), because the FreePascal compiler accepts one file at a time.

If multipleOfType is set to false, then the tool defined in the toolchain is called as many times as files are in the project being compiled. However, between each two invocations error markers are cleared. This cause that just errors in the last file (and its dependants files) are marked.

In order to solve this behaviour, first we tried to store internally all errors were made. However, we do not know when the build process starts as to clear the list of errors. Without clearing the list each time the build starts, errors that were solved would still appear in the sources. We posted a message to the cdt-dev list about an event or so for detecting a new build process, but with no answer: [[http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg16134.html]].

Therefore, we tried a different approach. Let's develop a wrapper of the FreePascal compiler. The wrapper accepts several files at a time and calls the compiler once per file passed in, composing the output so that it still can be parsed by the FreePascalErrorParser. The Pascaline toolchain is then changed accordingly to use the wrapper and setting the multipleOfType property to true. The wrapper is implemented in Java (it comprises two files).

Compiling the wrapper with gcj

In a first attempt we tried to compile it with gcj to produce a native executable. This way, CDT could invoke it directly (without having to specify "java -jar ..." for which the location of a Java JRE is needed). This approach works perfectly in Linux, but we found problems in Windows. The Windows executable (compiled with MinGW) stops as a result of a segmentation fault and does nothing. Even the most simple Java program compiled with MinGW's gcj doesn't work. It compiles fine (after installing the library [[LibIConv>>http://gnuwin32.sourceforge.net/packages/libiconv.htm]] for character set conversion) but produces the segmentation fault when run.

After a deep search we could find several references about this problem, but no solution at all:

Executing the wrapper with java

So we decided to use the wrapper in its java form and make the toolchain calls
"java -jar" to execute it. We can know where the JRE is by querying Eclipse (the eclipse.vm property points to the VM being used by Eclipse to run).

Binary parsers

Pascaline Windows version need to specify the Cygwin PE Parser (or PE Windows Parser) for binaries. The Linux version must specify GNU Elf Parser (org.eclipse.cdt.core.GNU_ELF). org.eclipse.cdt.core.ELF also works for Linux, however both present a slightly different list of symbols within the executable. We need to further investigate this. As for Mac, we need to specify MachO as binary format (org.eclipse.cdt.core.MachO or org.eclipse.cdt.core.MachO64) and macosx as osList.