win32: Replace scripts with native/cross-files definitions #476
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
By creating so many build scripts, they must be maintained, which considering the current scripts are batch-scripts it means it will sometimes be too hard to fix/update them to get too little benefit. There were two main purposes in having those scripts: - Ensuring pre-build procedures (setting environment variables and running vcvars64) have been done. - Setting windows-specific project option values, such as disabling wayland/x11 support and some Unix-specific EFL modules. For the first one, after quite a lot of changes in the codebase, there's only one environment variable to be set: CMAKE_TOOLCHAIN_FILE, which must then be passed to -Dcmake_args project option to meson. This is now done by creating a simple native-file with the cmake_args value on it, so a script to check/define it is above overkill. About vcvars64, this might be a simple "run vcvars64" (or "start a Develop Console from Visual Studio") instruction in compile and installation guides. For the second one, since meson 0.55 and further more on 0.56, there were some serious updates on cross/native-file definitions, which now fixes the issue mesonbuild/meson#6783 that was the one that blocked EFL most from relying solely on native/cross-files. Given these, there's no good reason left to keep relying on these scripts, thus simplifying the build procedure a lot and making it more reliable and customizable, since now we only depend on meson defaults and not on another language (in this case, batch-script).
Co-authored-by: João Antônio Cardoso <joao.maker@gmail.com>
Co-authored-by: João Antônio Cardoso <joao.maker@gmail.com>
joaoantoniocardoso
approved these changes
Apr 9, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
By creating so many build scripts, they must be maintained, which
considering the current scripts are batch-scripts it means it will
sometimes be too hard to fix/update them to get too little benefit.
There were two main purposes in having those scripts:
running vcvars64) have been done.
wayland/x11 support and some Unix-specific EFL modules.
For the first one, after quite a lot of changes in the codebase, there's
only one environment variable to be set: CMAKE_TOOLCHAIN_FILE, which
must then be passed to -Dcmake_args project option to meson. This is now
done by creating a simple native-file with the cmake_args value on it,
so a script to check/define it is above overkill. About vcvars64, this
might be a simple "run vcvars64" (or "start a Develop Console from
Visual Studio") instruction in compile and installation guides.
For the second one, since meson 0.55 and further more on 0.56, there
were some serious updates on cross/native-file definitions, which now
fixes the issue mesonbuild/meson#6783 that was
the one that blocked EFL most from relying solely on native/cross-files.
Given these, there's no good reason left to keep relying on these
scripts, thus simplifying the build procedure a lot and making it more
reliable and customizable, since now we only depend on meson defaults
and not on another language (in this case, batch-script).