Fix build with newer CMake and LLVM versions.

[cassandras-lies]

This is needed to build on Mac now.

[julian-CStack]

So I had used patch in the CMakeLists.txt. I've changed it to copy hardcoded files rather than patch the existing ones. I tested it on Windows this time.

I would like if you could include the files separately rather than as part of the patch. Any updates or changes in the future will be a bit easier to handle this way. Please include links where the files were sourced from. I regret not doing so for the thread_data.hpp file. Feel free to leave the links in a comment here and I will put them along the the source of thread_data.hpp somewhere in the repo once I track down where I found it.

[cassandras-lies]

This will make a submodule dependency dependent on the main repo. Maybe it would be better to vendor it in that case?

The modified files are the result of applying the previous patches to the source tree the boost-cmake module fetches, which is an extracted .bz2 file given as a source from the boost site.

[julian-CStack]

The boost-cmake submodule only depends on the main repo specifically for use in the main repo. Maybe I'm misunderstanding?

src/deps/patches/boost-patch.patch would still need to exist but I was referring to the new files created in the patch which are not copied from the boost source archive or modified from what I am seeing.

sidenote: This change https://github.com/cypherstack/flutter_libsparkmobile/pull/41/files#diff-f9b13aa9e581ca347c8e7e7e2bfb45ffa09d53074a461c38e90d4c33886e532bR36 is overridden by https://github.com/cypherstack/flutter_libsparkmobile/blob/main/src/CMakeLists.txt#L46-L47

[julian-CStack]

I'd actually love to not have to patch anything in the submodules. Not sure if that is feasible thoguh

[cassandras-lies]

So basically this boost-cmake submodule is pulling boost from a remote server (it does check the checksum), and then building it on the local machine with some CMake files that they've added. Unfortunately the remote boost version used there does not properly support compilation with newer LLVM and CMake. The boost-cmake.patch file adds a new commit in the boost-cmake repository, and that commit contains the updated files. It's kind of a confusing structure. :) Basically, patching the files directly from the outer module would leave a dirty working directory in the submodule (which will cause warnings every time you run git status), so the patch files to the boost source live inside the new boost-cmake.patch commit, and then those are copied over. I guess we can have the boost-cmake.patch reference files in the outer directory since it's a patch that exists only in our repo and not on any actual outside server, but I found that aesthetically displeasing.

As to not patching anything, unfortunately the boost-cmake source needs to be patched to work. boost-cmake uses a very old version of boost which is not compatible with new compilers.

Personally I would suggest removing the submodule entirely and vendoring the boost-cmake directory, as it looks like it's a dead project anyway.

Also, with regard to patching submodules generally, they will cause you to reference non-existent commits which will be annoying to work with when you make new commits as you need to be sure not to commit references to the now patched modules (as they can't be pulled from the remote repos specified in .gitmodules).

[julian-CStack]

Messy. Vendoring it may be the way to go then? Might be a bit of a pain to set stuff up for easy compilation across platforms (looking at you iOS)

Maybe we can user a recent version of boost? (just update the boost download link and hash in https://github.com/cypherstack/flutter_libsparkmobile/blob/main/src/CMakeLists.txt#L46-L47). Not sure if that will be compatible with the current source of sparkmobile. I thought firo uses 1.7x but I could be wrong there.

[cassandras-lies]

The whole "patching submodules" thing is kind of iffy entirely, but there was already a windows patch that did it, so I did it too. Honestly you should probably fork the submodule and point it to your own patched version rather than keeping a patch in an outer repository, due to the dirtiness and commit referent stuff.

[cassandras-lies]

Do you want me to vendor boost-cmake and openssl-cmake then? They're both dead projects, and that will do away with the ugly patching stuff.

[cassandras-lies]

sparkmobile is patched too, but we control that repo, so we can just push the fix to the real repo. I'm not sure why that wasn't done in the first place really.

[julian-CStack]

Do you want me to vendor boost-cmake and openssl-cmake then? They're both dead projects, and that will do away with the ugly patching stuff.

What about adding those as subtrees? We can then commit the changes to the main repo and do away with patching during build?

sparkmobile is patched too, but we control that repo, so we can just push the fix to the real repo. I'm not sure why that wasn't done in the first place really.

That is just the addition of the two cmakelists IIRC. I have no objection to actually getting those in to sparkmobile

[cassandras-lies]

Ok, so I added all the dependencies into subtrees and moved the patches into the actual directories. (The boost patches are still replacement files in the src/deps/boost-cmake/patches directory, because the boost source is pulled from a network repository.)

[julian-CStack]

The podspec files for ios and macos work ok without calling extras now? I assume they must. I can test later and tweak if needed.

Was the deletion of the run_build.sh along side the macos podspec while keeping that along side the ios podspec intentional?

Everything else looks good to me.

[julian-CStack]

LGTM

If any issues arise we can fix later