Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2014-09

Binary Package System Discussion?

4 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Den

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

Reply by email

Mark Morgan Lloyd
Den wrote 14 lines
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..

Doesn't NaCl use LLVM?

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).
Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Den
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote 18 lines
Den wrote: > 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.. Doesn't NaCl use LLVM?

I think so yep? So I guess I should say "Like LLVM", but the way Chrome uses it to it's High Level Portal Executable or "pexe" format. If we had a code generator that outputted the IR language (instead of Assembly, as an option), we could use that to compile on any architecture* with LLVM. But then you'd need LLVM external tools.

Show quoted text 6 lines
> 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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140906/f6d7da60/attachment-0001.html>

Reply by email

Marco van de Voort
to Den: I know this has been brought up from time to time, but the more I use NetBeans and other…
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.
Show quoted text 9 lines
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..

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.

Reply by email