Error in VS2019 about elements HOT 13 OPEN

Yes, the idea is that after CMake do its tests/detections when configuring, it checks for the prebuilt bins option and if set it starts download binaries, else do nothing downloads and prepare Skia requirements/tools (default) and builds Skia when build starts.

Sounds good to me. Basically, something like: we prepared prebuilt libraries for Skia for xxx-system and www-compler and zzz-processor. If we do not have a prebulit library for your target, the cmake build scipt will attempt to build Skia for you. In such cases, here are the requirements: this and that and so on... python etc...

from elements.

We are using VS2022 currently. Any chance you cal use that instead. The linker errors are related to the c++ library. Skia is the dependent library, specifically tag m106. I must warn you though. Skia is a PAIN to build.

@redtide Another addition to the dependency matrix of the pre-compiled headers: compiler version :-(

from elements.

OK

from elements.

@redtide The issue here is that we can't practically have all the precompiled binaries for all platforms, compilers, processors. And the glaring question is, what do we do when someone has a particular setup that is not included in our binaries for download? Do we just ask them to run the script? And then what?

from elements.

Until now other than Arm64 and x86_64 (32 is becoming old even for RPi and the like it seems) there was only a request for RiskV (in another project).
Compilers? GCC, Clang and MSVC seems enough to me, maybe MingW64? Platforms... when you cover Linux/BSD, macOS and Windows, later maybe Android, IOS and WebAssembly IDK what else. Just check the current repo at JetBrains. There is a limit (we have limits), else... yes, DIY.

That is also why I like the idea to use scripts instead embedding commands in CI, so people can use them locally to build. Maybe that way they can propose some PR to include some exception we don't cover? Though it seems already a lot of builds to support.

As side note, the current JetBrains repo seems to have removed the compiler option, so I guess they now only build using GCC on Linux and MSVC on Windows. If were me I would force to use Clang everywhere instead since it's the one where Skia gives the maximum performances. IDK on Windows but using Clang on Linux is not that big pain for a C++ based project.

WDYM with and then what? I guess they have to check first also that the Artist, Elements (maybe also Infra header only libraries?) code supports their setup. They can also maintain their own custom setup themselves using CI (both for Skia and Elements) if we can't support all the options in the world.
In that case CI can also build Elements, so they can download the static lib directly for their project.

from elements.

Compilers? GCC, Clang and MSVC seems enough to me

That is correct. But I should have mentioned: compiler versions. As you see in this issue, a prebuilt library for VS 2019 is not necessarily compatible with VS 2020 or VS 2023. It's a combinatorial explosion.

from elements.

Here's a thought. What do you think about not pre-building at all using CI, but instead having the build script for Skia run, on demand, at install time on each platform, via cmake. That would mean, having python and all the build dependencies of Skia.

The pre-built thing is looking like a nasty rabbit hole.

from elements.

I'm not sure I understand what you mean, run the build at install time?
Don't we need to build Skia before Elements and then link to it when Elements' build finishes?
From my POV you can add another option, say ELEMENTS_USE_SKIA_PREBUILD set to false by default, and run a custom CMake command that calls the python scripts. So if people like me don't want to build Skia, can use prebuilt binaries and set the option true/on.

from elements.

I'm not sure I understand what you mean, run the build at install time?

Build Skia using cmake, instead of downloading prebuilt binaries.

from elements.

Compilers? GCC, Clang and MSVC seems enough to me

That is correct. But I should have mentioned: compiler versions. As you see in this issue, a prebuilt library for VS 2019 is not necessarily compatible with VS 2020 or VS 2023. It's a combinatorial explosion.

OK, so if version is also an issue I'm starting wondering how JetBrains people have no issues with it, maybe users using it just use the same compiler and same version? Still the answer above could be a solution: want different setup/unsupported platform/whatever? BIY (build it yourself :D ), else use our setup and prebuilt bins.

Build Skia using cmake, instead of downloading prebuilt binaries.

Ah OK, so it's what I call "configuration time" (IDK if there are "standard names"), install time for me means when you install all the built artifacts in system.
Yes, the idea is that after CMake do its tests/detections when configuring, it checks for the prebuilt bins option and if set it starts download binaries, else do nothing downloads and prepare Skia requirements/tools (default) and builds Skia when build starts.

from elements.

In brief, we could not add the option now, and add Skia to the configuration:

• add its dependencies in CMake
• rename the build.py command to configure.py and remove the ninja build command
• run checkout.py and configure.py during CMake configuration
• at build time, before Elements, call Skia' ninja build command

from elements.

OK, so if version is also an issue I'm starting wondering how JetBrains people have no issues with it, maybe users using it just use the same compiler and same version?

Because JetBrains' target is not a library. It is an app. They have control over everything.

from elements.

Please use the master (cairo) branch for now. Skia needs a LOT of work to get right.

from elements.