Re: Regarding the build process (mainly for SciTE, but also for Scintilla and Lexilla)

"'Neil Hodgson' via scite-interest" <[email protected]> Thu, 8 May 2025 14:34:34 +1000
Newsgroups gmane.editors.scite.general
Message-ID <[email protected]>
Naram Qashat:

> I've been maintaining the FreeBSD port of SciTE (and by extension, Scinti=
lla and later Lexilla) for many years now, but I've always been a bit baffl=
ed by the build process for them. From my understanding, it appears as if t=
hey aren't really designed to be built and installed separately from each o=
ther, that all of them are expected to be built together.

I see Scintilla and Lexilla as libraries for use by multiple downstream pro=
jects and SciTE is just an application that acts as a demonstration for the=
 libraries and is a bit useful itself. Most users will prefer using more co=
mplex applications that call Scintilla and Lexilla like Geany or Notepad++.

Scintilla and Lexilla are commonly integrated into applications rather than=
 being installed as their own independently-versioned entities. I'm not a f=
an of the Unix shared package paradigm as applications are more robust when=
 used with the specific library versions they were tested against.

Scintilla isn't a singular package on any platform as binaries are compiled=
 against specific GUI platform layers like GTK, Qt, Wx, and others.

Lexilla is more amenable to having a single package since it doesn't contai=
n any GUI code but its also often modified by applications that want to sup=
plement the set of lexers or remove unused lexers to avoid bloat and dead-c=
ode security issues.

> I've tried working around that with the FreeBSD ports, so that there can =
be 3 separate ones (there is x11-toolkits/scintilla for Scintilla, textproc=
/lexilla for Lexilla and editors/scite for Scite). However, I've found that=
 with the way the build process currently is, SciTE does not appear to actu=
ally link to any Lexilla shared library,

SciTE commonly loads Lexilla dynamically allowing users to replace or suppl=
ement the set of lexers with their own shared library.

There is support for statically linking Scintilla and Lexilla into SciTE bu=
t that is only commonly exercised on Win32 where it produces a version with=
 a single file installation.

> but it does link with Scintilla's shared library. And I've also found tha=
t Lexilla only seems to need Scintilla for building and rely on Scintilla's=
 library in any way.

Scintilla calls Lexilla (or something else that provides the same API) and =
Lexilla calls back into Scintilla. However, this relationship is fully deco=
upled and completely orchestrated by an application like SciTE.

> So mainly, I'd like some insight about how to properly build all 3 in suc=
h a way that they can be treated as separate, individual entities and that =
they can be installed individually and used in the build process outside of=
 what is included in the tarball (as I've noticed that SciTE's tarball cont=
ains both the source code of Lexilla and Scintilla in it).

Scintilla and Lexilla do not specify 'install' targets as that is deferred =
to the application. SciTE puts them into its own $(prefix)/lib/scite direct=
ory instead of a global shared library directory.

There may be downstream projects that would like shared system-wide install=
ations of Scintilla (GTK) and Lexilla. Build procedures including installat=
ion and package manager integration could be defined for the benefit of tho=
se projects by people that would use the results.

Neil

--=20
You received this message because you are subscribed to the Google Groups "=
scite-interest" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/scite-inter=
est/DBE10CE8-34F1-497F-8019-6AC8BF15E274%40me.com.