Create a subproject for sljit

[zherczeg]

This is just opening a discussion. Updating the jit compiler by hand creates huge patches in pcre2. When it was an svn project, this was the only option. However, we now use git. Would it be a good idea to use git subprojects for sljit?

[PhilipHazel]

I wasn't aware of Git subprojects (or submodules) but I've just had a quick look at some web pages. It looks as though it could be a better way of managing the integration of sljit into PCRE2. I am happy to go along with whatever you think is best, Zoltan.

[MatthewVernon]

I'd avoid submodules because they're mis-designed, but a subtree might be suitable?

[addisoncrump]

Even if it is mis-designed, it would likely be better than the current solution. Since very few people touch sljit, it likely wouldn't increase the overhead from e.g. new contributors not knowing how to use submodule, and would prevent situations like #407.

This also makes the relationship between the projects more clear. Should sljit be under PCRE2Project?

[zherczeg]

Sljit is an independent jit compiler used by various projects.

[minipli-oss]

I'm also in strong favor of getting a better change history for JIT related changes than the sometimes huge and often just big non-describing "JIT compiler update" commits. A git submodule feels just like a natural fit.

[zherczeg]

It looks like to me that the subproject way is preferred. The next thing is deciding where the subproject should be, since src/sljit is inside the primary code base, and that is not a usual place for external dependencies.

I would prefer third_party/sljit or just sljit. What do you think?

[minipli-oss]

Either its old place src/sljit or a move to sljit sounds good to me.

[PhilipHazel]

I have no preference.

[zherczeg]

Finally I decided to use deps/sljit since it make things clear. Alpine Linux tried to stop me, but I was able to figure out the CI config as well. Proposed patch #443

git submodule update --init --recursive will be needed after checkout.