This is related to bug 0021580: Feature request: Robust IDE cross-compiling.

With Lazarus 1.0 being closer than ever, and with the availability of different Linux scripts to compile FPC from source (including cross compilation), maybe the time has come to have an automated installer that does all that, including the compilation of the cross binutils.

The complement for Lazarus would be the ability to import/export the default project options with build modes. My default build modes include Default, Linux/i386, Win32/i386, Linux/arm, and WinCE/arm.

The 1st base question that comes to mind is: What is the optimal folder structure to contain FPC with different versions, lazarus, the cross binutils, and all related sources?

Stephano

patspiper hat am 27. M?rz 2012 um 17:17 geschrieben:

This is related to bug 0021580: Feature request: Robust IDE

cross-compiling.

That is one approach.
Another is to use VMs.
VMs are nowadays very easy to setup and they run almost as fast (sometimes even faster) as the host system.
Installing/Upgrading all the required libs in a VM is much simpler than setting up these libs cross compiled.

Maybe someone wants to setup VM image for public download for his favorite distribution with preinstalled Lazarus and other common development tools.

Lazarus projects and packages are made for cross platforms. So you can simply copy them or use VCS.

The complement for Lazarus would be the ability to import/export the default project options with build modes.

The default project options (compiler options with build modes) are stored in ~/.lazarus/projectoptions.xml

My default build modes include Default, Linux/i386, Win32/i386,

Linux/arm, and WinCE/arm.

The 1st base question that comes to mind is: What is the optimal folder structure to contain FPC with different versions, lazarus, the cross binutils, and all related sources?

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120327/fd2f2bd5/attachment.html>

Agreed with Mattias.

I would strongly recommend using VMs as well so that the level of complexity/maintenance decreases.
Linux to Windows can be done, but the other way round is difficult.

Why invest time and effort in chasing a moving target (new libraries) when you need to test on the target environment anyway?

I'd rather have some more people fixes ;)

Regards,
Reinier

Not necessarily (assuming you have the right dependencies already installed). I use 3 scripts that rely on sources (exported from SVN or a released FPC, plus a tar for binutils). Although not perfect, these scripts:

- Make and install FPC for the host platform (given an FPC version number), based on a starting compiler or an installed FPC
- Make and install the cross binutils for the desired target platform
- Make and install cross FPC for the desired target platform

Finally, the Lazarus launcher script exports the required paths (given the FPC version number) and executes startlazarus.

As for Lazarus itself, my default build modes allow me to switch target platforms with minimal effort (using the build modes tool button)

The above makes it possible to use FPC SVN and stable releases very efficiently for normal as well as cross compiling.

Oh..I meant the default project build modes only...my bad!

Stephano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120327/d1cda52f/attachment.html>

I'd introduce some words of caution here, for a number of reasons.

a) Depending on the person who's put it together, the requirements and architecture of an OS running in a VM can vary enormously. As a particular example, Debian set up for some guest processors requires a graphical (xterm) console, but for others can make do with ssh or with ) Performance can vary wildly. That is particularly the case where the guest is x86, since Qemu- on which a number of other VM schemes are based- increasingly assumes that hardware virtualisation is available (i.e. an older Linux kernel with kqemu, or newish hardware and kernel with KVM).

c) Library availability etc. is determined by whoever put the guest OS together.

It's probably not safe to assume that a developer will be able to build natively (i.e. if he wants to compile for an ARM target that he has an ARM system) since PC-type boards based on ARM, MIPS and so on are comparatively scarce and expensive (this might change when the Raspberry Pi is finally available, at least for ARM).

It's only slightly more safe to assume that a developer will be able to get an OS of a suitable version working in a VM.

So while native and VM-based systems are certainly significant, I think it would be unwise to write off cross-build tools out of hand.

Then take a look at CodeTyphon - it is exactly that. A repackage FPC and Lazarus with cross-compiling support to many targets, and plenty of extra components and even some custom CodeTyphon component installed.

http://www.pilotlogic.com/sitejoom/

2012/3/27 Mattias Gaertner <nc-gaertnma at ....>:

Maybe someone wants to setup VM image for public download for his favorite distribution with preinstalled Lazarus and other common development tools.

Microsoft and Apple would love you for pirating and distributing their OS's illegally. :-) What you suggest will only work with Linux as the VM operating system. Maybe ReactOS could be used for the Windows VM though. The last time I tested FPC+fpGUI on ReactOS, I was quite impressed.

