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.