If you meant having many libs of different version exist
side-by-side,
.NET runtime supports it, but Win32 itself doesn't
Most unixes also have it. The point is that it kind of
defeats the purpose.
Having 20+ libraries called fpcrtl-xyz.dll (or
fpcrtl.so.x.y.z on unixes) defeats the
That this requires a strict versioning schedule, is part of the deal.
Borland's packages are also incompatible between released versions.
Which is very bad practice for a commercial IDE (makes third-party
commercial components support only some versions of Delphi [had suggested to
Borland to
You can't, for Lazarus. You need the classes, that's what you
need the plugins for in the first place: to install
additional components on the component palette. They must
descend from the TComponent which is in the IDE.
There is no way around it.
If you had an immutable Icomponent
So, a component that you place in the component palette implements
some kind of palette interface, providing the IDE with the
communications it needs to work with the component.
Nice idea, but I think you'll end up creating a set of
interfaces which describes completely
Op Fri, 9 Feb 2007, schreef George Birbilis:
Speaking of namespaces, Borland added concept (to support .NET) in latest
Delphis I think, has FPC done similar yet? Could help in this case
It is on the not to be supported list (unless we have to decide to be
Delphi .NET compatible). It won't
Speaking of namespaces, Borland added concept (to support .NET) in latest
Delphis I think, has FPC done similar yet? Could help in this case
We already have units, with etc? Maybe you want internal units ?
___
fpc-devel maillist -
On Wed, 7 Feb 2007 21:56:54 +0100
Jonas Maebe [EMAIL PROTECTED] wrote:
On 07 Feb 2007, at 21:45, Mattias Gaertner wrote:
In principle you should be able to do it with make shared in the
respective directories. But I would strongly recommend against
doing that, since the interface is by
Op Thu, 8 Feb 2007, schreef Mattias Gaertner:
Plugins. For example installing a design time package.
Contrary to normal apps an IDE has the advantage to recompile
if needed. So Lazarus has only a subset of the normal dyn lib problems.
But I know, that as soon as the IDE can load packages as
On Thu, 8 Feb 2007, Daniël Mantione wrote:
Op Thu, 8 Feb 2007, schreef Mattias Gaertner:
Plugins. For example installing a design time package.
Contrary to normal apps an IDE has the advantage to recompile
if needed. So Lazarus has only a subset of the normal dyn lib problems.
Op Thu, 8 Feb 2007, schreef Michael Van Canneyt:
Design a plugin binary API, dynload the plugin. It is not necessary that
the RTL is shared for this purpose (allthough it could reduce the size).
This way you only have to keep the plugin API backwards compatible,
and could allow
On Thu, 8 Feb 2007, Daniël Mantione wrote:
Op Thu, 8 Feb 2007, schreef Michael Van Canneyt:
Design a plugin binary API, dynload the plugin. It is not necessary that
the RTL is shared for this purpose (allthough it could reduce the size).
This way you only have to keep the
Op Thu, 8 Feb 2007, schreef Michael Van Canneyt:
Secondly, there are serious problems with this approach which make it
unusable
for an IDE like Lazarus.
Assume I get a component instance from the plugin (MyObject), then
extremely
simple and basic statements like
On Thu, 8 Feb 2007, Dani?l Mantione wrote:
and LCL, which seems next to impossible to me.
Why ? Borland does it.
Borland releases 13 versions in say 12 years, and no inbetween.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Michael Van Canneyt wrote:
On Thu, 8 Feb 2007, George Birbilis wrote:
We need a version system.
That's not something we need, but which most OS'es need
(and don't
provide, except for hacks like symlinks or different filenames).
Moreover, it doesn't really solve much unless you like having
Marco van de Voort wrote:
On Thu, 8 Feb 2007, Dani?l Mantione wrote:
and LCL, which seems next to impossible to me.
Why ? Borland does it.
Borland releases 13 versions in say 12 years, and no inbetween.
If Lazarus releases libs for every official FPC release wouldn't that be
almost the
On Thu, 8 Feb 2007, Marc Weustink wrote:
Marco van de Voort wrote:
On Thu, 8 Feb 2007, Dani?l Mantione wrote:
and LCL, which seems next to impossible to me.
Why ? Borland does it.
Borland releases 13 versions in say 12 years, and no inbetween.
If Lazarus releases libs for
On Thu, 8 Feb 2007, Bogusław Brandys wrote:
Michael Van Canneyt wrote:
On Thu, 8 Feb 2007, George Birbilis wrote:
We need a version system.
That's not something we need, but which most OS'es need
(and don't
provide, except for hacks like symlinks or different
On 07 Feb 2007, at 19:51, Mattias Gaertner wrote:
How can I create dynamic libs of the RTL and FCL units under Linux?
In principle you should be able to do it with make shared in the
respective directories. But I would strongly recommend against doing
that, since the interface is by no
On Wed, 7 Feb 2007 20:00:20 +0100
Jonas Maebe [EMAIL PROTECTED] wrote:
On 07 Feb 2007, at 19:51, Mattias Gaertner wrote:
How can I create dynamic libs of the RTL and FCL units under Linux?
In principle you should be able to do it with make shared in the
respective directories. But I
On 07 Feb 2007, at 21:45, Mattias Gaertner wrote:
In principle you should be able to do it with make shared in the
respective directories. But I would strongly recommend against doing
that, since the interface is by no means stable and consequently
programs compiled against both newer and
We need a version system.
That's not something we need, but which most OS'es need
(and don't provide, except for hacks like symlinks or
different filenames).
Moreover, it doesn't really solve much unless you like having
20 different versions of the same shared library on your
We need a version system.
That's not something we need, but which most OS'es need
(and don't
provide, except for hacks like symlinks or different filenames).
Moreover, it doesn't really solve much unless you like having 20
different versions of the same shared library on your
On Thu, 8 Feb 2007, George Birbilis wrote:
We need a version system.
That's not something we need, but which most OS'es need
(and don't
provide, except for hacks like symlinks or different filenames).
Moreover, it doesn't really solve much unless you like having 20
23 matches
Mail list logo
