[fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Sven Barth
pascaldragon at googlemail.com
Sat Aug 10 12:52:36 CEST 2013
On 10.08.2013 11:21, Mark Morgan Lloyd wrote:
> Sven Barth wrote:
>
>>> I'm just about to add your next tests and redo. Recompilation is slow,
>>> and I don't think that firing up a bigger machine and using make -j
>>> helps that much.
>>>
>>
>> Ok, we now know that TVectorRegs is the culprit so we could try a
>> simpler testcase than the whole IDE. Could you please try whether the
>> following example triggers the exception as well? You can also speed
>> up the compilation by just doing a "make cycle" in the compiler
>> directory if this example works as intended.
>>
>> === code begin ===
>>
>> program test;
>>
>> const
>> MaxRegs = 128;
>>
>> type
>> TVectorRegs = record
>> reg : array [0..MaxRegs-1] of string;
>> end;
>>
>> TVectorView = object
>> OldRegs,NewRegs: TVectorRegs;
>> end;
>>
>> procedure DoAssignment(var aView: TVectorView);
>> begin
>> aView.NewRegs := aView.OldRegs;
>> end;
>>
>> var
>> v: TVectorView;
>> begin
>> DoAssignment(v);
>> end.
>>
>> === code end ===
>
> Using the same version of compiler that we've been testing, that
> compiles cleanly and runs without output (i.e. no visible exception etc.).
>
> Does that mean that it /is/ or /isn't/ safe to use make cycle rather
> than a complete build?
>
"make cycle" should be safe anyway. As long as we don't find a simpler
example you could just do a "make clean all
FPC=/path/to/freshly/cycled/ppcsparc" inside the "ide" directory to
speed things up (as we only change some of the compiler's console
output, but no unit structure you don't need to recompile the packages
each time)
Regards,
Sven
More information about the fpc-devel
mailing list