Re: Splitting the cairo backends up so they can be in separate packages?
Stuart Axon <[email protected]> Mon, 9 Dec 2019 19:56:22 +0000 (UTC)
| Newsgroups | gmane.comp.lib.cairo |
|---|---|
| Message-ID | <[email protected]> |
--===============2061451609==
Content-Type: multipart/alternative;
boundary="----=_Part_5847661_1282761595.1575921382601"
------=_Part_5847661_1282761595.1575921382601
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'll see if I can build one libcairo under a different name with one backen=
d, then go from there :)
I've got some ideas of varying sanity for how libcairo.so might work, maint=
aining backwards compatibility, but have to see if I get far enough along t=
o test them first.
S++=20
On Saturday, December 7, 2019, 8:07:06 AM GMT, Uli Schlachter <psychon@=
znc.in> wrote: =20
=20
Hi,
On 06.12.19 18:13, Stuart Axon wrote:
[...]>=C2=A0 I was wondering how hard it would be to split up cairo by
backend, would it be feasible to build it so there instead of
libcairo.so, there is libcairo-${backend}.so, e.g.
> libcairo-image.so
> libcairo-xcb.solibcairo-pdf.so
> etc..?
something like this was already proposed before, but I do not remember
the details. The proposal "back then" was to have one libcairo.so
containing "cairo core" and the backends in extra files. The problem
with this idea is the interface between libcairo.so and the backends: It
would need to be public. And thus, it would need to be (semi-)stable.
This idea basically turns all of cairo's internals into public ABI (and
perhaps even public API, but that is avoidable).
Alternatively, you could compile cairo with just the image backend and
call this one libcairo-image.so etc. This would mean that the different
cairo backends are not interoperable, I think.
> Any idea what I would need to change to make it build like this ?
If you want to go down that route, you would have to change the build
system to note give all symbols hidden visibility by default and make
the "slim_hidden_def" not do whatever it does. Afterwards, I think you
could just split the source into multiple .so files as you prefer.
Cheers,
Uli
--=20
- He wants the impossible...!
- That's the short definition of 'captain'.
=20
------=_Part_5847661_1282761595.1575921382601
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"ydpe6707a5byahoo-style-wrap" style=
=3D"font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 1=
3px;"><div dir=3D"ltr" data-setdir=3D"false"><div dir=3D"ltr" data-setdir=
=3D"false">I'll see if I can build one libcairo under a different name with=
one backend, then go from there :)</div><div dir=3D"ltr" data-setdir=3D"fa=
lse"><br></div><div dir=3D"ltr" data-setdir=3D"false">I've got some ideas o=
f varying sanity for how libcairo.so might work, maintaining backwards comp=
atibility, but have to see if I get far enough along to test them first.<br=
></div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div class=3D"ydpe6=
707a5bsignature">S++</div></div>
<div><br></div><div><br></div>
=20
</div><div id=3D"yahoo_quoted_6395250012" class=3D"yahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
=20
<div>
On Saturday, December 7, 2019, 8:07:06 AM GMT, Uli Schl=
achter <[email protected]> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir=3D"ltr">Hi,<br clear=3D"none"><br clear=3D"no=
ne">On 06.12.19 18:13, Stuart Axon wrote:<br clear=3D"none">[...]> =
I was wondering how hard it would be to split up cairo by<br clear=3D"none=
">backend, would it be feasible to build it so there instead of<br clear=3D=
"none">libcairo.so, there is libcairo-${backend}.so, e.g.<br clear=3D"none"=
>> libcairo-image.so<br clear=3D"none">> libcairo-xcb.solibcairo-pdf.=
so<br clear=3D"none">> etc..?<br clear=3D"none"><br clear=3D"none">somet=
hing like this was already proposed before, but I do not remember<br clear=
=3D"none">the details. The proposal "back then" was to have one libcairo.so=
<br clear=3D"none">containing "cairo core" and the backends in extra files.=
The problem<br clear=3D"none">with this idea is the interface between libc=
airo.so and the backends: It<br clear=3D"none">would need to be public. And=
thus, it would need to be (semi-)stable.<br clear=3D"none"><br clear=3D"no=
ne">This idea basically turns all of cairo's internals into public ABI (and=
<br clear=3D"none">perhaps even public API, but that is avoidable).<br clea=
r=3D"none"><br clear=3D"none"><br clear=3D"none">Alternatively, you could c=
ompile cairo with just the image backend and<br clear=3D"none">call this on=
e libcairo-image.so etc. This would mean that the different<br clear=3D"non=
e">cairo backends are not interoperable, I think.<div class=3D"yqt522129002=
0" id=3D"yqtfd25676"><br clear=3D"none"><br clear=3D"none">> Any idea wh=
at I would need to change to make it build like this ?</div><br clear=3D"no=
ne"><br clear=3D"none">If you want to go down that route, you would have to=
change the build<br clear=3D"none">system to note give all symbols hidden =
visibility by default and make<br clear=3D"none">the "slim_hidden_def" not =
do whatever it does. Afterwards, I think you<br clear=3D"none">could just s=
plit the source into multiple .so files as you prefer.<br clear=3D"none"><b=
r clear=3D"none">Cheers,<br clear=3D"none">Uli<br clear=3D"none">-- <br cle=
ar=3D"none">- He wants the impossible...!<br clear=3D"none">- That's the sh=
ort definition of 'captain'.<div class=3D"yqt5221290020" id=3D"yqtfd70995">=
<br clear=3D"none"></div></div></div>
</div>
</div></body></html>
------=_Part_5847661_1282761595.1575921382601--
--===============2061451609==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
LS0gCmNhaXJvIG1haWxpbmcgbGlzdApjYWlyb0BjYWlyb2dyYXBoaWNzLm9yZwpodHRwczovL2xp
c3RzLmNhaXJvZ3JhcGhpY3Mub3JnL21haWxtYW4vbGlzdGluZm8vY2Fpcm8=
--===============2061451609==--