mirror of
https://github.com/QB64-Phoenix-Edition/QB64pe.git
synced 2024-07-03 18:11:20 +00:00
c165476838
Previously, the creation of the icon.rc file was restricted to be Windows only because Windows is the only platform with a use for that file. Unfortunately, this breaks a fundimental assumption about how the QB64 C++ generation works, because we only have one set of `./internal/source` files from which we build all versions of QB64 for all platforms. Due to that, the built version needs to include all files needed by all platforms, regardless of which one is doing the building. So to that end, all platforms should produce the icon.rc, even if it will not be used on that platform. Additionally, the path to the icon file in `icon.rc` is problimatic because it is made into an absolute path. This blocks `qb64.bas` from using `$EXEICON` because the absolute path is not predictable, as the location we create ./internal/source will be different from the location we build ./internal/source. Effectively this means that the `icon.rc` file in `./internal/source` would always be wrong. The solution is to not use an absolute path, with the other option being to have the icon in the same directory as the resource file. This is actually relatively easy to acomplish since icon files are not terribly large and we can simply copy it into the temp directory. Thus, that is what this change does - the specified icon file is copied into the temp directory as `icon.ico`, which allows use to use `icon.ico` in the `icon.rc` file and have it always work regardless of directory. The internal logic was also cleaned up a bit. The creation of these files is no longer Windows specific, and the $EXEICON parsing no longer writes to the `icon.rc` file - rather, the entire thing is generated together, with both the $VERSIONINFo and $EXEICON depending on which were provided. |
||
|---|---|---|
| .. | ||
| ini-manager | ||
| file.bas | ||
| strings.bas | ||