Re: [fpc-devel] fpjson/jsonparser: EJSONScanner vs EScannerError
On Sun, 29 May 2011, Luiz Americo Pereira Camara wrote: On 29/5/2011 18:57, Michael Van Canneyt wrote: On Sun, 29 May 2011, Luiz Americo Pereira Camara wrote: I found that to handle error while parsing json through TJSONParser is necessary to consider two types of exceptions: EJSONScanner from jsonparser EScannerError from jsonscanner Well, there are 2 different kinds of errors: scanner errors, and parser errors. They should have 2 different classes. OK EJSONScanner seems misleading since hints to a scanner error You are right, it is misleading. Should a bug report be made? You can submit a request so they are merged (or one made a descendent of the other). Done: http://bugs.freepascal.org/view.php?id=19444 Fixed. Renamed and made descendent of EParserError (from Classes unit), so you have to test for 1 exception only. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
On 05/29/2011 04:35 PM, Mark Morgan Lloyd wrote: Felipe and Michael have pointed out to me that David Zhang's mipsel port has been integrated into trunk. Great ! Will this allow for producing code for PIC 32 Chips ? Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Comparison FPC 2.4.4 - Delphi 7
Hi, I compiled MSEide with FPC 2.4.4 and Delphi 7 for comparison. Delphi 7: Borland Delphi Version 15.0 Copyright (c) 1983,2002 Borland Software Corporation [...] 303079 lines, 5.31 seconds, 2256556 bytes code, 820297 bytes data. Exe size: 3.2MB FPC: Free Pascal Compiler version 2.4.4 [2011/04/23] for i386 Copyright (c) 1993-2010 by Florian Klaempfl [...] 302251 lines compiled, 45.2 sec , 2257728 bytes code, 1688152 bytes data 187 warning(s) issued 315 note(s) issued Exe size: 3.87 MB Interesting the big difference in data size. Source: http://svn.berlios.de/viewvc/mseide-msegui/trunk/ Commandline Delphi: dcc32.exe -B -I..\..\lib\common\kernel -U..\..\lib\common\kernel -U..\..\lib\common\kernel\i386-win32 -U..\..\lib\common\graphics -U..\..\lib\common\image -U..\..\lib\common\widgets -U..\..\lib\common\ifi -U..\..\lib\common\printer -U..\..\lib\common\designutils -U..\..\lib\common\sysutils -U..\..\lib\common\editwidgets -U..\..\lib\common\dialogs -U..\..\lib\common\regcomponents -U..\..\lib\common\serialcomm -U..\..\lib\common\serialcomm -U..\..\lib\common\delphicompatibility -dmse_no_db -dmse_no_opengl -dmse_no_math mseide.pas Commandline FPC: ppc386.exe -O2 -CX -XX -Xs -B -Fi..\.. \lib\common\kernel -Fu..\..\lib\common\kernel -Fu..\..\lib\common\kernel\i386-win32 -Fu..\..\lib\common\graphics -Fu..\..\lib\common\image -Fu..\..\lib\common\widgets -Fu..\..\lib\common\ifi -Fu..\..\lib\common\printer -Fu..\..\lib\common\designutils -Fu..\..\lib\common\sysutils -Fu..\..\lib\common\editwidgets -Fu..\..\lib\common\dialogs -Fu..\..\lib\common\regcomponents -Fu..\..\lib\common\serialcomm -Fu..\..\lib\common\serialcomm -dmse_no_db -dmse_no_opengl -dmse_no_math -omseidefpc.exe mseide.pas All MSE *.o,*.ppu and *.dcu files deleted before compiling. System: win2000, AMD Athlon XP 3000+, 1GB RAM Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
On Mon, May 30, 2011 at 9:26 AM, Michael Schnell mschn...@lumino.de wrote: Will this allow for producing code for PIC 32 Chips ? Are you saying that PIC 32 is MIPS? Little Endian? But even if it is, a RTL for PIC would be missing then. The currently made work is for linux-mipsel, so that means a new code generator and the existing linux RTL. pic-mipsel would require a new PIC32 RTL -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
In our previous episode, Felipe Monteiro de Carvalho said: Are you saying that PIC 32 is MIPS? Little Endian? The site lists 32-bit MIPS M4K? Core I have a PIC32MX795, though I don't use it (it is an alternate chip for the 16-bit dspic development board that i have. But even if it is, a RTL for PIC would be missing then. The currently made work is for linux-mipsel, so that means a new code generator and the existing linux RTL. I think full Object Pascal HLL will quickly exhaust the 128kb memory. (and in practical cases less, since then some of it will be allocated as DMA buffers by e.g. the ethernet engine) So one would really need a cut down RTL for this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote:
Isn't it easier to simply copy all compiled libraries to the target when
they are compiled (just like compiled test programs are copied)?
this second approach (which works well for me) copies the libraries when
the are compiled. No need to expand the %needlibrary directive.
Regards, Bernd.
Index: tests/utils/dotest.pp
===
--- tests/utils/dotest.pp (Revision 17610)
+++ tests/utils/dotest.pp (Arbeitskopie)
@@ -930,6 +930,8 @@
str(Config.Timeout,s);
execcmd:=execcmd+s;
end;
+ if Config.NeedLibrary then
+ execcmd:=execcmd+'export LD_LIBRARY_PATH='+RemotePath + ' ; ';
{ as we moved to RemotePath, if path is not absolute
we need to use ./execfilename only }
if not isabsolute(TestRemoteExe) then
@@ -1185,6 +1187,8 @@
var
PPDir : string;
Res : boolean;
+ LocalLibraryFile, LibraryFileName: String;
+ execres: Boolean;
begin
Res:=GetConfig(PPFile[current],Config);
@@ -1398,6 +1402,20 @@
begin
if (Config.NoRun) then
begin
+if (CompilerTarget = 'linux') and (RemoteAddr '') then
+{ if test program is a library, copy the library to the target }
+begin
+ LibraryFileName:= 'lib' +
ForceExtension(SplitFileName(PPFile[current]), 'so');
+ LocalLibraryFile:= OutputDir + '/' + SplitPath(PPFile[current]) +
LibraryFileName;
+ if FileExists(LocalLibraryFile) then
+ begin
+ execres:=ExecuteRedir(rcpprog,RemotePara+' '+ LocalLibraryFile+'
'+RemoteAddr+':' + RemotePath+'/'+ LibraryFileName,'',EXELogFile,'stdout');
+ if not execres then
+ begin
+Verbose(V_normal, 'Could not copy library ' + LibraryFileName);
+ end;
+ end;
+end;
{ avoid a second attempt by writing to elg file }
AddLog(EXELogFile,skipping_run_test+PPFileInfo[current]);
AddLog(ResLogFile,skipping_run_test+PPFileInfo[current]);
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
On 05/30/2011 10:37 AM, Felipe Monteiro de Carvalho wrote: Are you saying that PIC 32 is MIPS? Little Endian? http://ww1.microchip.com/downloads/en/DeviceDoc/DS-39904j.pdf PIC32 Microcontroller Families With USB, CAN and Ethernet says: 80 MHz, 1.56 DMIPS/MHz MIPS M4K Core 512K Flash with pre-fetch cache 128K RAM for data and program execution Fast interrupts and context switch I don't know about endianess with MIPS. pic-mipsel would require a new PIC32 RT It seems to be viable to do a PIC32 RTL, as the 32 PIC seems to offer a great price/performance relation many nice chips with appropriate I/O and good support by Microchip. The said document also states: Free USB, TCP/IP graphics and file system source code Broad Third Party ecosystem $49.99 starter kit with free C compiler Hardware trace for less than $80 See www.microchip.com/PIC32 as well. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
On 05/30/2011 10:58 AM, Marco van de Voort wrote: I have a PIC32MX795, though I don't use it (it is an alternate chip for the 16-bit dspic development board that i have. same here :) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 11:04, Bernd Mueller wrote: Jonas Maebe wrote: Isn't it easier to simply copy all compiled libraries to the target when they are compiled (just like compiled test programs are copied)? this second approach (which works well for me) copies the libraries when the are compiled. No need to expand the %needlibrary directive. Why do you limit it to Linux targets? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
There even is a Linux for PIC32 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGEnodeId=2519param=en546018 No idea if this is really useful ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote: On 30 May 2011, at 11:04, Bernd Mueller wrote: Jonas Maebe wrote: Isn't it easier to simply copy all compiled libraries to the target when they are compiled (just like compiled test programs are copied)? this second approach (which works well for me) copies the libraries when the are compiled. No need to expand the %needlibrary directive. Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 11:19, Bernd Mueller wrote: Jonas Maebe wrote: Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote: On 30 May 2011, at 11:19, Bernd Mueller wrote: Jonas Maebe wrote: Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... One could work with a default suffix .so and make this overridable by a new test option for example TEST_LIBRARY_SUFFIX. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 11:37, Bernd Mueller wrote: Jonas Maebe wrote: Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... One could work with a default suffix .so and make this overridable by a new test option for example TEST_LIBRARY_SUFFIX. Maybe better would be to hardcode .so for Linux and FreeBSD, and use dynlibs.SharedSuffix for all other targets. Most other targets use libc by default anyway (and if new non-libc targets are added or brought back to life, the ifdef can be adjusted in case the libc dependency would cause problems). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] test suite, problem with missing libraries on the target
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Bernd Mueller Envoyé : lundi 30 mai 2011 11:38 À : FPC developers' list Objet : Re: [fpc-devel] test suite, problem with missing libraries on the target Jonas Maebe wrote: On 30 May 2011, at 11:19, Bernd Mueller wrote: Jonas Maebe wrote: Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... One could work with a default suffix .so and make this overridable by a new test option for example TEST_LIBRARY_SUFFIX. Just add a LibExt constant to dotest.pp source with the same conditionals as for ExeExt, this should be enough. Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Am 30.05.2011 10:58, schrieb Marco van de Voort: So one would really need a cut down RTL for this. That's why we have the feature switches. Though I admit that it hard to use for the outer rtl and packages because it would require a lot of ifdef'ing thus polluting the sources. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Michael Schnell wrote: There even is a Linux for PIC32 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGEnodeId=2519param=en546018 No idea if this is really useful ? Although despite my enthusiasm for Linux, for hardware like that I find myself asking /why/. I think there's a fairly clear demarcation between projects/products which really do need a multitasking OS with networking etc., and those that quite simply need to fiddle a few inputs and outputs. The real problem is memory size: I remember a development job a few years ago that was basically well-specified and well-planned, but by the time the multitude of UI screens had been roughed out it was painfully obvious that it wouldn't fit in the targeted board's address space. Then it turned out that the compiler supported paging but that the linker offset the tables by one entry: I managed to fix the binaries but we /still/ ran out of space. That experience is, in part, why these days I am more interested in native than cross compilation. If you can get the basic functionality of a project running on a real computer to the point where you can gauge its performance and requirements, you're then in a far stronger position to specify the target hardware. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.4.4 - Delphi 7
30.05.2011 11:26, Martin Schreiber пишет: Interesting the big difference in data size. It is explainable: Delphi 7 puts good half of data into the code section (procedure-local data, string data, class vmt's are all there). FPC separates data from code completely. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.4.4 - Delphi 7
On Mon, May 30, 2011 at 03:26, Martin Schreiber mse00...@gmail.com wrote: Delphi 7: 303079 lines, 5.31 seconds, 2256556 bytes code, 820297 bytes data. FPC: 302251 lines compiled, 45.2 sec , 2257728 bytes code, 1688152 bytes data So Delphi is 9 times faster? -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.4.4 - Delphi 7
Am 30.05.2011 11:41, schrieb Alexander Klenin: On Mon, May 30, 2011 at 03:26, Martin Schreibermse00...@gmail.com wrote: Delphi 7: 303079 lines, 5.31 seconds, 2256556 bytes code, 820297 bytes data. FPC: 302251 lines compiled, 45.2 sec , 2257728 bytes code, 1688152 bytes data So Delphi is 9 times faster? Yes. But the distance has been diminished. 2.4.0 was more than 10 times slower. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Pierre Free Pascal wrote:
Just add a LibExt constant to dotest.pp source
with the same conditionals as for ExeExt, this should be enough.
const
ObjExt='o';
PPUExt='ppu';
{$ifdef UNIX}
ExeExt='';
LibExt='so';
{$else UNIX}
{$ifdef MACOS}
ExeExt='';
LibExt='so';
{$else MACOS}
ExeExt='exe';
LibExt='dll'; ???
{$endif MACOS}
{$endif UNIX}
but wouldn't that fail with crosscompiling? I am crosscompiling from a
Windows host.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.4.4 - Delphi 7
Martin Schreiber mse00...@gmail.com hat am 30. Mai 2011 um 09:26 geschrieben: Hi, I compiled MSEide with FPC 2.4.4 and Delphi 7 for comparison. Delphi 7: Borland Delphi Version 15.0 Copyright (c) 1983,2002 Borland Software Corporation [...] 303079 lines, 5.31 seconds, 2256556 bytes code, 820297 bytes data. Exe size: 3.2MB FPC: Free Pascal Compiler version 2.4.4 [2011/04/23] for i386 Copyright (c) 1993-2010 by Florian Klaempfl [...] 302251 lines compiled, 45.2 sec , 2257728 bytes code, 1688152 bytes data 187 warning(s) issued 315 note(s) issued Exe size: 3.87 MB Interesting the big difference in data size. Do you know, how much is compiling and how much is linking? Source: http://svn.berlios.de/viewvc/mseide-msegui/trunk/ Commandline Delphi: dcc32.exe -B -I..\..\lib\common\kernel -U..\..\lib\common\kernel -U..\..\lib\common\kernel\i386-win32 -U..\..\lib\common\graphics -U..\..\lib\common\image -U..\..\lib\common\widgets -U..\..\lib\common\ifi -U..\..\lib\common\printer -U..\..\lib\common\designutils -U..\..\lib\common\sysutils -U..\..\lib\common\editwidgets -U..\..\lib\common\dialogs -U..\..\lib\common\regcomponents -U..\..\lib\common\serialcomm -U..\..\lib\common\serialcomm -U..\..\lib\common\delphicompatibility -dmse_no_db -dmse_no_opengl -dmse_no_math mseide.pas Commandline FPC: ppc386.exe -O2 -CX -XX -Xs -B -Fi..\.. \lib\common\kernel -Fu..\..\lib\common\kernel -Fu..\..\lib\common\kernel\i386-win32 -Fu..\..\lib\common\graphics -Fu..\..\lib\common\image -Fu..\..\lib\common\widgets -Fu..\..\lib\common\ifi -Fu..\..\lib\common\printer -Fu..\..\lib\common\designutils -Fu..\..\lib\common\sysutils -Fu..\..\lib\common\editwidgets -Fu..\..\lib\common\dialogs -Fu..\..\lib\common\regcomponents -Fu..\..\lib\common\serialcomm -Fu..\..\lib\common\serialcomm Why are kernel and serialcomm given twice? -dmse_no_db -dmse_no_opengl -dmse_no_math -omseidefpc.exe mseide.pas All MSE *.o,*.ppu and *.dcu files deleted before compiling. System: win2000, AMD Athlon XP 3000+, 1GB RAM How to compile for Linux? Is there something like a fpmake.pp or Makefile? I can't find it in the README.txt. Mattias___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote: Maybe better would be to hardcode .so for Linux and FreeBSD, and use dynlibs.SharedSuffix for all other targets. maybe I am missing something, but wouldn't dynlibs.SharedSuffix retrieve the library suffix for the host? So, when I am crosscompiling from Windows, I would get the wrong suffix for the Linux target? Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 13:53, Bernd Mueller wrote: Jonas Maebe wrote: Maybe better would be to hardcode .so for Linux and FreeBSD, and use dynlibs.SharedSuffix for all other targets. maybe I am missing something, but wouldn't dynlibs.SharedSuffix retrieve the library suffix for the host? Yes, your right... Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.4.4 - Delphi 7
Am Montag 30 Mai 2011, 13:21:39 schrieb Mattias Gaertner: Do you know, how much is compiling and how much is linking? Linking is 3..4 seconds. Why are kernel and serialcomm given twice? kernel is once -Fi and once -Fu, second serialcomm is copy paste error. How to compile for Linux? Is there something like a fpmake.pp or Makefile? I can't find it in the README.txt. MSEide on linux can be compiled with ppc386 -Fulib/common/* -Fulib/common/kernel/i386-linux -Filib/common/kernel apps/ide/mseide.pas Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.4.4 - Delphi 7
Am 30.05.2011 13:21, schrieb Mattias Gaertner: Do you know, how much is compiling and how much is linking? Linking time is little: [10.205] Linking mseidefpc.exe [10.767] 310695 lines compiled, 10.8 sec , 2277216 bytes code, 1703496 bytes data [10.768] 148 warning(s) issued So approx. 0.56 sec ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.4.4 - Delphi 7
Martin Schreiber mse00...@gmail.com hat am 30. Mai 2011 um 13:59 geschrieben: Am Montag 30 Mai 2011, 13:21:39 schrieb Mattias Gaertner: Do you know, how much is compiling and how much is linking? Linking is 3..4 seconds. So, the Linker takes almost the time Delphi needs for everything? [...] How to compile for Linux? Is there something like a fpmake.pp or Makefile? I can't find it in the README.txt. MSEide on linux can be compiled with ppc386 -Fulib/common/* -Fulib/common/kernel/i386-linux -Filib/common/kernel apps/ide/mseide.pas Thanks. Can this be added to the README.txt? It's not the first time I searched this. Mattias___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.4.4 - Delphi 7
Am Montag 30 Mai 2011, 14:30:44 schrieb Mattias Gaertner: Martin Schreiber mse00...@gmail.com hat am 30. Mai 2011 um 13:59 geschrieben: Am Montag 30 Mai 2011, 13:21:39 schrieb Mattias Gaertner: Do you know, how much is compiling and how much is linking? Linking is 3..4 seconds. So, the Linker takes almost the time Delphi needs for everything? Yes. MSEide on linux can be compiled with ppc386 -Fulib/common/* -Fulib/common/kernel/i386-linux -Filib/common/kernel apps/ide/mseide.pas Thanks. Can this be added to the README.txt? It's not the first time I searched this. Done, trunk 4587. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
