[Pkg-pascal-devel] Lazarus packaging model
Abou Al Montacir
abou.almontacir at sfr.fr
Tue May 6 20:14:14 UTC 2014
On Tue, 2014-05-06 at 21:23 +0200, Paul Gevers wrote:
> On 06-05-14 21:12, Abou Al Montacir wrote:
> >> As Promised a few weeks ago, I've drawn this graph as a starting point
> >> to some documentation work about LCL SW model architecture and its
> >> inherent packaging.
>
> Sorry for not responding to your drawing earlier. I must confess that
> although it seems to make the upstream architecture clear, if fails for
> me to explain what this means for packaging purposes.
I've tried to reproduce the upstream architecture in the packages.
especially that upstream are adding more and more components, so that
the amount of libraries are more and more increasing. This should be
handled in a scalable way.
> > Please note that is could be worth to note that lcl-units are kind of
> > libraries while Lazarus is kind of program. Theoretically, one should be
> > able to use different LCL versions with the latest Lazarus IDE. It could
> > be compared gcc and libc orf fpc and its RTL.
> >
> > In this logic, the lcl-${widget set} are just pascal bindings over c
> > bindings
>
> I was wondering, does the current upstream way of working scale? I mean,
> should these libraries have a "soname bump" every time the compiler
> changes?
This is a kind of soname, but you can not postfix the unit files
> I.e. the units depend on the version of fpc, that is something
> that is not true in the c world.
In C yes, but in C++ that happens. And please compare ppu file too
compiled headers rather than to object files. BTW fpc generates
both .ppu and .o files.
> This makes it very hard to distribute
> multiple source packages with units (like we see now with
> castle-game-engine). It means that ALL unit packages must migrate
> together from unstable to testing, making this a pain if more unit
> packages are packaged. In the c world only the API of the library itself
> matters.
As I told to you, there is -Ur flag:
-Ur Generate release unit files (never automatically recompiled)
Maybe we need to investigate more, but I think if there is no change in
the unit generator code in the compiler, there should be way to
workaround this. However if a unit was compiled with a given version of
rtl and that the interface of that rtl (API) changed, then you need to
recompile anyway.
> Paul (who is neither a c expert nor a library expert)
Cheers,
Abou Al Montacir,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20140506/10ddfd34/attachment.sig>
More information about the Pkg-pascal-devel
mailing list