Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
msys2_mingw [2024/03/14 09:34] – [OpenGL через SD2L] adminmsys2_mingw [2025/07/10 15:36] (current) – admin
Line 39: Line 39:
 Вы еще тут ? Я еще держусь, но с трудом... :) Вы еще тут ? Я еще держусь, но с трудом... :)
  
-**ПРИМЕЧАНИЕ:** С мая 2020 32-битную **MSYS2** стали [[https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supported|потихоньку сворачивать]]. Она еще поддерживается, но пакеты для нее выходят крайне редко, а начальный инсталлятор для 32-битной версии **MSYS2** убрали с главной стравницы [[http://repo.msys2.org/distrib/i686/|сюда]]. Следите за [[https://www.msys2.org/news/|новостями]]. Таким образом, даже для сборки 32-битных приложений нужно использовать 64-битную ОС и 64-битную ''MSYS2''. Этакая кросс-система. Увы.+**ПРИМЕЧАНИЕ:** С мая 2020 32-битную **MSYS2** стали [[https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supported|потихоньку сворачивать]] также как и поддержку старых систем Windows 7 и Windows 8. Они еще поддерживается, но пакеты для них выходят крайне редко, а начальный инсталлятор для 32-битной версии **MSYS2** убрали с главной стравницы [[http://repo.msys2.org/distrib/i686/|сюда]]. Следите за [[https://www.msys2.org/news/|новостями]]. Таким образом, даже для сборки 32-битных приложений нужно использовать 64-битную ОС и 64-битную ''MSYS2''. Этакая кросс-система. Увы.
  
 [[https://www.msys2.org/news/#2022-04-06-windows-7-8-support-will-be-dropped-late-2022-or-early-2023|2022-04-06 - Windows 7 / 8 support will be dropped late 2022 or early 2023]] [[https://www.msys2.org/news/#2022-04-06-windows-7-8-support-will-be-dropped-late-2022-or-early-2023|2022-04-06 - Windows 7 / 8 support will be dropped late 2022 or early 2023]]
Line 50: Line 50:
 под Windows-консоль. А вот хрен вам! Оказывается, теперь есть НЕ ОДИН компилятор, точнее не одна build-система (среда, namespace e.t.c.), а несколько. под Windows-консоль. А вот хрен вам! Оказывается, теперь есть НЕ ОДИН компилятор, точнее не одна build-система (среда, namespace e.t.c.), а несколько.
 Из них первая - для компиляции программ под __САМУ__ **MSYS2** (вы же помните, что она тащит за собой теперь как Из них первая - для компиляции программ под __САМУ__ **MSYS2** (вы же помните, что она тащит за собой теперь как
-минимум DLL ''msys-2.0.dll'' и работает с UNIX-путями), а остальные build-системы - для обычных "голых" Windows программ,+минимум DLL ''msys-2.0.dll'' и работает с UNIX-путями?), а остальные build-системы - для обычных "голых" Windows программ,
 как в старом добром **Mingw**. Компилятор и там и там - знакомый **Mingw-w64**, но по-разному настроенный. Да, как в старом добром **Mingw**. Компилятор и там и там - знакомый **Mingw-w64**, но по-разному настроенный. Да,
 не забываем что всё это может существовать в 32-бит, 64-бит и все комбинации между ними! не забываем что всё это может существовать в 32-бит, 64-бит и все комбинации между ними!
Line 168: Line 168:
 **ПРИМЕЧАНИЕ**: Как было написано выше, управление консолью в Windows устроено совсем иначе, чем в UNIX, так что не обходится без глюков. Библиотека ncurses реализована таким образом, что она "чувствует", под какой консолью она работает и включает "магию". Если мы запускаем одну и ту же прогрмамму под UNIX-подобной консолью, она начинает управлять экраном через ESC-последовательности, а если из CMD или PowerShell - через API Windows Console. Но фокус в том, что для ESC-последовательностей нужна база терминалов, а она не всегда доступна. Это дает неприятный результат: программа на ncurses неадекватно работает из "оболочки" **MSYS2 Mingw64** в которой мы ее только что откомпилировали. А из обычных CMD или PowerShell работает нормально. Как это обойти ? Если нужна программа для среды **MSYS2** - скомпилируйте ее в оболочке **MSYS2 MSYS** с ее библиотеками, а если "чистая виндовая" - в среде **MSYS2 Mingw64**. **ПРИМЕЧАНИЕ**: Как было написано выше, управление консолью в Windows устроено совсем иначе, чем в UNIX, так что не обходится без глюков. Библиотека ncurses реализована таким образом, что она "чувствует", под какой консолью она работает и включает "магию". Если мы запускаем одну и ту же прогрмамму под UNIX-подобной консолью, она начинает управлять экраном через ESC-последовательности, а если из CMD или PowerShell - через API Windows Console. Но фокус в том, что для ESC-последовательностей нужна база терминалов, а она не всегда доступна. Это дает неприятный результат: программа на ncurses неадекватно работает из "оболочки" **MSYS2 Mingw64** в которой мы ее только что откомпилировали. А из обычных CMD или PowerShell работает нормально. Как это обойти ? Если нужна программа для среды **MSYS2** - скомпилируйте ее в оболочке **MSYS2 MSYS** с ее библиотеками, а если "чистая виндовая" - в среде **MSYS2 Mingw64**.
  
-Давайте создадим простую ncurses программу для Windows (конечно же статическую):+Давайте создадим простую ncurses программу для консоли Windows (конечно же статическую):
  
   #include <curses.h>   #include <curses.h>
Line 362: Line 362:
  
 https://ps-group.github.io/opengl/lesson_1 https://ps-group.github.io/opengl/lesson_1
 +
 +==== QT ====
 +
 +Еще одна популярная кроссплатформанная библиотека.
 +
 +Среди пакетов MSYS2 имеется IDE QtCreator
 +
 +Параграф не написан.
 +
 +https://wiki.qt.io/MSYS2
 +
  
 ==== Интеграция MSYS2 и VSCode ==== ==== Интеграция MSYS2 и VSCode ====

Trace: • soprj • albom

Navigation