Sign in Join

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

Mailing lists / fpc-devel / 2010-12

Suggestion: decomposition exe to dll

3 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

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

Andrzej

If I install component package I must rebuild all Lazarus. It is time-consuming. Would be better to have separate libraries like BPL in Delphi. Applications compiled with FreePascal even stripped are big (minimal with gui has 1.6 MB, with Synedit is about 2 MB). If it posssible to separate fcl,lcl libraries from rest exe code? If we want to distribute minimal exe, we not have to distribute libraries. This involves problem: code must works not only with library version strict to code, but with each higher. How solve it: Libraries can't change too much, not remove public methods and change parameters, only add method. It needs to handle with calls to object field when ancestor object has added field. This requires intermediate array or late linking calls to field or virtual methods?

Reply by email

Jonas Maebe
to Andrzej
Andrzej wrote
If I install component package I must rebuild all Lazarus. It is time-consuming. Would be better to have separate libraries like BPL in Delphi.

Some people are working on packages support, but it probably will not be ready in the near future

This involves problem: code must works not only with library version strict to code, but with each higher. How solve it: Libraries can't change too much, not remove public methods and change parameters, only add method.

This is indeed a problem. In practice, it's unlikely that this will be possible because there is no grand vision or overarching plan of how the RTL should be. It is developed on an ad hoc basis, and e.g. compiler-specific helpers are added/removed/renamed as the compiler itself changes.

So programs compiled by a particular FPC release will probably only ever be guaranteed to work with the "BPL" compiled from that same release. They will have to be versioned just like any other library.

Jonas

Reply by email

Marco van de Voort
to Jonas Maebe

In our previous episode, Jonas Maebe said:

Show quoted text 9 lines
> This involves problem: code must works not only with library version strict to code, but with each higher. How solve it: > Libraries can't change too much, not remove public methods and change parameters, only add method. This is indeed a problem. In practice, it's unlikely that this will be possible because there is no grand vision or overarching plan of how the RTL should be. It is developed on an ad hoc basis, and e.g. compiler-specific helpers are added/removed/renamed as the compiler itself changes.

Should this hamper development? Or should this be on the principle of a long living release branch?

Even Delphi breaks compatibility every year (and we are not that different with on avg 9 month release cycle lately)

Reply by email