Put Scintilla include header files into test folder

[zufuliu]

This avoids every CI run to download scintilla500.zip, see example download failures https://github.com/zufuliu/lexilla/actions/runs/20539507375/job/59001916614

The Install Scintilla source step could just copy/move bundled test/scintilla/include directory.

lexilla/.github/workflows/build-check.yml

Lines 16 to 20 in 0ffa2ad

	- name: Install Scintilla source
	run: |
	(cd .. && wget --no-verbose https://www.scintilla.org/scintilla500.zip)
	(cd .. && unzip scintilla500.zip)
	- name: Unit Test

[b4n]

What about simply using a cache action to limit external downloads?

[zufuliu]

lexilla only needs three headers (ILexer.h, Sci_Position.h and Scintilla.h, Scintilla.h is only used to access lexer specific constants, e.g. fold level constants SC_FOLDLEVEL*), I think put them in test folder would be simplest change.

[rdipardo]

Git submodules exist precisely for build dependencies that are only consumed verbatim. Instead of a file tree, you simply maintain a commit ref.

Mitchell's git mirror would be the most reliable choice, e.g.,

$ git submodule add -b default https://github.com/orbitalquark/scintilla-mirror.git scintilla
$ git commit .gitmodules

Then configure the workflow to also clone the submodule:

- uses: actions/checkout@*
  with:
    submodules: true

In any case the Makefile's include paths have to be overridden during a build, or edited with a new condition that checks whether the GITHUB_ACTIONS environment variable is defined.

[nyamatongwe]

Recent failures are with Win32 builds and they are showing problems connecting to scintilla.org with curl. It times out after 21 seconds. There's no indication which end causes the failure. There could be over-use / denial-of-service mitigations at scintilla.org hosting or github could be preventing something like distributing malware through actions. Or its just random failures. curl could be encouraged to try harder with --retry or similar. I don't mind occasionally hitting an extra button but its become worse - 3 failures in December.

Header distribution was an issue when Lexilla was separated from Scintilla and my choice was to have a single owner of the headers used to communicate between Scintilla and Lexilla. Since it seemed more likely that lexer projects will proliferate, Scintilla is the owner and distributor of the headers. An alternative design would add a third project (LexingInterface?) that owned and distributed the headers needed by Scintilla, Lexilla, and other projects that want to use or provide lexers. Including the headers within Lexilla encourages use of those headers rather than Scintilla's which then makes it more difficult for Scintilla to distribute improved headers.

The set of headers needed by Lexilla hasn't been minimized - as noted above SC_FOLDLEVEL* are in Scintilla.h along with many definitions Lexilla doesn't need so shouldn't see.

Caching the files may reduce failures but caches are still evicted once a week so failures may continue. I couldn't quickly work out how to implement caching for Lexilla tests.

Lexilla doesn't need most of Scintilla so a submodule seems too heavy and entangling.

[zufuliu]

An alternative design would add a third project (LexingInterface?)

That might make thing harder, Lexilla can't be used alone and also requires non/semi-lexer specific constants (SC_LINE_END_TYPE*) to communicate with Scintilla. minified version of Scintilla.h can only be used for test (so I suggest put them in the test folder), app uses Lexilla still needs Scintilla to ensure consistency.

[zufuliu]

Another option is created a dummy release for Lexilla, and upload scintilla500.zip as release asset, then change CI workflow to download the asset https://github.com/ScintillaOrg/lexilla/releases/download/<release-name>/scintilla500.zip.

Update curl option to curl -fsSL may help, https://www.appveyor.com/docs/how-to/download-file/#curl