Hello all,

I know this has been brought up from time to time, but the more I use NetBeans and other big editors.. The more I miss the fact that it isolates you from being in their pool of source code to build whenever you add a component, etc. Having a binary-only Lazarus would mean an entire overhaul of a binary package system. What would be amazing to see actually, is FPC being able to compile into a universal object (which supports the basic byte code, and sections which will only be used when converting to a certain architecture if necessary.. Like SSE optimized code), then being able to convert into native code at destination machine. Something like Chrome's Native Client does now, which compiles the code into a universal op-code base, and converts it to native at their servers..

Having this universal binary package system, means we can distribute one package, and have it convert on the destination machine. Means we don't really have to do tricks when distributing your unit when you don't want to distribute the source code (ie. Commercial Packages).

Any thoughts?

- Den

Any thoughts?

Dream on. FPC is a native compiler and someone would need to implement that proposed bytecode and maintain it.
Even once we support LLVM we wouldn't drop any of our native code generators and even if we did LLVM simply does not support all those platforms that we support (e.g. m68k as CPU or OS/2 as OS). Additionally there'd still be the platform differences which would stop you from distributing one set of blobs: on Windows you need to use the WinAPI, on Linux C API and X11 and on Mac OS X C API and Carbon/Cocoa. If you'd encode all this currently handled by ifdefs and different units into those blobs you could simply distribute the source as well.

Please note that support for binary packages (aka dynamic packages) will come. But they will depend on a target just as compiled units currently do already.

Regards,
Sven

Hi Sven!

I suppose you can just have Build Servers and build all major OS/Architectures. The platform differences could be solved by an additional 'target dependent' package. But I suppose with the Dynamic Packages, we could just bundle the different architectures in the one Package File, and have a header which states which architectures it has in it, or even in the file listings in the Package in a certain directory. When that time comes, fun stuff will happen, as the Lazarus could be made to auto-update and such for the normal folk. (I know mine is practically auto-update.. Update VCS and then rebuild :p ) and then there's FPCUP .. But just thought something like Netbeans.

I was also thinking, when I have time, I wanted to make an API for Lazarus which devs could make their own VCS and have it display in the IDE, to make it more modern.. But I have a project due very very soon, so I can't really work on it yet. :p

Anyway, thanks for the reply Sven! I'll have that bug fix tested as soon as I get a moment.
Take care!

- Den

Den wrote

I know this has been brought up from time to time, but the more I use NetBeans and other big editors.. The more I miss the fact that it isolates you from being in their pool of source code to build whenever you add a component, etc.

Aside from the fact that it requires a bunch of tech that is not there and costly to develop (even if you wanted to), it still doesn't solve the recompile on installation of a package (specially if they contain code, like designtime editors).

Then there is of course the problem that Java solves by simply not being multiplatform at all. (but run inside a Java world with the real machine at arms length)

Such universal code system would still fall down at the first OS specific ifdef. (since code for only the selected platform would be compiled into bytecode ).

Having this universal binary package system, means we can distribute one package, and have it convert on the destination machine.

Yes. And then you would have what exactly? Still only a binary package compiled at the host binary, the link to the IDE is still not done.

Means we don't really have to do tricks when distributing your unit when you don't want to distribute the source code (ie. Commercial Packages).

Good to remind, that is also the problem, since like most bytecodes the intermediate format would be easily decompilable.