<time for a blatant plug then>
For anybody who wants to jump in: help with the fpcup project is much appreciated.
https://bitbucket.org/reiniero/fpcup/

It allows you to build a complete up to date FPC/Lazarus environment from scratch.
Currently it only features a win32=>win64 cross compiler, but it has a modular architecture that allows you to write a cross compilation plug in. IIRC, this unit should basically:
- make sure your target binutils are there (either check them or download them; HTTP, FTP and svn downloads already supported)
- make sure your target libraries are there (same thing here)

Then some instructions in the included state machine need to be added so fpcup knows the cross compiler is available.

Currently, fpcup has been compiled on win32, win64, linux32, linux64, OSX Intel.

Any units welcome!

Regards,
Reinier

I wrote "his favorite distribution".
That excludes Windows and iOS/OSX for me. ;)

What you suggest will only work with Linux as the VM operating system. Maybe ReactOS could be used for the Windows VM though. The last time I tested FPC+fpGUI on ReactOS, I was quite impressed.

Mattias

Le 27/03/2012 17:17, patspiper a ?crit :

Absolutely :-*
I've tried a few days ago to have a crosscompiler on Linux for i386 and x86_64: I failed to compile for i386, Lazarus installed as x86_64 native. Something was still missing.

The complement for Lazarus would be the ability to import/export the default project options with build modes. My default build modes include Default, Linux/i386, Win32/i386, Linux/arm, and WinCE/arm.

Same for me. It would be delightful to have a script, or maybe better a package installer (debian .deb or rpm) for each supported cross-compilation architecture.

The current wiki pages do not give enough information about the installation process of another target into a functional Lazarus installation. On another hand I think it is more a task for the FPC development team than Lazarus one. But still, as they work hand in hand (I guess), I think it is a Lazarus task as well. Although I'm not a submarine ( 8-) ) developer I can give some of my time to help in this process.

Antonio.

Great.
Lazarus and FPC share the same wiki.

Mattias

Too slow. Tried it for FPC release building, but checkout, export + build takes >40 mins (Core2 6600. Virtualbox with hardware virtualization enabled)

I ended up stacking relative cheap Pentium D boxes (HP office machines, typically dc7600sff 2.8GHz, 1GB, 80GB hdd for Eur 55-65, inaudible when idle). Nobody wants PIV's and derivatives anymore, but the later Pentium D series have 64-bit capability, DDR2 and sata, so are relatively cheap to maintain if something breaks down, and the default config is enough for FPC release building.

Cheap usb KVM, first generation TFT monitor. Whole stack under a table, relative low on space.

(all el cheapo since typically only used during release time)

Disclaimer: wife-acceptancy-factor not an issue here.

VMs are nowadays very easy to setup and they run almost as fast (sometimes even faster) as the host system.

Only hypervisors run fast. Anything heterogenous with an image as storage is quite slow. Slower than 5 year old HW from the dumpster.

Marco van de Voort hat am 28. M?rz 2012 um 17:10
geschrieben:

enabled)

Here it takes only a few minutes.

> I ended up stacking relative cheap Pentium D boxes (HP office machines, typically dc7600sff 2.8GHz, 1GB, 80GB hdd for Eur 55-65, inaudible when idle). Nobody wants PIV's and derivatives anymore, but the later Pentium

D

series have 64-bit capability, DDR2 and sata, so are relatively cheap to maintain if something breaks down, and the default config is enough for

FPC

