Regarding the build process (mainly for SciTE, but also for Scintilla and Lexilla)
38 views
Skip to first unread message
Naram Qashat
May 6, 2025, 7:55:27 AMMay 6
to scite-interest
Hi there,
I've been maintaining the FreeBSD port of SciTE (and by extension, Scintilla and later Lexilla) for many years now, but I've always been a bit baffled by the build process for them. From my understanding, it appears as if they aren't really designed to be built and installed separately from each other, that all of them are expected to be built together. 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 actually link to any Lexilla shared library, but it does link with Scintilla's shared library. And I've also found that Lexilla only seems to need Scintilla for building and rely on Scintilla's library in any way.
So mainly, I'd like some insight about how to properly build all 3 in such 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 contains both the source code of Lexilla and Scintilla in it).
Thanks in advance,
Naram "CyberBotX" Qashat
Neil Hodgson
May 8, 2025, 12:34:52 AMMay 8
to scite-i...@googlegroups.com
Naram Qashat:
> I've been maintaining the FreeBSD port of SciTE (and by extension, Scintilla and later Lexilla) for many years now, but I've always been a bit baffled by the build process for them. From my understanding, it appears as if they aren't really designed to be built and installed separately from each other, that all of them are expected to be built together.
I see Scintilla and Lexilla as libraries for use by multiple downstream projects 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 complex 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 fan 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 contain any GUI code but its also often modified by applications that want to supplement the set of lexers or remove unused lexers to avoid bloat and dead-code 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 actually link to any Lexilla shared library,
SciTE commonly loads Lexilla dynamically allowing users to replace or supplement the set of lexers with their own shared library.
There is support for statically linking Scintilla and Lexilla into SciTE but 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 that 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 decoupled and completely orchestrated by an application like SciTE.
> So mainly, I'd like some insight about how to properly build all 3 in such 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 contains 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 directory instead of a global shared library directory.
There may be downstream projects that would like shared system-wide installations of Scintilla (GTK) and Lexilla. Build procedures including installation and package manager integration could be defined for the benefit of those projects by people that would use the results.
Neil
> I've been maintaining the FreeBSD port of SciTE (and by extension, Scintilla and later Lexilla) for many years now, but I've always been a bit baffled by the build process for them. From my understanding, it appears as if they aren't really designed to be built and installed separately from each other, that all of them are expected to be built together.
Scintilla and Lexilla are commonly integrated into applications rather than being installed as their own independently-versioned entities. I'm not a fan 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 contain any GUI code but its also often modified by applications that want to supplement the set of lexers or remove unused lexers to avoid bloat and dead-code 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 actually link to any Lexilla shared library,
There is support for statically linking Scintilla and Lexilla into SciTE but 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 that Lexilla only seems to need Scintilla for building and rely on Scintilla's library in any way.
> So mainly, I'd like some insight about how to properly build all 3 in such 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 contains both the source code of Lexilla and Scintilla in it).
There may be downstream projects that would like shared system-wide installations of Scintilla (GTK) and Lexilla. Build procedures including installation and package manager integration could be defined for the benefit of those projects by people that would use the results.
Neil
Roland Hughes
May 9, 2025, 3:34:45 AMMay 9
to scite-i...@googlegroups.com
Hello Naram,
I cannot directly answer your question, I can only point you to the CopperSpice ports and RedDiamond where I did what you are asking.
Things are in a state of flux because I forked CopperSpice to LsCs for a major gutting to become BasisDoctrina or Bd for short.
The Wiki pages may provide you some guidance.
I haven't looked at the stuff in seven or more months, finishing writing another novel and dealing with life in general. Adding insult to injury I'm on a Windows machine in my house, not at my office with Linux machines where I could quickly verify what I'm thinking.
In the Cmake files you want to focus on libRedLex
Actually, in this second one it is all REDLEX and RedLex things you would wish to look at.
Sorry, I don't check this GMail account very often. Just too much going on right now. You should be able to thieve the CMake stuff and cobble together your own library builds.
I don't use FreeBSD so do not know the packaging. If it is somewhat close to either Debian or RPM you can look at
the flatpak stuff is not yet done so don't look at it.
Hope this helps rather than confuses.
I can offer a word of caution.
Most everyone has to customize the lexers. While they are great, they were done by various people who had differing ideas when it came to colors. SciLexer.h
Things "work" because of a time honored much abused aspect of C programming. #define-ing 32,767 different names to have the same value. When you come up with your "perfect" color theme for C programming it becomes mud fence ugly for some other languages.
In the later stages of editor development, almost everybody has to come up with their own method of nuking these constants and replacing with a single definition OR they take the other approach dynamically redefining the theme for each language.
When you want some non-white backgrounds so things are easier on older eyes though
Most of us (perhaps just me) develop really nice looking themes for C/C++. Then you pull up something like COBOL, FORTRAN, etc. and it is God-awful.
Some of us (perhaps just me) are incredibly OCD when it comes to text editors. No matter what language we are using we want the strings to always be the same color, same with numbers, etc. Search SciLexer.h for "_STRING" and you will find those of us who are OCD about such things have a very brutal reality to face. But we're programmers so we can redefine reality! As long as A) we keep a sacred baseline copy somewhere to diff against or B) we never want to merge again.
Hopefully I've helped you more than harmed with this post.
--
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 email to scite-interes...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/scite-interest/1c9257b7-c288-4fb7-9768-e6b427404191n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages