[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