(sometimes

I was suprised that some of my virtualbox images compiled Lazarus faster than my host machine.

I didn't tune anything, so I can't give any advice. Maybe I was just lucky.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120328/19365482/attachment.html>

Mattias Gaertner wrote

> takes >40 mins (Core2 6600. Virtualbox with hardware virtualization enabled) Here it takes only a few minutes.

With what on what? How is storage organized?

I mostly tried under Windows, but before virtualbox I used VMWare player, and the picture was the same under Linux.

Marco van de Voort hat am 28. M?rz 2012 um 18:15
geschrieben:

I simply installed an ubuntu 32 bit in a virtual box. Gave it 2GB mem, 100GB dynamic growing disk. The rest default.

AMD Phenom(tm) II X4 965 Processor

The I installed lazarus, which installed everything needed. Then I downloaded fpc and laz svn. This takes most of the time. Then I compiled them. Compiling takes a few minutes. Building debs is a bit faster than on the host system, because virtualbox apparently uses a very lazy write.

How is storage organized?> I mostly tried under Windows, but before virtualbox I used VMWare player, and the picture was the same under Linux.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120328/aae59829/attachment.html>

2012/3/28 Mattias Gaertner <nc-gaertnma at ...:

Here it takes only a few minutes.

+1

I see no visible difference in speed between my native host system, and the VM sessions I run. I have a lot of VM sessions for our product testing and building, and yes, I do FPC building on them too.

I've got a first generation Intel Quad Core 2.4Ghz system with 4GB RAM and a SATA2 harddrive. My main (host) OS is Ubuntu Linux 10.04 64-bit. I use VirtualBox 4.x. We have various VM sessions here covering all the Windows versions from Win95 thru Windows7. We also have Ubuntu 8.04, 9.10 and 10.04. It's a mixed bag of 32bit and 64bit OSes. I normally give each VM 1GB of memory, but for older OSes like Win2000 I only give 512MB. Out of all the Windows VM's, I use Win2000 for Windows development work, running Visual Studio (old version), VB6, Delphi 7, Lazarus etc. Performance on any of these VM's are no slower than running them on "real hardware", and they don't tend to slow down my host system either (thanks to the quad core I think).

For a while I had a separate SCSI hard drive to host the VM hard drive images, but that drive was too noisy, so I removed it from my system.

I used to run VMWare Workstation, but I found that much slower than VirtualBox, and a lot more problematic to install under Linux. So now we only use VirtualBox.

IMO the most critical point is the memory configuration. VMs tend to use fixed memory, i.e. the virtual RAM is mapped to persistent physical RAM, reducing the available RAM on the host machine. One can play around with different amounts of virtual memory, starting with 512MB, to find out the best configuration for the host machine.

DoDi

Hans-Peter Diettrich wrote

IMO the most critical point is the memory configuration. VMs tend to use

I think so too. I never starve my host OS from memory. I have 4GB installed in my system. My host OS (Ubuntu 10.04) uses on average 45% of that for day-to-day us, so that leaves 2GB for VM sessions (guest OSes). As I mentioned, I normally allocate 512MB to 1GB to a guest OS session, so that still leaves 1GB spare for my host OS.

I also normally only allocate one CPU core for a VM session to access, again leaving 3 cores for the host OS. I also never limit the VM session's CPU usage (called 'Execution Cap' in VirtualBox) - I leave that at 100% because it only has access to one of my CPU cores anyway.

Obviously it is also vital to install the VirtualBox Guest Additions to improve guest OS performance. This makes a huge difference too.

2012/3/29 Graeme Geldenhuys :

Obviously it is also vital to install the VirtualBox Guest Additions to improve guest OS performance. This makes a huge difference too.

3D video drivers are very bad on virtual OS, so is not possible to develop for 3D graphics on VirtualBox, VMWare, etc.

Regards,
Kjow

Right, but why should somebody want to *develop* such applications for a different platform, instead for the platform of his physical machine? Herefore, and for other time-critical applications, a dual boot of the target OS is the better choice.

DoDi

What if you need to develop for an OS that your platform does not support? E.g. (though not exactly fitting in context) developing an application for an older Windows version which does not boot on your super modern computer. Or developing for e.g. Mac OS X without having a Mac (Note: let's not talk about eventual problems regarding legalitiy here). Or writing a graphical application for an embedded device. Also - in my opinion - dual booting breaks the workflow. I want to mainly work on one machine and maybe have others running in other windows (be it a VM or a RDP or VNC session).

VMs are also important not for time critical stuff, but for low level stuff. E.g. I would not have wanted to develop the Native NT port of FPC without having a Windows OS (in my case ReactOS) running in a VM. ^^

Regards,
Sven

2012/3/29 Hans-Peter Diettrich :

Android or iOS for example, but any cross-platform project could be much more easy (instead reboot every time, just build into VM)

Regards,
Kjow

Please check your use cases for the need of hardware acceleration, like for 3D graphics. And suggest better development environments. E.g. for embedded devices you may be better off with an dedicated emulator, instead of a VM.

I never doubted that VMs are usesul - I use them myself, and know about their limitations.

DoDi