Re: [fpc-devel] Small virtual machine to cross compile FPC
Paul Breneman schrieb: I think 100Mb is a bit small. You'll need cross-binutils, X, cross-dev libs and whatnot. 650Mb would be feasable, I guess. Thanks for that info, but couldn't most of that be download into the VM *after* it is running? Seems to me I'd like the *smallest* VM and then have a way to load things into that standard PC. But maybe I'm thinking wrongly? If so please help me get it right. I don't understand why the VM *size* should matter - unless it's 30GB for current Windows versions. My goal would be a *simple* OS, easy to configure and manage, and then install into it whatever is required. Why download and configure all the required tools whenever the VM is run? This may take half an day, to get the VM up for cross-development, and the downloads end up on the virtual disk as well. For cross-development I'd install a network of dedicated target VMs, one of which can host the project files, and then build the project in every target VM. This would allow for parallel builds, and every created executable can be tested immediately on its platform - also in parallel for comparison of the GUI and operation. With a single development VM you would need another VM or emulator to perform the final checks, for every single target platform. I've looked at (or tried) laz4android and fpcup. Seems that such an approach would work much better on a standard PC? Virtual machines work well on the same hardware (CPU), but for other targets (ARM instead of x86) an emulator is required. Wikipedia says that a LiveCD and AndroVM with Android for x86 is available, where it might be possible to develop Android applications somewhat natively on an x86 machine. But finally an emulator or physical device is required, where the cross-compiled programs can run on their target CPU, using the according libraries (RTL, VCL... for ARM). Please don't ask me about Adroid, my experience is limited to FPC/Lazarus development on various Windows and Linux VMs, and I never tried to cross-compile myself. Why cross-compile when I cannot check the results? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Small virtual machine to cross compile FPC
On 11/01/2014 03:13 AM, Hans-Peter Diettrich wrote: Paul Breneman schrieb: I think 100Mb is a bit small. You'll need cross-binutils, X, cross-dev libs and whatnot. 650Mb would be feasable, I guess. Thanks for that info, but couldn't most of that be download into the VM *after* it is running? Seems to me I'd like the *smallest* VM and then have a way to load things into that standard PC. But maybe I'm thinking wrongly? If so please help me get it right. I don't understand why the VM *size* should matter - unless it's 30GB for current Windows versions. My goal would be a *simple* OS, easy to configure and manage, and then install into it whatever is required. Why download and configure all the required tools whenever the VM is run? This may take half an day, to get the VM up for cross-development, and the downloads end up on the virtual disk as well. For cross-development I'd install a network of dedicated target VMs, one of which can host the project files, and then build the project in every target VM. This would allow for parallel builds, and every created executable can be tested immediately on its platform - also in parallel for comparison of the GUI and operation. With a single development VM you would need another VM or emulator to perform the final checks, for every single target platform. I've looked at (or tried) laz4android and fpcup. Seems that such an approach would work much better on a standard PC? Virtual machines work well on the same hardware (CPU), but for other targets (ARM instead of x86) an emulator is required. Wikipedia says that a LiveCD and AndroVM with Android for x86 is available, where it might be possible to develop Android applications somewhat natively on an x86 machine. But finally an emulator or physical device is required, where the cross-compiled programs can run on their target CPU, using the according libraries (RTL, VCL... for ARM). Please don't ask me about Adroid, my experience is limited to FPC/Lazarus development on various Windows and Linux VMs, and I never tried to cross-compile myself. Why cross-compile when I cannot check the results? DoDi Thanks DoDi for all of your feedback. You are correct that the size of the VM doesn't matter much. I was thinking of leaving out things that change often but maybe that is really only the source code. Building FPC is complex and mobile seems even more complex. So an easy and simple way to see things work might be a valuable first step even though the developer should move over to a better development environment ASAP. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 31.10.2014 15:31, Sven Barth wrote: Am 30.10.2014 11:34 schrieb hinsta...@yandex.ru mailto:hinsta...@yandex.ru hinsta...@yandex.ru mailto:hinsta...@yandex.ru: okay sorry for spamming the mailing list So basically the other problem I reported before (generic + refcounted does not work) turns out to be something different: Declaring variable of refcounted type in a different unit makes the compiler stop with error 2014092205 Assume in unit Aunit I have type TSomething = class refcounted end; Then I declare a procedure: procedure Run; var server: TServer; begin server := TServer.Create; end; When procedure Run is declared in Aunit, it compiles. However, if I declare procedure Run in some other unit, say Bunit, then the compiler stops on line with assignment := That simplifies things. Thanks for the update :) I have now fixed the problem, so you can retest, if you want. :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 30.10.2014 11:00, hinsta...@yandex.ru wrote:
Even if line numbers are slightly different, you can easily find the
place where exception is raised: in jitforms.pp: in procedure
GetVMTVirtualMethodOffset: raise
Exception.Create('GetVMTVirtualMethodOffset Parent Virtual Method not
found');
I leave the decision if this worth investigating or not to you as I am
myself not sure. Not that I could possibly force someone to look into it
even if I insisted.
This problem should now be fixed as well. I forgot to adjust a VMT
related constant that is (thankfully) used by that LCL code. ;)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
